Hmmm looks like you've found some sort of bug in the block explorer. I'll look into it shortly.

No, it's because those shitcoin people spend all their time and money on promotion and marketing so that their premined coins can be sold for a hefty profit. All they care about is whether or not people buy their coin and push the price up. And it's sad because many of the top ranking coins are not there due to their innovation or merit, but simply because they had a strong marketing campaign.

My main focus is not promotion because I don't treat Cryptonite like a business. But I am doing what I can to spread awareness of Cryptonite, I've done several interviews and most recently my goal is to get XCN accepted by one of the altcoin payment processors so that I can create a market around XCN and give people a reason to own XCN apart from just holding and hoping the price goes up.

Cryptonite is and always will be an open source community project, not a company owned by anyone. There will never be a "Cryptonite Foundation" because history shows that those types of centralized organizations are easily corrupted and are the antithesis of P2P technology. My point is, this is a community effort, don't expect us to do everything. We are all responsible for the success of Cryptonite.

Well at the moment I'm trying to strike up a deal with an altcoin payment processor. If any payment processor is willing to accept XCN payments, then in return I will add support for their gateway to BitShop, which will bring them a lot of new users. The main goal is to create a marketplace around XCN but it would benefit all parties involved. BitShop stores will be able to easily accept a large range of different altcoins instead of just Bitcoin. I've thought a lot about it and adding a separate API for each new altcoin I want to add to BitShop is simply not a feasible task, especially when most altcoin web API's are not using secure connections. In order to make BitShop support a large range of altcoins I need to add support for an altcoin payment processor.

Well I was unable to contact coinpayments.net directly because they don't provide a contact email address, but I was able to use their coin request form and told them that I have a proposal which will benefit all parties involved. Hopefully they will respond soon, but if anyone knows of any other good cryptocurrency payment processors which accept a wide range of coins, let me know and I will send them the same proposal.

I believe 5.3 should work, give it a try and see. But to be on the safe side you should build with 4.8.

You can donate to either of these addresses:
XCN: CcFE7EWRuBVe4FrJoVJyEeW5GvZZ4spNqN
BTC: 15XvdRtPpon1wxx4SeNbR4WZtU5mdE8A5S

I'm hesitant to repost the XCN announcement on other forums because I don't have the time to keep track of multiple Cryptonite threads on different websites. I'd rather most discussion was kept to this thread until I create our own official forum. But if you want to repost the XCN announcement in other places don't let me stop you.

Well I believe the blocks are downloaded and validated in a simultaneous fashion, so it's not quite that simple. I think it's mainly just because there are faster Bitcoin seed nodes which allow the blockchain to be downloaded at very fast speeds but there are several different factors playing a role.

Try running -resync and adding the nodes listed below. If all else fails then sync using cryptonited and then once fully synced switch to cryptonite-qt. For some reason the sync process in Qt seems to be a bit buggy, especially on Windows.

47.55.147.150:8253
174.6.46.186:8253
66.45.239.67:8253
217.129.141.209:8253

Like I said, unless you wait several weeks you wont really notice any advantage. Syncing once per week is the same as syncing once per day overall because you're not skipping any blocks unless you wait more than a week. If you wait more than a week before resyncing that's when you will see a difference because it will only download the last 10k blocks. Stay offline for 10 years and try to sync and it will still only download the last 10k blocks (and account tree), but that doesn't mean it's missing any data, it can still be a full node and do anything a full node can do because of the way the account tree summarizes the entire state of all addresses and since transactions become instantly spent when applied to the account tree.

Ok I have finally finished a job I was doing for a client, so now I should have much more time to work on Cryptonite stuff. One good idea I have is to add XCN support to my BitShop script so that all existing shops using my script can sell products for XCN. I will ask an altcoin payment gateway such as coinpayments.net to accept XCN and in return I will add support for their gateway to BitShop, which will bring them a lot of new users. That way I can create a fairly good marketplace around XCN quite quickly.

But the question I have is how does it store that data in the blockchain? I'm guessing it must use normal tx's which use scripts, which clearly cannot work with Cryptonite. If it's just storing extra arbitrary data in the blockchain then it may be possible. We have a message field attached to all transactions so we may be able to use that, but I believe the length of the message field is limited to 64 characters so the AT programs would be limited in length.

