[ANN][XCN] Cryptonite | 1st mini-blockchain coin | M7 PoW | No Premine

[mikenz]

Bitfreak, you are an excecllent dev and your communication with the community is exemplary. I just tipped you some XCN and hope others will do so too. looking forward to Cryptonites rise once the public realizes its capabilities. may it take more time, even a few more months, I dont mind

[bitfreak!]

What size would the trie be if it had as many accounts as bitcoin currently does?

I'd need to know how many non-empty bitcoin addresses exist, which isn't exactly an easy task. I did these calculations a while ago but I'd have to go back and find it. I believe there are 3844 non-empty addresses in the Cryptonite network right now and the trie is currently about 150kB.

[argon1]

Bitcoin discourages small transctions by charging a fee.
Cryptonite does not have a problem with small transactions at all but it seems there is concern over the number of accounts.
Yet Bitcoin recommends creating a new account for every transaction for improved security and privacy.
Could cryptonite have an issue with too many account at some point in the future?

[bitfreak!]

Bitcoin discourages small transctions by charging a fee.
Cryptonite does not have a problem with small transactions at all but it seems there is concern over the number of accounts.
Yet Bitcoin recommends creating a new account for every transaction for improved security and privacy.
Could cryptonite have an issue with too many account at some point in the future?

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.

[kalon]

Beyond Bitcoin interview with Bitfeak is out!
http://letstalkbitcoin.com/blog/post/beyond-bitcoin-18-cryptonite

 Bitfreak, great job of explaining the features and benefits of the system! I hope everyone takes the time to check it out.  

[Equality 7-2521]

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

[bitfreak!]

Beyond Bitcoin interview with Bitfeak is out!
http://letstalkbitcoin.com/blog/post/beyond-bitcoin-18-cryptonite

 Bitfreak, great job of explaining the features and benefits of the system! I hope everyone takes the time to check it out.  

Yeah I thought the interview went quite well. There are a few interesting bits cut out of the published version but overall I think Arthur did a good job of editing and cutting out the irrelevant parts. I should also amend one incorrect comment I made near the end of the discussion. I said the maximum transaction rate for bitcoin is 7 tx's per block which is obviously too low, it's 7 tx's per second.

[CasualSam]

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.

[ltcnim]

Beyond Bitcoin interview with Bitfeak is out!
http://letstalkbitcoin.com/blog/post/beyond-bitcoin-18-cryptonite

 Bitfreak, great job of explaining the features and benefits of the system! I hope everyone takes the time to check it out.  

Yeah I thought the interview went quite well. There are a few interesting bits cut out of the published version but overall I think Arthur did a good job of editing and cutting out the irrelevant parts. I should also amend one incorrect comment I made near the end of the discussion. I said the maximum transaction rate for bitcoin is 7 tx's per block which is obviously too low, it's 7 tx's per second.

extremly good interview. very informative! make sure to put it on the main page so everyone can see it!

[bitfreak!]

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

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?

[bitfreak!]

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.

Awesome news, CasualSam is the man.

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.

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.

[Equality 7-2521]

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

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.

[CasualSam]

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.

Oh yeah I think I get you. I'm still pretty clueless about how the trie works, but what if instead of aliases for an account the names were legitimate account addresses? Basically you wouldn't differentiate between a namehash and a pubkeyhash, either could be used for trie lookup but they represent different types of accounts. A 'name' account would have a stored pubkey (or pubkeyhash), but you would only be able to pay to the name. To spend you provide the name and a sig (verifiable against the account's pubkey), so again the trie lookup would be the same namehash/pubkeyhash search. Would that work or have I been up too long?

EDIT: This is the account structure which may clarify

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

[bitfreak!]

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.

[bitfreak!]

Oh yeah I think I get you. I'm still pretty clueless about how the trie works, but what if instead of aliases for an account the names were legitimate account addresses? Basically you wouldn't differentiate between a namehash and a pubkeyhash, either could be used for trie lookup but they represent different types of accounts. A 'name' account would have a stored pubkey (or pubkeyhash), but you would only be able to pay to the name. To spend you provide the name and a sig (verifiable against the account's pubkey), so again the trie lookup would be the same namehash/pubkeyhash search. Would that work or have I been up too long?

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.

[CasualSam]

Oh yeah I think I get you. I'm still pretty clueless about how the trie works, but what if instead of aliases for an account the names were legitimate account addresses? Basically you wouldn't differentiate between a namehash and a pubkeyhash, either could be used for trie lookup but they represent different types of accounts. A 'name' account would have a stored pubkey (or pubkeyhash), but you would only be able to pay to the name. To spend you provide the name and a sig (verifiable against the account's pubkey), so again the trie lookup would be the same namehash/pubkeyhash search. Would that work or have I been up too long?

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.

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
}

[bitfreak!]

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
}

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.

[CasualSam]

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

[Equality 7-2521]

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.

This discussion about Counterparty and MBC is slightly deviating from my original intent of engaging you with regard to Side-Chains and MBC. The Counterparty MBC application is just an example.

Yes Counterparty Messages (https://github.com/CounterpartyXCP/Counterparty#message-types) use scripting but certain activities could be offloaded to a side-chain. For example, Counterparty has an in-built decentralized exchange which uses the Order Message. These messages could be offloaded to an MBC side-chain for fast order matching. Periodically, the results of the trades on the side-chain could still be embedded in the Bitcoin Blockchain like they are currently doing.

Again, I need to stress that I am talking about using both the Bitcoin Blockchain and an MBC at the same time to complement each other. The MBC would ephemerally store recent data and offload the balance of this data back to the Bitcoin Blockchain.

[bitfreak!]

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.