MasterCoin: New Protocol Layer Starting From “The Exodus Address”

[grazcoin]

The distributed architecture uses a new type of bitcoin node. Not the "satoshi reference client", but an obelisk server. The obelisk server implements the bitcoin protocol using libbitcoin and participates in the network like other nodes. The great thing about this new server is that you can ask it complicated questions about the blockchain, e.g. get-history of an address, monitor and address, get-utxo for a specific address, fetch specific transaction, etc. It means that there is no need to hold a database and parse the blockchain for bitcoin information.

Why do you think it is a good idea to use obelisk servers as a source of information?

If you query history for an address, you cannot verify whether servers gives you all information.

This means that people who control these servers can easily perform double-spends by hiding send-to-self transactions.

The need to trust servers, is bad, but the bigger problem with it is that you don't know who runs these servers, and so there is no accountability.

The obelisk server is open source, and I just run my own locally (just like people run bitcoind). You can do that as well, or just compare results from few obelisk servers.
A mastercoin user checking mastercoin-explorer.com or some other similar centralized-database-driven web-based source has an inferior position. If that central server is hacked, the user would see wrong information, which can be used to trick him.
On the other hand, having a local copy of masterchain.info (e.g. directly from github) and running a sync to a chosen obelisk server (even a local obelisk server), gives you for sure results directly from the blockchain which is the single consensus.
The more obelisk servers will appear (keep in mind that the project is still very new - 3 days ago was the first release https://github.com/spesmilo/obelisk/tree/0.2), you would have more nodes to choose from so that a higher trust level would be achieved.
I would like to remind that the obelisk simply implements the bitcoin protocol, just like bitcoind does.

[1713498546]

1713498546

[1713498546]

1713498546

[1713498546]

1713498546

[1713498546]

1713498546

[1713498546]

1713498546

[killerstorm]

The obelisk server is open source, and I just run my own locally (just like people run bitcoind).

So you run a local server, which has database and everything, but you call it:

• Fully distributed architecture - no need for database or webserver.

Got it.

The more obelisk servers will appear  you would have more nodes to choose from so that a higher trust level would be achieved.

No, it doesn't work this way. Have you ever heard about Sybil attack? ( http://en.wikipedia.org/wiki/Sybil_attack )

Lots of servers which are run by anonymous people on the internets won't help you. If you believe that it is unlikely that there will be a collusion among several independent server operators, then you need to be sure you connect to servers which are run by certain operators, and follow certain policy.

For example:

1. Suppose there are 10 servers operators of which are well known and it is believed that they are fully independent.
2. When you check whether Mastercoin transaction is correct, you request information from all of these 10 servers.
3. If less than 5 of them respond you abort immediately.
4. Each response is signed with server's unique private key.
5. If all of response agree, you assume that responses can be trusted and proceed with transaction validation.
6. If they disagree, you abort the procedure and save signed responses.
7. There will be investigation, and servers which produced wrong responses without a good excuse (e.g. well known bug in software) will be excluded from the list permanently.

[ripper234]

Yeah, these are good points, thanks killerstorm for putting my thoughts into writing
This was just too good to be true and the architecture details indeed didn't show a distributed architecture, I was just too busy with other matters to dive into the details.

I still think it's a good project, don't get me wrong, it just shouldn't be called a "fully distributed architecture", because it is not a.t.m. - you manually choose one or more servers and work with them.

It can be decentralized further in the future, perhaps something like what Ripple are doing with their server selection algorithms (forgot the name of the "server list" feature).

[troiste]

Hi,

I sent some BTC to that exodus address in mid August, how do I get my 100x Master coins?

Thanks!

[grazcoin]

The obelisk server is open source, and I just run my own locally (just like people run bitcoind).

So you run a local server, which has database and everything, but you call it:

• Fully distributed architecture - no need for database or webserver.

Got it.

I said I run myself an obelisk server, but you don't have to. You could use the open obelisk server that the known bitcoin developer Vitalik Buterin runs, or any other (well, the list is still short ...)
I don't call running a local obelisk server distributed.
I am calling distributed the option to use any remote obelisk server, as well as the option to run one yourself.

Indeed at this point the client-server certificates are not implemented yet, but they are on the pipeline.
Obelisk is still a very young project, but just check how fast it gets developed.
Running a server myself is the workaround for the trust, but this should be solved soon.

The more obelisk servers will appear  you would have more nodes to choose from so that a higher trust level would be achieved.

No, it doesn't work this way. Have you ever heard about Sybil attack? ( http://en.wikipedia.org/wiki/Sybil_attack )

Lots of servers which are run by anonymous people on the internets won't help you. If you believe that it is unlikely that there will be a collusion among several independent server operators, then you need to be sure you connect to servers which are run by certain operators, and follow certain policy.

For example:

1. Suppose there are 10 servers operators of which are well known and it is believed that they are fully independent.
2. When you check whether Mastercoin transaction is correct, you request information from all of these 10 servers.
3. If less than 5 of them respond you abort immediately.
4. Each response is signed with server's unique private key.
5. If all of response agree, you assume that responses can be trusted and proceed with transaction validation.
6. If they disagree, you abort the procedure and save signed responses.
7. There will be investigation, and servers which produced wrong responses without a good excuse (e.g. well known bug in software) will be excluded from the list permanently.

Thanks. I wasn't aware of term Sybil attack, but it is clear that without an extra layer of trust, multiple servers do not help much. I meant multiple trusted operators.
I am also not a developer of the obelisk server, but as I understand, this example that you describe is being currently implemented (signing with server's key).

So maybe the "Fully distributed" is not correct at this point of time, but I think distributed is fair enough, and potentially "Fully distributed" would be also OK, depending on the development of the obelisk server.

I want to see some other project achieves such level of "distribution" with the the common local-parse-blockchain-on-your-database approach. They could try to implement something using blockchain.info (closed source) API, but then they have a single point of failure. The bitcoind alone is simply not flexible enough for the job. Masterchain on the other hand, just let some distributed open source powers to do that job.

[grazcoin]

1. Suppose there are 10 servers operators of which are well known and it is believed that they are fully independent.
2. When you check whether Mastercoin transaction is correct, you request information from all of these 10 servers.
3. If less than 5 of them respond you abort immediately.
4. Each response is signed with server's unique private key.
5. If all of response agree, you assume that responses can be trusted and proceed with transaction validation.
6. If they disagree, you abort the procedure and save signed responses.
7. There will be investigation, and servers which produced wrong responses without a good excuse (e.g. well known bug in software) will be excluded from the list permanently.

I am also not a developer of the obelisk server, but as I understand, this example that you describe is being currently implemented (signing with server's key).

More on obelisk development pipeline regarding certificates (I just asked the main developer, and he replied with these links):

• http://hintjens.com/blog:39#toc8
• http://hintjens.com/blog:53
• https://github.com/caedesvvv/zmqproto

[ripper234]

Hi,

I sent some BTC to that exodus address in mid August, how do I get my 100x Master coins?

Thanks!

You already have them.

See:

http://wiki.mastercoin.org/index.php/FAQ#How_do_I_see_my_Mastercoins.3F
http://wiki.mastercoin.org/index.php/FAQ#How_do_I_send_Mastercoins.3F

[killerstorm]

I want to see some other project achieves such level of "distribution" with the the common local-parse-blockchain-on-your-database approach. They could try to implement something using blockchain.info (closed source) API, but then they have a single point of failure. The bitcoind alone is simply not flexible enough for the job. Masterchain on the other hand, just let some distributed open source powers to do that job.

JFYI there were a plenty of alternatives which can do more-or-less the same: Abe, electrum-server, bitcoinjs-server. So it isn't like obelisk is some unique piece of software.

Electrum uses a network electrum-servers for about a year now.

[zathras]

Hey guys, i was wondering why masterchest.info and master coin block explorer show me having a different amount of master coins
300 master coins have shown up  on master coin explorer

http://mastercoin-explorer.com/addresses/1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC

however only 50 on  masterchest.info

https://masterchest.info/lookupadd.aspx?address=1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC

They are both the same adress

Why is this ?

Hi bitwhizz,

Transaction 2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee is no longer showing in masterchest.info.  You received 250 MSC in this transaction, hence the discrepancy in balances between mine & Tachikoma's implementations.

This does look like a valid transaction - perhaps I may have introduced a bug in my latest update which is causing this particular transaction to be dropped as ambiguous - thanks for testing & I'll do some bug hunting when I get off work and get it corrected.

Thanks

[zathras]

Hey guys, i was wondering why masterchest.info and master coin block explorer show me having a different amount of master coins
300 master coins have shown up  on master coin explorer

http://mastercoin-explorer.com/addresses/1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC

however only 50 on  masterchest.info

https://masterchest.info/lookupadd.aspx?address=1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC

They are both the same adress

Why is this ?

Hi bitwhizz,

Transaction 2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee is no longer showing in masterchest.info.  You received 250 MSC in this transaction, hence the discrepancy in balances between mine & Tachikoma's implementations.

This does look like a valid transaction - perhaps I may have introduced a bug in my latest update which is causing this particular transaction to be dropped as ambiguous - thanks for testing & I'll do some bug hunting when I get off work and get it corrected.

Thanks

Transaction actually not being dropped in my implementation - something else is up, diagnosing now.

Code:

select * from transactions_processed where txid='2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee'

TXID	FROMADD	TOADD	VALUE	TYPE	BLOCKTIME	BLOCKNUM	VALID	CURTYPE	ID
2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee	12bDX26J84x545pzfSZouULeqjfBtAe9Lv	1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC	25000000000	simple	1378862659	257221	1	1	351494

EDIT: Bug resolved, apologies for any inconvenience and thanks for the bug check

[robamichael]

Firstly

Excellent work here. It will take awhile to digest, but it is plenty interesting.

I am struggling to understand the backed currency feature. Please allow me to present my sticking point. Thanks in advance to anyone who can resolve it.


Scenario

Consider an honest entity, MintX, which issues a MasterCoin derivative known as PlatinumCoin with the intention that it will track the price of 1 oz of Platinum bullion denominated in USD.

To issue PlatinumCoin, MintX accepts a nominal amount of MasterCoin equal to the USD price of 1oz Platinum, and in exchange the buyer receives one platinumcoin. MintX continues to issue at this rate to establish a market for PlatinumCoin. The mastercoins it accepts in the process are stored in escrow.

Should the secondary market price of PlatinumCoin fall below the intended price (1 oz Platinum:1 PlatinumCoin), MintX is expected to serve as a market maker. MintX destroys platinumcoins by accepting back any issued PlatinumCoin for a nominal amount of MasterCoin equal to the USD denominated price of 1 oz Platinum.


Caveat

The above scenario is presented under the assumption that the issuing entity, MintX, is honest, and we need not worry that it might sell off its escrowed MasterCoin, which is reserved solely for market making purposes.

The problem instead is that should the price of MasterCoin fall, the value of all MasterCoin in escrow will not meet the intended value of all issued PlatinumCoin. A similar price mismatch will arise should the USD price of 1oz Platinum rise.

In this condition, in which all MintX owned MasterCoin do not cover the intended value of all PlatinumCoin issued, what options are left for MintX should the market require MasterCoin in volume excess of that which is escrowed?


Example

1 MasterCoin = $500 USD
1 oz Platinum = $1500 USD

MintX issues 300 PlatinumCoin @ 1 PlatinumCoin:3 MasterCoin
MintX escrows 900 MasterCoin worth $450k

The USD price of MasterCoin tumbles
1 MasterCoin = $100 USD
MintX escrow = $90k USD

PlatinumCoin price falls, prompting MintX to buy PlatinumCoin @ 1 PlatinumCoin:15 MasterCoin

It would require only 60 PlatinumCoins to bankrupt the MintX escrow.
60 PlatinumCoin = $90k USD = 900 MasterCoin


What then?

[grazcoin]

I want to see some other project achieves such level of "distribution" with the the common local-parse-blockchain-on-your-database approach. They could try to implement something using blockchain.info (closed source) API, but then they have a single point of failure. The bitcoind alone is simply not flexible enough for the job. Masterchain on the other hand, just let some distributed open source powers to do that job.

JFYI there were a plenty of alternatives which can do more-or-less the same: Abe, electrum-server, bitcoinjs-server. So it isn't like obelisk is some unique piece of software.

Electrum uses a network electrum-servers for about a year now.

The question was about alternative mastercoin projects achieving that distribution level.
Electrum is from the same developer anyway, Abe is very heavy and not flexible enough. I have no experience with bitcoinjs-server.
It would be great if also other software would implement the protocol http://libbitcoin.dyne.org/obelisk/index.html or similar - then masterchain.info could use them as well.
I think we get carried away to off-topic which is not that interesting to other, so let's stop here.

[killerstorm]

The problem instead is that should the price of MasterCoin fall, the value of all MasterCoin in escrow will not meet the intended value of all issued PlatinumCoin. A similar price mismatch will arise should the USD price of 1oz Platinum rise.

Currency can be configured to automatically dissolve if escrow fund is too low, from the 1.1 spec (this wasn't present in 1.0):

If the currency creator had set the minimum escrow size to 100% the escrow fund would never get into
this situation because it would simply dissolve and pay out to currency stakeholders as soon as the
escrow fund value dropped to parity, with zero or minimal losses.

So... If mastercoins drop in price against gold, your GoldCoins will be automatically converted into mastercoins. Isn't that helpful?

Furthermore, suppose mastercoin drops in value. This triggers automatic conversion of GoldCoins into mastercoin. Now we have (potentially) a lot of people, who preferred gold exposure to Mastercoin exposure, and who know that mastercoin drops in value... Obviously, they'll want to buy gold with their mastercoins ASAP. Which means that a lot of mastercoins will be dumped on exchanges, causing further drop of mastercoin price, possibly causing collapse of other escrow-backed currencies.

So this has a positive feedback effect, where relatively small fluctuations can trigger an avalanche.

This seems to be an inherent property of systems like this: you cannot achieve true stability within a closed system; you can, however, make a trade-off, that is, you have to pay for reduction of volatility, and the price might be increased probability of catastrophic collapse.

MintX is expected to serve as a market maker

By the way, escrow fund mechanism makes it harder for a honest company to do this market making.

Suppose escrow fund is not used. Then a company can back coins it issues with 100% physical platinum. Company's exposure is neutral, so it doesn't need to do anything sophisticated to keep currency alive. It can simply sell platinum and buy back coins. It is inherently stable.

Now suppose that company buys mastercoins instead of platinum. Now company's position isn't neutral: is is long mastercoin and short platinum. It will be very hard to hedge this exposure.

Honestly, I don't see why a honest company would want to start an escrow-backed currency.

[killerstorm]

The question was about alternative mastercoin projects achieving that distribution level.

I will repeat in simple words: "that distribution level" has no advantages. It is NOT a good thing.

You CANNOT implement a thin client by getting a transaction history for a certain address.

Mastercoin transaction have implicit dependencies, and that means that once you'll get to advanced features, the only way to check transaction validity is to check all Mastercoin transactions. And, obviously, if you scan all Mastercoin transactions, it cannot be called a thin client. Potentially there will be millions, or even billions of such transactions.

On the other hand, thick clients which download all transactions and go through them keeping a local DB do not benefit from what you call "distributed architecture": Bitcoin protocol is already distributed, so you can just download all relevant blocks directly from the Bitcoin network.

You could say that you can make a faster thick client by using Obelisk, but it is a really bad trade-off: you gain a little in speed (if Mastercoin will be a big thing, then almost all Bitcoin transactions will be Mastercoin transactions, so there is no substantial difference between downloading whole blockchain and downloading only Mastercoin transactions), but you no longer have Bitcoin's foolproof security.

Trading off security for tiny gain in performance, how does this make sense?

Perhaps this makes sense in the short term, that is, while Mastercoin transaction count is very low you can indeed make a thin client this way, and perhaps it has some value. But I think you shouldn't boat of "distributed architecture", as it doesn't really have advantages in the long term.

Please note that I don't have a horse in this race, I just want to clarify some things.

You'll need special, Mastercoin-specific servers to enable validation on thin clients. Obelisk servers are simply are not suitable for this because they do not implement Mastercoin protocol.

[grimentz]

7. There will be investigation, and servers which produced wrong responses without a good excuse (e.g. well known bug in software) will be excluded from the list permanently.

Could you elaborate on the nature of this investigation? (i.e. is there a protocol for such investigation?)

[bitwhizz]

Hey guys, i was wondering why masterchest.info and master coin block explorer show me having a different amount of master coins
300 master coins have shown up  on master coin explorer

http://mastercoin-explorer.com/addresses/1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC

however only 50 on  masterchest.info

https://masterchest.info/lookupadd.aspx?address=1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC

They are both the same adress

Why is this ?

Hi bitwhizz,

Transaction 2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee is no longer showing in masterchest.info.  You received 250 MSC in this transaction, hence the discrepancy in balances between mine & Tachikoma's implementations.

This does look like a valid transaction - perhaps I may have introduced a bug in my latest update which is causing this particular transaction to be dropped as ambiguous - thanks for testing & I'll do some bug hunting when I get off work and get it corrected.

Thanks

Transaction actually not being dropped in my implementation - something else is up, diagnosing now.

Code:

select * from transactions_processed where txid='2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee'

TXID	FROMADD	TOADD	VALUE	TYPE	BLOCKTIME	BLOCKNUM	VALID	CURTYPE	ID
2d69ad4c5ec9380b2da89c06ef9fd263755d70f9fe7fe0774fe8c8a2494938ee	12bDX26J84x545pzfSZouULeqjfBtAe9Lv	1EYe3HxCA9txmN9pfEADctC7v69wi3TbMC	25000000000	simple	1378862659	257221	1	1	351494

EDIT: Bug resolved, apologies for any inconvenience and thanks for the bug check

Thanks,
The difference between the 50 Mastercoin transaction and the 250 mastercoin transaction on that adress is that the  seller of the 250 mastercoin transaction sent 0.0006 BTC instead of 0.00006 BTC in the transaction , according to the white paper this isn't a problem and a transaction is still valid, i'm just letting you know for future reference is this bug pops up again?, thanks for getting back to me

[Tachikoma]

Wow I go away for a weekend and everybody decides to release awesome stuff. Very cool!

I especially like Grazcoin's implementation on top of libbitcoin! It makes a lot of sense going for this approach and I can't wait to see what else comes out of it.

Great job guys; really digging the various implementations

[dacoinminster]

Wow, I'm finding it hard to keep up with my own dang project!

I support proof-of-stake voting for MasterCoin features, to remove me as the (mostly benevolent) dictator of the protocol, and I posted in Ripper's thread to that effect. I'm even willing to abstain from voting with my 28% if that makes everyone feel better

However, I've been thinking a lot about distributed e-commerce, and I've decided that there ARE some really good things about having such a system in the world, despite the obvious drawbacks. I plan to update the spec soon with:

• Description of message for paying dividends
• Description of message for suggesting/supporting new protocol features
• Description of messages for implementing distributed e-commerce
• Several other minor fixes and updates I've mentioned on this thread

killerstorm raised some valid points on reddit about how MasterCoin will be affected by blockchain re-organizations: http://www.reddit.com/r/coloredcoin/comments/1o6yke/colored_coins_or_mastercoin/

Basically, whenever orphaned blocks happen, he argues that MasterCoin has less protection against double-spending than bitcoin. At the very least, our various implementations need to give some thought to detecting reorganizations and re-scanning for MasterCoin transactions in case something changed due to the re-org. As we get bigger, we'll need to get more sophisticated about this. Certainly, no merchant should ever accept 0-confirmation MasterCoin transactions (since you can't prove the money hasn't been spent elsewhere until you see the transaction in the block chain and have high confidence it won't be orphaned).

Please forgive Alex's tone in those posts. Since he runs a competing initiative, you can maybe see why he'd be a bit biased. Despite that, I have a lot of respect for his intelligence, and he's obviously put a lot of thought into this area.

I'm unbelievably pleased to see that we now have THREE websites parsing simple-send transactions. Thanks for your hard work on this grazcoin. I think we're all agreed that your multi-sig approach is superior, we just can't use it yet! Don't throw away that code, but we need to all consolidate on the less-pretty-but-harder-to-block multi-sig method previously described.

This is a great place to be at the end of our coding contest (ends tomorrow). Tomorrow I'll kick off collecting the data I need from each of you to do the payouts

Seeing distributed exchange and smart property get implemented is going to be so exciting - I can't wait!

-J.R.

[dacoinminster]

P.S. I added masterchain.info links to the OP and to our reddit side-bar

Also, added "MasterCoin" to the title of this thread. (Thanks for the suggestion Ron)

[grazcoin]

Wow I go away for a weekend and everybody decides to release awesome stuff. Very cool!

I especially like Grazcoin's implementation on top of libbitcoin! It makes a lot of sense going for this approach and I can't wait to see what else comes out of it.

Great job guys; really digging the various implementations

Thanks for the support!
I am sure you like also the UI - the inspiration for it (at least Address.html page) is based on your site ;-)