|Complete Mastercoin Specificiation||J.R. Willett||7/31/13 7:59 AM|
Here's a sneak peak at the complete MasterCoin specification: https://sites.google.com/site/2ndbtcwpaper/MasterCoin%20Specification.pdf
I spent a lot of hours on it, and it is ready to go. I've been privately circulating it among bitcoin experts since Monday, with positive responses.
MasterCoins will be available for sale soon, and I hope it will make a big splash
|Re: Complete Mastercoin Specificiation||Stan Stalnaker||7/31/13 8:28 AM|
Hey is everyone aware of DATA - just announced this week - http://DATAuthority.org
|Re: Complete Mastercoin Specificiation||J.R. Willett||7/31/13 12:19 PM|
|Re: Complete Mastercoin Specificiation||Yoni Johnathan Assia||7/31/13 3:05 PM|
Great paper ! Awesome work JR !
|Re: Complete Mastercoin Specificiation||Yoni Johnathan Assia||7/31/13 3:22 PM|
Will you have a mastercoin wallet by the 31st of August ? So people can receive their master coins ?
I assume I send to exsodus address, after I recieve mastercoins to the sending address, since its on the btc network they must have btc value.
|Re: Complete Mastercoin Specificiation||Gil Ariel||7/31/13 9:21 PM|
This is awsome. I suggedt you prepare a short youtube video showing how exactly to transform the bitcoin into a mastercoin.
If you do so i'll transfer 3-5 bitcoins just to check it :)
I wouldn't wsnt to accidently loose my money in the process.
|Re: Complete Mastercoin Specificiation||Alex Mizrahi||8/1/13 2:26 AM|
Well, I see a problem: MasterCoin transactions are not linked together in a subgraph, so one needs to scan the whole Bitcoin blockchain to interpret them.
This means that thin clients are fundamentally impossible.
You are going to have either full clients (like Bitcoin-Qt) which download whole blockchain (8+ GB of data now).
Or server-trusting client, which undermines the whole point of having cryptocurrency. (If you are into that, just use Open Transactions: low overhead, impressive features.)
We discussed this topic in this mailing list, see discussion with Paul Snow and 'theory of colored coins'/'advanced color states' threads: you have to confine transactions to subgraph to make it friendlier to thin clients.
(It is hard to say whether it is friendly enough, but at least we have a chance to optimize and make trade-offs to make it acceptable... I don't see how it is possible with global messaging model without making it reliant on trusted servers.)
You can implement many MasterCoin features using colored coin model with advanced color states.
Or you can at least confine special transactions to a subgraph, so thin clients will have a chance to exist until MasterCoin transaction volume becomes high...
|Re: Complete Mastercoin Specificiation||J.R. Willett||8/2/13 12:26 PM|
Sorry I haven't responded here. The Youtube idea is cool, but since I already have a Youtube video which talks about the idea from the conference, I'll probably put that off.
The block-chain scanning requirements are a lot lower considering that I only need to scan transactions that reference the Exodus Address, but thin client type solutions are going to be needed eventually.
Please put any questions you have I didn't answer on that thread on bitcointalk so that everyone can benefit from the answers. Thanks!
|Re: Complete Mastercoin Specificiation||Alex Mizrahi||8/2/13 12:50 PM|
The block-chain scanning requirements are a lot lower considering that I only need to scan transactions that reference the Exodus Address,
You need to scan whole blockchain to find all transactions which reference the Exodus Address.
Blockchain is a flat list of transactions, they aren't grouped by address or anything. And you need to process transaction to see which addresses it references.
You might use bloom filter feature to reduce traffic, but then you're at mercy of network nodes you've connected to: they might just 'forget' to send you some transactions, which might be used to rob user.
For example, suppose address XYZ has 100 coins. I will first send 100 coins to address ABC, and later 100 coins to address DEF.
Of course, second transaction is invalid, but if DEF's node haven't seen the first one, it will recognize second as valid...
Thus: unless you scan whole blockchain, you depend on honesty of nodes you've connected to.
I don't think there can be a solution if protocol is simply not designed with thin clients in mind.