Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 142. (Read 448489 times)

Yes, one way avoid the server-trust problem is to use multiple independent data sources, so they would have to collude to perform a double-spend.

But yes, full nodes will still have to scan the full block chain. However, they should need WAY less RAM to do so, since the vast majority of it can be just thrown out once it is determined to not apply to MasterCoins.

Since unwinding bitcoin transasctions (in event of reorg) also unwinds MasterCoin transactions, I don't think anything would be needed other than a re-scan of the block-chain data.

The only reliable way to find all transactions which mention certain address is to scan all Bitcoin transactions.

So this doesn't buy you anything: you still need to read all transactions in block, parse them as Bitcoin transactions, checking whether they mention exodus address. If they don't you can skip further processing step.

This doesn't improve scalability. Maybe you'll have processing twice faster if you avoid "multipart" transactions, but processing time/download time is linear on number of transactions in blockchain.

You might be able to fetch only transactions which mention exodus address if you use centralized service like blockchain.info, but then you will depend on such service. For example, such service might omit a transaction to perform a double-spend on you.

---

If you only consider 'full node' clients (or ones using similar design), you should be concerned with what they need to keep in db and what changes they need to apply to it, not with number of transactions processed, since full node clients need to process all transactions anyway.

Say, what do you do in case of reorg, i.e. how do you unwind the state back to the point it was N blocks ago where fork happened?

One way to do this is to keep track of all changes to the state, but then you'll store the whole history...

Project update 8/19/2013

I spent a good portion of my weekend contemplating scalability, and I am pleased with my findings so far:

• MasterCoin has excellent usability early on, since the data the first 250038 blocks can be ignored (the first transaction to the Exodus Address was in block 250039)
• MasterCoin clients can safely ignore the vast majority of bitcoin transactions, since only transactions with an output to the Exodus Address need to be parsed. (For instance, no MasterCoin client will ever need to look at a SatoshiDice transaction.)
• MasterCoin scalability issues only become noticeable if the project is insanely successful. If MasterCoin transactions are the vast majority of bitcoin transactions, it will take longer and longer to parse them all. HOWEVER in that distant future, as with bitcoin, thin clients which sign transactions locally but rely on trusted servers for parsing previous transactions are a good performance/security compromise, and heavy users will invest in the hardware to run a full node locally, just as they do now with bitcoin.

In order to better support scalability, I'll be making a couple changes to the spec:

• The most important change will be that MasterCoin clients will require using sendmany, rather than having the option to send them one at a time. This means that a MasterCoin client never needs to look at ANY transactions other than those which contain the Exodus Address as an output
  • I believe that every major client (with the notable exception of the Android wallet) supports this feature. Hopefully, sendmany is coming soon to Android, but if not, I'll be sure to provide a way to transfer MasterCoins out of your Android wallet to a wallet which supports SendMany for those of you who used Android wallet to purchase MasterCoins.
• I will also change the spec so that data streams use a MasterCoin transaction to publish data (with an output to the Exodus Address) rather than just being standard bitcoin transactions. This will also improve block chain parsing and scalability.

These two changes mean that EVERYTHING needed to parse EVERY MasterCoin transaction (including every user currency transaction, every bet, every piece of data published on every datastream, every property transaction, every currency sale, etc) can be calculated just from the Exodus Address transactions: http://blockchain.info/address/1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P

Technically, even my GreaseMonkey script currently used to calculate MasterCoin purchases on that page (http://userscripts.org/scripts/show/175196) could be expanded to parse all those MasterCoin transactions! (Although that won't scale as well as native clients.)

I vote for either 1 or 6. The others are a bit too abstract but all of them are cool and you're talented for sure.

^Right, as per the white paper's subheading "The Exodus Address"

Funds can be sent to the Exodus address till the end of August – right?

What the heck, it's all about money, better kinds of money.

I am in, not greedy, just to get my feet wet. 

6769187272ebe0fae45b8c0617fead121072e3447753fa1afa47c47d5f478cd0

What the heck, it's only money. I'm in.

37992e445c33dd74a1e4e00dabb6a66f16a5d39977a1f5fd1a6c0154e884eee2

I must say that I am very intrigued by this idea. I have long since come to the conclusion that the alts have been over-run and many won't survive. BTC will though, and its because of the blockchain and its usefulness that its only getting started. I have initiated a .5BTC transaction through the Exodus address and can't wait to see where this goes!

407e0a6ae2986693c8e5d35b2e47f973af35239fc53e8561137ee5f320195682

Thank you! much appreciated.

I LOVE simplicity 

And, by the way, it's worth noting that we were aware of MasterCoin when we were designing colored coins. (Quite possible it was an inspiration, but I'm not sure.)

I've considered both proposals about a year ago, and found that colored coins are much simpler, and thus it is easier to make a robust, mature implementations.