EDIT: just did some brief reading on AT and it seems to me like it would require rather large changes and extensions to our protocol. It would also require extra data related to the execution states of AT's to be stored in each block and it's highly problematic to prune old AT data. It seems like a fairly complicated and bulky system which would hurt the ultra scalable system that we have now.

@chompyZ: the following quote is not quite true. I don't know exactly how the AT stuff works, but I highly doubt it's compatible with the mini-blockchain system because we don't have any scripting capabilities, let alone Turing complete scripting.

Well in that case there isn't much difference between what they need to do. If you wait like a few weeks then Cryptonite should definitely win, because Cryptonite will only attempt to download the last 10k blocks, but Bitcoin will attempt to download every block it has missed. Bitcoin may have been faster in your test simply because there are more bitcoin seed nodes or because Cryptonite lost a few minutes downloading the trie.

EDIT: actually it's also very important to remember that Cryptonite has a block rate of 1 per minute where as Bitcoin is 1 every 10 minutes, and that's probably why Bitcoin won in your test, because there were less blocks to download. But like I said Cryptonite will still win if you wait a few weeks and run the same test because Cryptonite only needs to download the last 10k blocks regardless of how long you stay offline.

Well I'm not sure what they mean when they say "a loosely distributed checkpoint alert system" but I'm guessing it's some sort of decentralized checkpoint system, which might be a plausible solution to the Secret Chain Attack. We could release a new checkpoint hash each week but then users would have to trust our decision about which chain is the right one and that could introduce an unwanted level of centralization, which is why a decentralized or "distributed checkpoint alert system" could be an interesting solution. But when they say "loosely distributed" it gives me the impression there's still some level of centralization in the Monero checkpoint alert system. There doesn't seem to be a whole lot of technical information on how it works.

Lol yeah I was expecting him to edit out that first part of the convo but I'm glad he didn't, everyone should read Principia Discordia.

I did mention "community checkpoints" some where near the end of the discussion. Where can I read more about this Monero checkpointing?

Ok that makes it much clearer for me. The account tree structure is particularly useful for acting as a dynamic balance sheet as it does in Cryptonite, and if you need to store that type of data in a decentralized way then a MBC type of scheme is probably a good approach. I'll listen to that Beyond Bitcoin discussion you linked to when I have some time and learn more about Counterparty.

Well having human readable addresses is actually a pretty big problem in cryptocurrency and the solution you suggested is workable, so I agree it's pretty neat. Maybe if we had thought of that solution back when we were thinking about this issue we would have implemented it, but the changes necessary to make it work are too extensive to apply them now.

Yeah I see what you're saying and I think it could work, but not with our current protocol obviously. The AccountKey in your example should never change since it's used for lookup, so we would need a special type of transaction which would allow users to create a new account in the account tree using a custom AccountKey. This would essentially allow multiple accounts to exist which all have the same pubkeyhash but use a different namehash and that could be problematic. And as I mentioned you also need that extra redundant field which is only required when using a namehash. But I guess that's not such a bad trade off for having human readable addresses.

Well it seems to me what you are suggesting would have the same difficulty as generating vanity addresses because the public key and address is derived from the private key. I think you sort of need to understand how account lookup works to understand the problem. Something like your idea may possibly work but it would probably require extra redundant data to be stored in each account and I don't think you'd be able to change the alias once you created it.

Well my main question would be, what are Counterparty transactions/operations and do they use scripting? The main idea of the MBC scheme is that we can forget about old transactions because we don't link together tx's with scripts. If old Counterparty transactions cannot be forgotten in such a way then a MBC type solution may not be appropriate.

Awesome news, CasualSam is the man.

We actually had some fairly in-depth discussions about that idea but ultimately decided it wasn't tenable. The main problem is that when you need to lookup an account in the account tree with only an alias you have to basically search through every account until you find it because you can't use the fast lookup properties of the trie structure. The same sort of issue also applies when registering an alias, other nodes basically have to check every other registered alias and make sure the alias in question hasn't already been registered. I believe there were also some other issues with the idea but I can't remember them off the top of my head.

Well to be honest I don't know much about merged mining or Counterparty so I'll have to do some reading. Are you suggesting something which would merge with Cryptonite or an independent application of MBC technology to make Counterparty more scalable?