Yea there seems to be a bunch of problems surrounding this project, the main developer AWOL and not much of a community. However, the technology does work pretty good, considering that it has been running for over a year and (with a bit of luck) one can have it up and running, fully synced, within half an hour. Impressive!
In comparison to the actual working concept, the bugs and problems appear pretty minor.
Yeah, I wish I knew enough of the code to understand how portable this is to bitcoin. I know the blockchain mechanisms were somewhat modified to an account-style system, but essentially how difficult would it be for bitcoin to integrate whats been done here? I mean, thats been the concern with alt coins built from bitcoin (well, speculative concern). But I don't know how much has been changed and if it would be possible to merge... upstream?
Hello guys, sorry I haven't been around for a while, been spending most of my waking hours working on another project, but that is pretty much finished now, and at least I gained quite a bit of C++ experience from it. I will now try to focus the majority of my time on improving Cryptonite and try to get the web wallet released some time soon.
I saw that the market cap for XCN climbed back into the top 100 a couple of weeks ago so that has given me some motivation to keep this coin alive if I can. But like I said my abilities are still quite limited and if there is any team willing to take over this project so that it's not left alone when I'm not around, that would probably be for the best.
I also cannot keep funding the explorer and other services forever unless we can figure out some sort of funding scheme. At this point it seems to me, if mining pools want XCN to stay alive, one or more of the pools should participate in an agreement to fund development of Cryptonite by diverting a fraction of their XCN profits to that cause.
Now let me attempt to answer some of your technical questions, although it's been a while since I brushed up on my cryptocoin knowledge. Bitcoin did adopt a sort of limited pruning system not too long after Cryptonite was released but there are some critical differences which make Cryptonite more scalable, that's why it syncs so fast if you manage to make it sync correctly.
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.
