Topic: [ANN][XCN] Cryptonite | 1st mini-blockchain coin | M7 PoW | No Premine - page 10. (Read 578543 times)
January 02, 2017, 05:48:52 PM
Is the future Bright with Cryptonite or should we pass on this one?
January 02, 2017, 05:45:46 AM
Since whis was fixed soon after XCN release, it may be trivial to backport.
Could you point me to the commit on the bitcoin git? I will have a look.
I have previously tried looking for a specific commit which fixed the issue but couldn't seem to find one. I think the fix may have been included with some larger patch, I'm not really sure. I found several bug reports about random wallet corruption, such as this one, which were made around the start of 2014 and have the same error codes, however it seems they were closed without referencing a commit which solved the issue. I recall our core dev being stumped about the wallet corruption because he didn't change anything that could have caused it, so I'm fairly certain it is a bug inherited from Bitcoin.Could you point me to the commit on the bitcoin git? I will have a look.
This might be a bit more complex: do you have an idea what kind of work is needed for this?
Yes it wont be as simple as copying the Bitcoin implementation because we have the whole account tree thing. I have a rough idea as to what would be required, the hard part will be adapting all the changes Bitcoin has undergone in the last few years, much of the code has been overhauled to work in a very different way to how it worked when Cryptonite was forked from it, but many of those changes are necessary to make things like the parallel block downloading work properly. January 02, 2017, 04:46:31 AM
Since the original dev is around, i will be stepping back to let him resolve the issues.
I didn't code Cryptonite, I helped develop the concepts behind it and funded the development of it. If you read the first pages of this thread you will see we had a core dev but he's no longer around. As I've said before, not having a premine makes it hard to attract developers. I made a mistake assuming that open source developers would continue improving Cryptonite. My C++ skills are still fairly limited so it's unlikely I will be able to solve all these issues myself, but I am looking in the sync issues.Based on some research I did a few days ago many of the bugs in Cryptonite have been carried over from Bitcoin. For example, there are Bitcoin bug reports about wallet corruption submitted around the time Cryptonite was forked from Bitcoin. The bugs are clearly related because even the error numbers and error messages are the same as the ones reported by people using Cryptonite. I think many of the bugs in Cryptonite could be solved simply by applying many of the fixes which have since been applied to Bitcoin.
The version of Bitcoin used to create Cryptonite also lacked several important features it has now. As I said earlier, the networking code was fairly poor and only allowed the blockchain to be downloaded from one peer at a time. Back then, Bitcoin also didn't download the block headers before downloading blocks, so it had to download blocks in order and couldn't do it in parallel.
Cryptonite was actually the first coin to implement the headers first approach, Bitcoin gained that feature shortly after the release of Cryptonite. However our headers first implementation was rushed and is not as robust as the Bitcoin implementation, and without good networking code we cannot download blocks in a parallel fashion from multiple peers at the same time, which is much faster and less error prone.
Once again I think many problems with Cryptonite could be solved by adapting the new networking code and new syncing code from Bitcoin so that the headers first synchronization works more smoothly. I am looking into how I can make some of these upgrades myself but like I said my skills are limited. Also I wont be back home for another day or two and I'm stuck with a slow laptop which doesn't have much of my software on it.
My point is, Cryptonite needs all the developers it can get right now. I know it's not easy to locate these bugs and fix them because it probably would have been done by someone by now. If we had the original dev it would probably be a lot easier to fix these issues but I doubt he will be coming back any time soon so we need other developers to keep Cryptonite alive.
I have been considering the idea of remaking Cryptonite and implementing a pre-mine, then allowing the old coins to be converted to the new coins, but I'm not exactly sure how that would be done in a fair manner. I'm not sure if that would really be a good idea but at least then we could provide a reason for devs to work on the new version of Cryptonite.
Work together guys, looks like you would make a great team collaborating. As for funding, I think a coin swap @ 90% would be accepted by most, that would create 10% for ongoing dev expenses. The other option is donations, but might get a lot less that way.
January 02, 2017, 03:34:25 AM
Based on some research I did a few days ago many of the bugs in Cryptonite have been carried over from Bitcoin. For example, there are Bitcoin bug reports about wallet corruption submitted around the time Cryptonite was forked from Bitcoin. The bugs are clearly related because even the error numbers and error messages are the same as the ones reported by people using Cryptonite. I think many of the bugs in Cryptonite could be solved simply by applying many of the fixes which have since been applied to Bitcoin.
Since whis was fixed soon after XCN release, it may be trivial to backport.
Could you point me to the commit on the bitcoin git? I will have a look.
Once again I think many problems with Cryptonite could be solved by adapting the new networking code and new syncing code from Bitcoin so that the headers first synchronization works more smoothly. I am looking into how I can make some of these upgrades myself but like I said my skills are limited. Also I wont be back home for another day or two and I'm stuck with a slow laptop which doesn't have much of my software on it.
This might be a bit more complex: do you have an idea what kind of work is needed for this?
I have been considering the idea of remaking Cryptonite and implementing a pre-mine, then allowing the old coins to be converted to the new coins, but I'm not exactly sure how that would be done in a fair manner. I'm not sure if that would really be a good idea but at least then we could provide a reason for devs to work on the new version of Cryptonite.
I've been thru swaps some times and it always made someone unhappy, but if restarting from a recent version of bitcoin takes less or about the same time than fixing the old code, it will be a good choice because, in the end, the advantages are countless.
January 02, 2017, 03:22:31 AM
Since the original dev is around, i will be stepping back to let him resolve the issues.
I didn't code Cryptonite, I helped develop the concepts behind it and funded the development of it. If you read the first pages of this thread you will see we had a core dev but he's no longer around. As I've said before, not having a premine makes it hard to attract developers. I made a mistake assuming that open source developers would continue improving Cryptonite. My C++ skills are still fairly limited so it's unlikely I will be able to solve all these issues myself, but I am looking in the sync issues.Based on some research I did a few days ago many of the bugs in Cryptonite have been carried over from Bitcoin. For example, there are Bitcoin bug reports about wallet corruption submitted around the time Cryptonite was forked from Bitcoin. The bugs are clearly related because even the error numbers and error messages are the same as the ones reported by people using Cryptonite. I think many of the bugs in Cryptonite could be solved simply by applying many of the fixes which have since been applied to Bitcoin.
The version of Bitcoin used to create Cryptonite also lacked several important features it has now. As I said earlier, the networking code was fairly poor and only allowed the blockchain to be downloaded from one peer at a time. Back then, Bitcoin also didn't download the block headers before downloading blocks, so it had to download blocks in order and couldn't do it in parallel.
Cryptonite was actually the first coin to implement the headers first approach, Bitcoin gained that feature shortly after the release of Cryptonite. However our headers first implementation was rushed and is not as robust as the Bitcoin implementation, and without good networking code we cannot download blocks in a parallel fashion from multiple peers at the same time, which is much faster and less error prone.
Once again I think many problems with Cryptonite could be solved by adapting the new networking code and new syncing code from Bitcoin so that the headers first synchronization works more smoothly. I am looking into how I can make some of these upgrades myself but like I said my skills are limited. Also I wont be back home for another day or two and I'm stuck with a slow laptop which doesn't have much of my software on it.
My point is, Cryptonite needs all the developers it can get right now. I know it's not easy to locate these bugs and fix them because it probably would have been done by someone by now. If we had the original dev it would probably be a lot easier to fix these issues but I doubt he will be coming back any time soon so we need other developers to keep Cryptonite alive.
I have been considering the idea of remaking Cryptonite and implementing a pre-mine, then allowing the old coins to be converted to the new coins, but I'm not exactly sure how that would be done in a fair manner. I'm not sure if that would really be a good idea but at least then we could provide a reason for devs to work on the new version of Cryptonite.
January 01, 2017, 05:55:46 PM
hi bitfreak,
Getting size for height : 1265985
Cannot fastforward chain because of missing data:
OS 1265**9 NS 1265987
Accepted block 1265969
Accept block header
loads of these messages so i really cant get to get to the end of the blocks in the xcn blockchain,
stays a bit behind,
Getting size for height : 1265985
Cannot fastforward chain because of missing data:
OS 1265**9 NS 1265987
Accepted block 1265969
Accept block header
loads of these messages so i really cant get to get to the end of the blocks in the xcn blockchain,
stays a bit behind,
January 01, 2017, 08:10:37 AM
Since the original dev is around, i will be stepping back to let him resolve the issues.
January 01, 2017, 03:34:06 AM
Only two of us donating of the top 15 miners on xcn.suprnova.cc
Others in the top 15 should consider donating to the suprnova pool as well
Its been one of the best pools and in some cases the only pool when others have gone down.
Others in the top 15 should consider donating to the suprnova pool as well
Its been one of the best pools and in some cases the only pool when others have gone down.
Donate also for block explorer. Today is new month so server bills comes.
December 31, 2016, 11:54:08 AM
Only two of us donating of the top 15 miners on xcn.suprnova.cc
Others in the top 15 should consider donating to the suprnova pool as well
Its been one of the best pools and in some cases the only pool when others have gone down.
Others in the top 15 should consider donating to the suprnova pool as well
Its been one of the best pools and in some cases the only pool when others have gone down.
December 31, 2016, 09:13:23 AM
Btc38 working again.
December 31, 2016, 08:20:34 AM
hi china,
no no block explorer is good,
bitfreak is back that is way gooder,,
so relax, buy some @ really cheap @ now @ polo
no no block explorer is good,
bitfreak is back that is way gooder,,
so relax, buy some @ really cheap @ now @ polo
December 30, 2016, 11:41:21 AM
Block Explorers is bad??
December 29, 2016, 11:37:07 PM
For those people who asked to know more about the syncing process, here's a post I made a little while back:
The main difference really comes down to the fact the Bitcoin uses transaction scripting but Cryptonite doesn't. When you sync with Bitcoin you need to download the full blockchain in order to validate it and calculate your wallet balance because the inputs and outputs link the transactions together, which makes it difficult to prune old transactions.
For that same reason it can be slow to import a new private key into a bitcoind-based wallet because it needs to rescan the blockchain to recalculate the wallet balance. And that is why you simply cannot get the balance of any address which isn't in your wallet using bitcoind. However I think they've also recently remedied this problem a little bit with watch only addresses.
But I believe bitcoind still needs to perform a rescan after importing a watch only address in order to calculate the address balance, and I believe a Bitcoin wallet with pruning enabled wouldn't be able to perform those rescans because it wouldn't have the entire transaction history required to calculate the balances, because it has pruned that data.
The release notes for Bitcoin Core 0.11.0 stated that "Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.)", and I'm uncertain if the situation has improved since then but they had plans for it.
I think I read some where not too long ago that they wanted to use a hash tree structure to store the unspent outputs and maybe even balances, some what similar to the "account tree" in Cryptonite, however I believe that would still require the full blockchain to be downloaded and scanned so the tree could be built, so syncing would still be very slow.
The main advantage with Cryptonite is that transactions don't link together, so all of them can safely be forgotten after a certain period of time. Instead of having to download the full blockchain, nodes only have to download a recent portion of the blockchain along with the account tree / balance sheet, with which they can become a full node.
The real trick is that the nodes share the account tree between themselves and they're able to use data embedded into the blockchain in order to verify the validity of their copy of the account tree. When a new block is accepted, transactions in the block will cause balances in the tree to be updated among all nodes so they all have the same copy of the balance sheet.
So when a transaction is being made, there is no need to reference what may be a very old transaction like with Bitcoin, instead the inputs and outputs of a transaction will simply reference address nodes in the account tree. It's a more purely mathematical approach without all the scripting on top, closer to how a normal banking system would work.
The consequences of this approach is that the balance of any address can be cheaply computed simply by looking up the balance of that address in the account tree, which all synced nodes will have an up-to-date copy of. It also means block pruning is completely compatible with using a wallet because blockchain rescans are not necessary.
Most importantly, it means that the time required for a new node to sync is vastly reduced, because instead of needing to download every transaction which has ever occurred, they only need to download transactions from the last week or so, along with the account tree which nodes are programmed to share, and they've got all they need to be a full node.
They will never have to worry about not having some old transaction which has been pruned from their disk because those transactions will never have to be referenced again. The account tree is a self contained balance sheet which tells a node essentially everything it needs to know in order to check balances and validate transactions.
Of course there are a lot of little finicky details like the inversion database which is required for undoing changes made to the account tree in the case of forking, and I would suggest reading the Cryptonite wiki if you want a deeper understanding of how it works. I tried to keep this explanation relatively simple so that it wasn't too hard to understand.
For that same reason it can be slow to import a new private key into a bitcoind-based wallet because it needs to rescan the blockchain to recalculate the wallet balance. And that is why you simply cannot get the balance of any address which isn't in your wallet using bitcoind. However I think they've also recently remedied this problem a little bit with watch only addresses.
But I believe bitcoind still needs to perform a rescan after importing a watch only address in order to calculate the address balance, and I believe a Bitcoin wallet with pruning enabled wouldn't be able to perform those rescans because it wouldn't have the entire transaction history required to calculate the balances, because it has pruned that data.
The release notes for Bitcoin Core 0.11.0 stated that "Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.)", and I'm uncertain if the situation has improved since then but they had plans for it.
I think I read some where not too long ago that they wanted to use a hash tree structure to store the unspent outputs and maybe even balances, some what similar to the "account tree" in Cryptonite, however I believe that would still require the full blockchain to be downloaded and scanned so the tree could be built, so syncing would still be very slow.
The main advantage with Cryptonite is that transactions don't link together, so all of them can safely be forgotten after a certain period of time. Instead of having to download the full blockchain, nodes only have to download a recent portion of the blockchain along with the account tree / balance sheet, with which they can become a full node.
The real trick is that the nodes share the account tree between themselves and they're able to use data embedded into the blockchain in order to verify the validity of their copy of the account tree. When a new block is accepted, transactions in the block will cause balances in the tree to be updated among all nodes so they all have the same copy of the balance sheet.
So when a transaction is being made, there is no need to reference what may be a very old transaction like with Bitcoin, instead the inputs and outputs of a transaction will simply reference address nodes in the account tree. It's a more purely mathematical approach without all the scripting on top, closer to how a normal banking system would work.
The consequences of this approach is that the balance of any address can be cheaply computed simply by looking up the balance of that address in the account tree, which all synced nodes will have an up-to-date copy of. It also means block pruning is completely compatible with using a wallet because blockchain rescans are not necessary.
Most importantly, it means that the time required for a new node to sync is vastly reduced, because instead of needing to download every transaction which has ever occurred, they only need to download transactions from the last week or so, along with the account tree which nodes are programmed to share, and they've got all they need to be a full node.
They will never have to worry about not having some old transaction which has been pruned from their disk because those transactions will never have to be referenced again. The account tree is a self contained balance sheet which tells a node essentially everything it needs to know in order to check balances and validate transactions.
Of course there are a lot of little finicky details like the inversion database which is required for undoing changes made to the account tree in the case of forking, and I would suggest reading the Cryptonite wiki if you want a deeper understanding of how it works. I tried to keep this explanation relatively simple so that it wasn't too hard to understand.
December 29, 2016, 04:53:16 PM
@bitfreak: https://github.com/pallas1/Cryptonite
Hi pallas,
Does this patch also fix the issue with the wallet crash that I mentioned earlier?
Thanks!
Sorry I don't know because I made that modification in order to compile it.
Are you using compiled windows wallet? Is it crashing at some point like when you close it or try to send coins?
I run Linux. Tried compiling the original sources. Had to change them as you can see on my fork.
December 29, 2016, 03:14:37 PM
@bitfreak: https://github.com/pallas1/Cryptonite
Hi pallas,
Does this patch also fix the issue with the wallet crash that I mentioned earlier?
Thanks!
Sorry I don't know because I made that modification in order to compile it.
Are you using compiled windows wallet? Is it crashing at some point like when you close it or try to send coins?
December 29, 2016, 03:04:19 PM
@bitfreak: https://github.com/pallas1/Cryptonite
Hi pallas,
Does this patch also fix the issue with the wallet crash that I mentioned earlier?
Thanks!
Sorry I don't know because I made that modification in order to compile it.
December 29, 2016, 02:40:37 PM
@bitfreak: https://github.com/pallas1/Cryptonite
Hi pallas,
Does this patch also fix the issue with the wallet crash that I mentioned earlier?
Thanks!
full member
Activity: 140
Merit: 100
your damned if you do, your damned if you dont lol
December 28, 2016, 08:32:39 PM
what does that response from btc38 even mean haha , i rly do like that exchange and their support for me has been good in the past so i am sure they have the best intentions , quote - "Dears. Please deposit your coin to new address(Click deposit to get a new address). Thank you. ^_^ " dears xD but yeah ...as you mention the new address does not generate . fingers crossed it gets fixed asap . The price on bter is shocking , is this whats known as a big dump?
Really happy to see bitfreak , the original dev here , allow me to say thankyou for this coin
Im guessing you have read the forum and caught up on recent things , its been a bit shakey , Im still staying hopeful things can recover . I love the mini blockchain and the m7 algorythm , it does not get near the credit it deserves ....its rly quite a shame . If you start some bounties for various things to help development I will donate within my capabilities , cheers .
Really happy to see bitfreak , the original dev here , allow me to say thankyou for this coin
Im guessing you have read the forum and caught up on recent things , its been a bit shakey , Im still staying hopeful things can recover . I love the mini blockchain and the m7 algorythm , it does not get near the credit it deserves ....its rly quite a shame . If you start some bounties for various things to help development I will donate within my capabilities , cheers . December 28, 2016, 01:16:36 PM
Hi, everybody come on coins BTC38?
The second day is no enrollment ...
And the new dipozit address is not generating...
Same thing here, I asked them and they responded
Quote
I'm sorry, it is said that XCN to increase the circulation, we are checking, if there is no will resume work on deposits.
December 28, 2016, 12:30:14 PM
Hi, everybody come on coins BTC38?
The second day is no enrollment ...
And the new dipozit address is not generating...
Jump to: