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

Hey Grazcoin,

I can confirm both these transactions are dropped as they are ambiguous under the processing rules in my implementation (here)

Thanks!

What happened to the tool on mastercoin-explorer.com that created transaction specifications for you?

Just before this round ends, I decided to challenge the parsing of the different implementations and manually created invalid transactions, according to:
https://bitcointalksearch.org/topic/m.3190175

The transactions are:

• https://blockchain.info/tx/c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5
• https://blockchain.info/tx/ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5

On masterchain.info you can see that they don't appear, and if you ask for them directly:

• http://masterchain.info/Transaction.html?tx=c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5
• http://masterchain.info/Transaction.html?tx=ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5

you would see that they are indeed invalid.

For the reason of invalidity, you can check the json:

• http://masterchain.info/tx/c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5.json
• http://masterchain.info/tx/ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5.json

On the first tx, "invalid" field has the value [true, "ambiguous sequence [77, 77, 78]"]
On the second tx, "invalid" field has the value [true, "perfect sequence [75, 76, 77]"]

It seems that mastercoin-explorer.com treats them as valid:
http://mastercoin-explorer.com/transactions/c2a904dd47797736617bf5df555f029064de0fc2ff5ba71197638e469caae7f5
http://mastercoin-explorer.com/transactions/ecb792bf58c67120d6d62149f542271c33e3df046460aebc2bae1012e5ba52e5

On https://masterchest.info they don't appear.
zathras, please verify that the tx got invalid for this reason (and not for some other parsing reason).

I hope this help.

Thanks

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 ;-)

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)

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.

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,
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

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

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.

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):


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.

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.

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?

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


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

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

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.

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

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

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.


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.