Topic: [ANN][XCN] Cryptonite | 1st mini-blockchain coin | M7 PoW | No Premine - page 57. (Read 578501 times)

I just listen the  interview on the Beyond Bitcoin. Very good job bitfreak.

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.

https://github.com/monero-project/bitmonero/commits/master?page=3

https://twitter.com/monerocurrency/status/519850497323196418

https://bitcointalksearch.org/topic/m.9190733

These steps were the result of BCX the evil supervillain forcing evolution through a threatened Timewarp attack.

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?

I gave it a listen; great job BF.  Nice to hear the voice behind the coin, and especially delightful to discover BF is a fellow Discordian (FNORD)!   

The fascinating (Hidden Troll Chain Surprise) attack vector vs scalability trade-off discussion prompts me ask about the applicability/possibility/priority of incorporating Monero's advanced new checkpointing techniques into XCN.

Distributed democratic polymorphic blob-based hybrid checkpointing sounds like exactly the kind of BCX-TimeWarp-defeating Gallifreyan alien tech I expect to see in XCN.   

I like both ideas, although the domain aliasing seems like a (minor) PITA.  The Namecoins I spend landgrabbing and squatting on .bit domains never turned a profit, but human-friendly vanity addresses are still very popular with the kids nowadays.   

Since Namecoin is merge-mined with BTC and thus very secure and more decentralized than (higher barrier to entry) ICANN DNS, perhaps we should just register one .bit address to store/resolve all of our various coin addresses?  EG [btc/ltc/xpm/xmr/bbr/xdn/via/xcn]:bitfreak.bit

The land-grab (but not cybersquatting) may be curtailed by only allowing block solvers to register aliases.  BBR uses this constraint and limits alias creation to one per block, which also creates an additional incentive to solo mine.  OTOH, pools could create an additional revenue (and dev donation) stream by offering alias registration services via flat-rate, priority, or auction based pricing mechanisms.

Great! That's what I was thinking. In hindsight, that particular interview doesn't discuss the fundamentals of the Counterparty Protocol enough. This episode of Lets Talk Bitcoin might be a better on-ramp - http://letstalkbitcoin.com/blog/post/ltb109-the-ideal-counterparty.

It would be really great to see that example of an MBC enabling a faster and more efficient (less Bitcoin Blockchain bloat) decentralized exchange/market side-chain!

I'll give you a chance to think about some of this. I'll re-iterate that the Counterparty Devs are great guys and really approachable, as you also seem to be, so I think you guys could have some great conversations. Drop me a PM when you're ready to chat.

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

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.

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.

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

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.

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
}

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.

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
}

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.

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?