Then we deliberately designed colored coins in such a way that it would be possible to make efficient, thin clients which won't need to scan whole chain.

Situation is still worse than with Bitcoin SPV thin clients (which need very little data to operate), but there is some room for optimization and trade-off...

Otherwise, making it similar to Bitcoin SPV would require support on protocol layer. I.e. an alt-coin with explicit colored coin support.

Colored coins allow one to create tokens which represent ownership of something, like shares, bonds, currencies, derivatives etc. Basically, whatever you want to have tradeable.

Then there is a way to trade them in a secure fashion, which opens up a possibility of decentralized, peer-to-peer trade.

There will be probably some features which are useful for stocks and bonds: paying dividends, motions, etc.

One can implement futures and prediction markets using colored coins, but there are no features specifically for that, it is up to issuer to guarantee proper settlement.

There are also some advanced features which can be used to implement currencies with demurrage, built-in taxation, etc, but it is largely theoretic now.

And that's pretty much it. MasterCoin features which require non-local interactions (i.e. transaction affects state of objects not linked to it) are not possible within colored coin model. This includes things special savings addresses, bets, and stabilized user currencies.

(Note that you might be able to implement features like that via advanced features of Bitcoin (multi-signature scripts, contracts) unrelated to colored coins. )

So, to summarize, with colored coins we deliberately avoid features which require non-local interactions. This makes things simpler.

Colored coin transactions are Bitcoin transaction, and they behave in exactly the same way. You wait confirmations in the same way as you do with normal Bitcoin payments. They are not sensitive to ordering. Double-spending is prevented by Bitcoin nodes.

This means that in comparison to MasterCoin, colored coins are:

• simpler and more reliable: colored coin kernel function is just ~15 lines of code, we only need to code review it to make sure that it works properly
• has well-understood properties which are based on Bitcoin properties: no need to wait a lot of confirmations to guarantee that transfer happened
• client needs to scan transaction history of one specific color to be able to receive it. This allows secure thin clients similar to SPV Bitcoin clients (although potentially such clients need to download much more data than Bitcoin thin clients). In contrast, to be able to work with MasterCoin you need to scan the whole Bitcoin blockchain, so thin clients will have to trust some server
• colored coins do not liter Bitcoin blockchain with unspendable UTXOs: all UTXOs which are used to represent colored coins are spendable and can (and should!) be eventually reclaimed

However, lack of non-local interactions means that we need more facilities outside of blockchain, i.e. decentralized trading requires separate communication and policies. (On the bright side, we do not liter the blockchain with offers and such, only with complete transactions.)

I also expect that off-chain trading will be used together with colored coins: i.e. trading will happen within a centralized service of some sort (potentially, Open Transactions) and colored coin transaction will be used only to settle the balance periodically.

It can be more-or-less secure as it is possible to use Bitcoin features such as multi-signature scripts and contracts together with colored coins.

Oh, and you cannot invest into colored coins in general: it is open source software, not a currency. You might be able to invest into a company which develops colored coin software, though.

HTH

Thank you very much for the transaction.

I was about to ask for a more detailed description, but I realized it's already here 

Sorry for the ignorance, but can someone tell me what's  the main difference between the capability of Mastercoins and Colored Coins?

I.E. what Mastercoins can do while the Coloredcoins can't, or vice versa.

I always appreciate tips! my address is in my sig. Thank you, sir.

[edit] also, while i'm posting something might as well point out this unicode looks really cool. Ѫ
I know, gettin' waaaaay ahead of everything. Just sayin' [edit]

i love them! the pyramid ones are great too. can i send you .1btc as appreciation?

What is your expectation for "release" of the wallet and opening of transaction for those who have sent BTC to the exodus address?

Thanks! Here are a couple more added to the b/w sketches. I tried to go for an abstract representation of the parting of the red sea (exodus). Definitely not explicitly that because i tried to design it into an "M", but hopefully you can see it.  




Whichever one is chosen, I'll provide vector/png formats for them and release them as open source. As far as what logos seem to be going for, I'm happy with whatever donations people would like to offer. Logos range in price so I don't really have a specific number, but typically it's between 1-2 btc.   Obviously I'd love to have access to some mastercoins so that would be great too, except I would have to download the client onto my desktop, right?

I don't feel like reading the whole white paper but this has piqued my interest ... is there a summary of how MasterCoins is supposed to work?

So far by osmosis I got;

- it is piggy-backing transactions onto bitcoin blockchain somehow to achieve something like coloured coins functionality

- you can make other master sub-coins that have in built auto-regulators for issuing based on supply-demand/pricing (where are the market operations taking place?)

- dacoinmeister is getting a ton of btc sent to an address controlled by him (and his wife if he dies) to do the dev work
 - if you don't get in now and send coins to dacoinmeister now you will miss out on the great early adopter mastercoin gold rush