Micro-transactions are fine in most cases but unlike Bitcoin we tend to discourage arbitrary creation of new addresses, which is why it's harder to send micro-transactions to addresses which don't already exist in the account tree. When we get millions of non-empty addresses the account tree may grow to a few gigabytes in size, but we're talking possibly decades or more before we actually hit the 1GB mark. The trie structure used should be perfectly capable of handling such large numbers.

Somebody talk to me about side-chains and merged-mining in the context of Cryptonite. This is tremendously exciting!

I would like to launch a Mini-Blockchain side-chain of the Counterparty Protocol. This MBC would be Complementary to the embedded Counterparty Protocol data in the Bitcoin Blockchain. This side-chain wouldn't necessarily have to store all of the Counterparty Protocol data.

See here for more information - https://forums.counterparty.io/discussion/418/the-crossparty-protocol#latest

Finally got some time to work on my open source xcn pool. Should be looking for beta testers in a couple of days if anyone is interested. There will be a 2% fee with all proceeds going to the cryptonite fund.

Here is a separate idea about aliased account names:

A pretty obvious extension of the account tree system is to offer aliased accounts. Basically someone could associate an alias with a cryptonite address and then payments could be sent to the alias instead of the address.

So instead of:

SEND 10 XCN TO CYsvPpb2YuyAib5ay9GJXU8j3nwohbttTz

You would have:

SEND 10 XCN TO xcn:bitfreak

A couple of problems with this approach: account tree bloat because of a potential land-grab of aliases and cybersquatting of aliases (anyone could register xcn:microsoft for instance). For these and possibly other reasons I don’t think this is a good idea.

Domain aliased accounts

A domain alias is a domain name you own that you use as your cryptonite address. Bitfreak owns bitfreak.info so he could use xcn:bitfreak.info as his cryptonite address.

To do this he would:
1. Create a new pub key pair and sign “xcn:bitfreak.info” with the private key
2. Add a new txt record to the bitfreak.info dns that resolves to the “xcn:bitfreak.info” signature
3. Create and submit a new ‘Register Alias’ transaction which includes the pub key and the domain alias.
4. Once the transaction is submitted every node checks that that there is a txt record associated with bitfreak.info with a signature that can be verified against the pub key.
5. Once included in a block the domain alias is stored in the account tree until it is removed or altered (using a similar process). Once the alias is added, the txt record can be removed and no more dns lookups are required.

That is the basic idea. Some other crypto scheme may be better.

Benefits:
* User friendly addresses. If I want to buy something from ‘fancyhats.com’ then I pay ‘xcn:fancyhats.com’.
* Promotional payments. It could be possible to pay to domains that don’t have a cryptonite account. Funds would be stored until a domain performs a registration transaction. Say I donate 10,000XCN to savetheplanet.com, savetheplanet would only be able to access the funds by registering. Once registered and having learned about cryptonite, savetheplanet may likely add xcn as a payment option.
* Encourages reuse of accounts so possibly less account tree bloat
* For non-domain owners a service could offer custom personal aliases. I would give my signature, pub key and name to the ‘xcnpal.com’ service and it would automatically create and register something like xcn:sam.xcnpal.com. With the right rules xcnpal would not need to be trusted. Even if the domain were hacked or expired, xcn:sam.xcnpal.com could not be modified without my permission.

Negatives:
* Requires all nodes to support domain aliases before it could be used.
* Effort is required to initially establish a domain alias. It is similar to setting up google mail for a custom domain.
* May not be worth the effort to implement. While I think the scheme works and is somewhat interesting, I’m not sure it would be a big enough selling point to justify doing it.

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?

Thanks for the reply. In your Beyond Bitcoin interview it stuck me just how highly you regarded your lead developer. I think you will find that the Counterparty Protocol developers are similarly gifted and hard working. They are also very accessible and they would surely be interested in communicating with you and your team. The previous Beyond Bitcoin episode was an interview with one of them - Robby Dermody - and listening to it might give you a good introduction to Counterparty technology - http://letstalkbitcoin.com/blog/post/beyond-bitcoin-17-counterpartying-with-robby-dermody.

Counterparty does not have a dedicated Blockchain of it's own - all of it's data is stored embedded within the Bitcoin Blockchain. From the start the Counterparty team have done their best to be good stewards of the Blockchain, avoiding complications and bloat where possible. By being embedded in the Blockchain Counterparty inherits all of the Bitcoin Network's security. One downside to this is that Counterparty Protocol operations take as long as Bitcoin transactions - approx. 10 minutes.

What I am suggesting is exactly as you phrased it - an independent application of your MBC technology to make Counterparty more scalable. But the clever bit is that the Counterparty Protocol could then use both the Bitcoin Blockchain and this independent Mini Blockchain simultaneously. I think MBC tech is the perfect fit for these side-chain or complementary-chain solutions.

Let me know what you think. Feel free to ask me any questions.

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.

Don't think bitcoin . A namehash can be the key to account just the same as a pubkeyhash. An account with a namehash as the key would also need to store the pubkeyhash for crypto purposes, just not for lookup.

I edited my above post with an example account structure you may not have seen:

Account{
    uint160 AccountKey (either pubkeyhash or namehash)
    uint160 PubKeyHash (only required for namehash)
    uint64 Balance
}

Yep you got it exactly. Haven't thought about implications of accounts with same pubkeyhash. Anyway it is nothing revolutionary but still pretty neat I reckon

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.

I think you could almost almost implement it without forking, but obviously all nodes would need to be updated before it could be used.

Otherwise I'll have to add it to my spacebucks research coin