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

[bitwhizz]

I thought this thread would have died long ago considering the valid criticisms at the start of the thread but maybe I was too close minded.

Is someone willing to summarise why Mastercoin is a good investment? What's the potential? And why?

I feel this is incredibly important. It would help to clear some of the fog and confusion around this project and maybe take some of the rhetoric out of the dialogue. The white paper is one thing, but many people wont read it, won't quite understand it, or will misunderstand the projects purpose/intention. Much of it is somewhat ambiguous. I say this from my experience having conversations with people about Mastercoin. A format that's easy to disseminate with the purpose, direction, objectives and technical function of the project that's concise and easily digestible but still covers enough ground to get a good grasp on the overall concepts. Frankly, I'm not even clear on many of these things. Maybe it would be a good thought excersize for those involved and help define these things for themselves as well.

Your right, there should be a video to explain the funcionality of mastercoin would be helpful for most people, in a similar style as the one made on bitcoin and the one made for ripple

like this one

http://www.youtube.com/watch?v=SEbCbp1vc9Y

[1715665494]

1715665494

[1715665494]

1715665494

[1715665494]

1715665494

[1715665494]

1715665494

[1715665494]

1715665494

[killerstorm]

With P2SH, the MasterCoin data could be stored in the input scriptSig, as a part of redeeming.  This may be unworkable, because the MasterCoin data would only be revealed when you spend a MasterCoin, and not when you receive a MasterCoin.

Before deciding on a spec I think we should exhaust every option presented to us. I will see if I can find a way of doing it via P2SH if that really is the best way to prevent any type of bloat. If that is indeed not possible I suggest we switch to multisig encryption until OP_RETURN becomes available at what time we can switch back to using address encoded data.

Note that Jeff doesn't know how MasterCoin protocol works, I think he thinks that it is similar to colored coin approach, but it is not!

(The difference is that with colored coins you have to spend a specific UTXO, but with MasterCoin you can spend any coin.)

It is possible to spend multisig outputs right away, hence they don't need to be in UTXO set. But users are not required to spend these outputs right away, so the concern that they will hang in the UTXO space remains.

If we want to absolutely prevent the possibility of bloating, P2SH+multisig seems to be the best option. It might have slightly higher storage overhead, but it is guaranteed to not store anything in UTXO set.

So taking this into account, what we get:

1. Plain multisig is a viable option. Bloat prevention can be a policy of client: it should spend these multisig outputs either right away, or after some time.
2. P2SH+multisig is possible and easy to implement, but it isn't clear if it is necessary. In any case, it is easy to add support for it.
3. OP_RETURN offers NO advantages, only disadvantages. it shouldn't even be considered.

(EDIT: well, OP_RETURN has one advantage: it makes Bitcoins more valuable through monetary deflation

[killerstorm]

With P2SH, the MasterCoin data could be stored in the input scriptSig, as a part of redeeming.  This may be unworkable, because the MasterCoin data would only be revealed when you spend a MasterCoin, and not when you receive a MasterCoin.

Mastercoin protocol is message-based, i.e Mastercoin is sent when message is published in the blockchain.

It doesn't use Bitcoin transaction graph in any way, Mastercoins are not tied to any particular UTXOs. In other words, Mastercoins do not exist within the Bitcoin blockchain, blockchain is only used as a communication medium.

So P2SH will work (sender needs to create two transactions to send mastercoins: one which pays to script hash, and another which publishes the message in the inputs).

But just using multisig outputs works too: when user A sends coins to user B, multi-sig script he creates can include public key of user A. So he can later spend this output and use coins for other Mastercoin transaction. Hence we'll have one multi-sig UTXO per user, which is hardly a problem.

If it is a problem, it is possible to enforce use of P2SH+multisig, but it has higher overhead because two Bitcoin transactions are needed to represent one Mastercoin transaction.

[zathras]

JR, the spec doesn't mention anything about confirmations - have you put much thought into when we would consider a mastercoin transaction confirmed?  3 blocks? 6 blocks?  Thanks

Tachikoma, while I was doing some comparisons between my work and your (great btw) block explorer - I noticed a minor bug in your block reporting - eg transaction http://mastercoin-explorer.com/transactions/3dcdf1a51ad844ef305a95a08d57e8f2027125bcf982cc0ae6767d0d629b5648 is reported as being included in block 260564 but as of now the network is only up to block 259203.

[jgarzik]

Note that Jeff doesn't know how MasterCoin protocol works, I think he thinks that it is similar to colored coin approach, but it is not!

Let's not put words into others' mouths, shall we?

MasterCoin is almost exactly like my original pybond scheme -- which had nothing to do with colored coins whatsoever.  Which is, in turn, similar to Mike Hearn's bond proposal from years ago.  The only similarities are higher level concepts of "applying a protocol on top of bitcoin transactions."

An earlier proposal would have enabled the attachment of mastercoins (or bonds) to each txout: https://github.com/bitcoin/bitcoin/pull/1809   After much discussion in the community, it was decided that OP_RETURN was superior because it provably enables pruning (thus removing UTXO bloat automatically).

Been there, done that, all these problems have already been thought through.

(The difference is that with colored coins you have to spend a specific UTXO, but with MasterCoin you can spend any coin.)

Just like my pybond design, which had absolutely nothing to do with colored coins.

1. Plain multisig is a viable option. Bloat prevention can be a policy of client: it should spend these multisig outputs either right away, or after some time.
2. P2SH+multisig is possible and easy to implement, but it isn't clear if it is necessary. In any case, it is easy to add support for it.
3. OP_RETURN offers NO advantages, only disadvantages. it shouldn't even be considered.

UTXO bloat is not a policy of the client, if the protocol is specified to store MasterCoin data in the UTXO set.

The quoted message is hand-waving away additional burdens placed upon the network -- and every bitcoin user -- by MasterCoin.

It is simple, provable engineering fact that storing data in transaction outputs makes block validation, double-spend checks and other critical consensus operations more expensive.  More RAM is used on average.  In general, it burdens the entire network.  UTXO is our most critical resource currently.  We have already made one change in recent times to ensure that UTXO growth is more constrained in the future:  https://github.com/bitcoin/bitcoin/pull/2577

Big mining pools also have custom patches on top of PR #2577, that ignore transactions they feel bloat the UTXO set.  Even more relevant to MasterCoin, at least two pools that I know of elide transactions that appear to transmit data rather than monetary value, trying to prevent another episode of dumping wikileaks cables into the blockchain.

Please work with the community, not against it.  The blockchain free-rider problem is very real, and deserves thought.

(EDIT: well, OP_RETURN has one advantage: it makes Bitcoins more valuable through monetary deflation

Incorrect.  All current proposed OP_RETURN schemes set nValue==0, because nobody wants to burn money.  Old "sacrifice" schemes have been dropped in favor of miner fees or anyone-can-spend outputs.

[killerstorm]

Note that Jeff doesn't know how MasterCoin protocol works, I think he thinks that it is similar to colored coin approach, but it is not!

Let's not put words into others' mouths, shall we?

MasterCoin is almost exactly like my original pybond scheme

No, it doesn't.

Again, MasterCoins are associated with addresses, not with transaction outputs. It is a completely different design.

MasterCoin user can own MasterCoins even if he doesn't own any UTXOs.

It isn't the case with pybond, is it?

[ASICSRUS]

Big mining pools also have custom patches on top of PR #2577, that ignore transactions they feel bloat the UTXO set.  Even more relevant to MasterCoin, at least two pools that I know of elide transactions that appear to transmit data rather than monetary value, trying to prevent another episode of dumping wikileaks cables into the blockchain. ...

i'd imagine it's possible to filter data type transactions coming from only certain countries that the pool don't like? 

[cunicula]

For what it is worth (probably negative to most people), I am pretty sure that killerstorm is right on this.

Mastercoin allows for state dependent transactions. Bitcoin doesn't. This is severely limiting. Almost everything I have ever wanted to see added to bitcoin cannot be added because bitcoin does not allow state dependent txn outcomes (e.g outcome of a txn cannot depend on the realization of a future state variable such as difficulty.)

[DobZombie]

For what it is worth (probably negative to most people), I am pretty sure that killerstorm is right on this.

Mastercoin allows for state dependent transactions. Bitcoin doesn't. This is severely limiting. Almost everything I have ever wanted to see added to bitcoin cannot be added because bitcoin does not allow state dependent txn outcomes (e.g outcome of a txn cannot depend on the realization of a future state variable such as difficulty.)

Can somebody explain 'state dependant?'

[zathras]

I'd like to seek further validation of my transaction engine so I've opened up the block explorer component of Masterchest @ https://masterchest.info.

This is very alpha so there may be bugs, errors, mistakes and so on present - feedback is most welcome so please post about any errors or unexpected behaviour.

[Tachikoma]

I'm back in action after being tied to the bed for the last week.

I've released 'Masteroin-ruby' which is the library behind mastercoin-explorer.com. I am trying to keep the readme up-to-date whenever I update it.

The latest version supports sending multisig Mastercoin-transaction via Bitcoin-Qt (or Bitcoind). However as always please be very careful what you do. It's very basic but the same logic could be used by any full-fledged Mastercoin client. Mastercoin-explorer will also recognise multsig transactions now.

I've send three (invalid, because the sending address did not buy from Exodus, did not want to send real coins until spec is finalised) multisig transactions, one, two and three.

As always I hope all you other developers working around can also try my implementation so we can finalise the spec. A few things I came across.

• Sequences for multisig public keys need to start with 01 instead of 00. If you don't do this more often then not the public key won't be a valid ECDSA point.
• My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
• Bitcoin-qt doesn't recognise multsig-transactions as outputs ready for spending. You will have to manually redeem those outputs.

Tachikoma, while I was doing some comparisons between my work and your (great btw) block explorer - I noticed a minor bug in your block reporting - eg transaction http://mastercoin-explorer.com/transactions/3dcdf1a51ad844ef305a95a08d57e8f2027125bcf982cc0ae6767d0d629b5648 is reported as being included in block 260564 but as of now the network is only up to block 259203.

Thanks! This should now be fixed.

I'd like to seek further validation of my transaction engine so I've opened up the block explorer component of Masterchest @ https://masterchest.info.

This is very alpha so there may be bugs, errors, mistakes and so on present - feedback is most welcome so please post about any errors or unexpected behaviour.

Woops; grats! Diversity is a good thing

[Peter Todd]

Posted my "Offer: Mastercoin analysis and transaction specification design" here https://bitcointalk.org/index.php?topic=299679.0

[zathras]

I'm back in action after being tied to the bed for the last week.

I've released 'Masteroin-ruby' which is the library behind mastercoin-explorer.com. I am trying to keep the readme up-to-date whenever I update it.

The latest version supports sending multisig Mastercoin-transaction via Bitcoin-Qt (or Bitcoind). However as always please be very careful what you do. It's very basic but the same logic could be used by any full-fledged Mastercoin client. Mastercoin-explorer will also recognise multsig transactions now.

I've send three (invalid, because the sending address did not buy from Exodus, did not want to send real coins until spec is finalised) multisig transactions, one, two and three.

As always I hope all you other developers working around can also try my implementation so we can finalise the spec. A few things I came across.

• Sequences for multisig public keys need to start with 01 instead of 00. If you don't do this more often then not the public key won't be a valid ECDSA point.
• My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
• Bitcoin-qt doesn't recognise multsig-transactions as outputs ready for spending. You will have to manually redeem those outputs.

Tachikoma, while I was doing some comparisons between my work and your (great btw) block explorer - I noticed a minor bug in your block reporting - eg transaction http://mastercoin-explorer.com/transactions/3dcdf1a51ad844ef305a95a08d57e8f2027125bcf982cc0ae6767d0d629b5648 is reported as being included in block 260564 but as of now the network is only up to block 259203.

Thanks! This should now be fixed.

I'd like to seek further validation of my transaction engine so I've opened up the block explorer component of Masterchest @ https://masterchest.info.

This is very alpha so there may be bugs, errors, mistakes and so on present - feedback is most welcome so please post about any errors or unexpected behaviour.

Woops; grats! Diversity is a good thing

Great work Tachikoma, busy getting the wallet ready but I'll take a look at expanding the Masterchest transaction engine to handle multisig too - thanks for all your work

[superfluouso]

Posted my "Offer: Mastercoin analysis and transaction specification design" here https://bitcointalk.org/index.php?topic=299679.0

Thanks for the offer, though as an "investor" this is slightly annoying.  Why do you feel you need to separate yourself from the rest of those who may be interested in pursuing the outstanding bounty?  As someone presumably qualified, why not jump in with your skills and either A) make bitcoin better by further developing this mastercoin protocol layer or B) make bitcoin better by illuminating the supposed folly of a mastercoin layer (or anything like it in the future) and thereby protect it? 

If JR and the board want to take you up on your offer, obviously some like myself won't/can't stand in the way, but it appears JR's feelings on this issue were made clear earlier in the thread.  I can appreciate your enterprising nature, however, I feel its distracting to the goal at hand.  Personally, I'd much rather see talented devs contribute to this project regardless if its favorable or not, just to provably show whether or not this can work and sustain itself.  It's not like 40 BTC is going to change your life today anyways...why not just jump in and contribute if you have something to offer?

[Peter Todd]

It's not like 40 BTC is going to change your life today anyways...why not just jump in and contribute if you have something to offer?

I've got other paid and unpaid work competing for my time.

[killerstorm]

Posted my "Offer: Mastercoin analysis and transaction specification design" here https://bitcointalk.org/index.php?topic=299679.0

Thanks for the offer, though as an "investor" this is slightly annoying.  Why do you feel you need to separate yourself from the rest of those who may be interested in pursuing the outstanding bounty?  As someone presumably qualified, why not jump in with your skills and either A) make bitcoin better by further developing this mastercoin protocol layer or B) make bitcoin better by illuminating the supposed folly of a mastercoin layer (or anything like it in the future) and thereby protect it? 

If JR and the board want to take you up on your offer, obviously some like myself won't/can't stand in the way, but it appears JR's feelings on this issue were made clear earlier in the thread.  I can appreciate your enterprising nature, however, I feel its distracting to the goal at hand.  Personally, I'd much rather see talented devs contribute to this project regardless if its favorable or not, just to provably show whether or not this can work and sustain itself.  It's not like 40 BTC is going to change your life today anyways...why not just jump in and contribute if you have something to offer?

Your arrogance is sickening.

Mastercoin is a commercial endeavor, it got more than $500k in funding. But you're annoyed by the fact that people aren't willing to work for free. WTF is wrong with you?

BTW I think accepting retep's offer (or a similar offer) is the only way to save Mastercoin from failure. But you can keep thinking that trusting design to amateurs is a good idea.

People like J. R. Willet and ripper234 might be good software developers, but it's quite obvious they didn't have any experience in designing decentralized cryptographic systems and protocols for them.

On the other hand, retep is one one few people who know Bitcoin protocol inside-out (not just how to use it, but design considerations which go into it).

[superfluouso]

It's not like 40 BTC is going to change your life today anyways...why not just jump in and contribute if you have something to offer?

I've got other paid and unpaid work competing for my time.

Fair enough..I only hope at some point the potential of MasterCoin will be a bigger lure than a guaranteed 40 BTC to bring you into the mix.

[superfluouso]

Posted my "Offer: Mastercoin analysis and transaction specification design" here https://bitcointalk.org/index.php?topic=299679.0

Thanks for the offer, though as an "investor" this is slightly annoying.  Why do you feel you need to separate yourself from the rest of those who may be interested in pursuing the outstanding bounty?  As someone presumably qualified, why not jump in with your skills and either A) make bitcoin better by further developing this mastercoin protocol layer or B) make bitcoin better by illuminating the supposed folly of a mastercoin layer (or anything like it in the future) and thereby protect it? 

If JR and the board want to take you up on your offer, obviously some like myself won't/can't stand in the way, but it appears JR's feelings on this issue were made clear earlier in the thread.  I can appreciate your enterprising nature, however, I feel its distracting to the goal at hand.  Personally, I'd much rather see talented devs contribute to this project regardless if its favorable or not, just to provably show whether or not this can work and sustain itself.  It's not like 40 BTC is going to change your life today anyways...why not just jump in and contribute if you have something to offer?

Your arrogance is sickening.

Mastercoin is a commercial endeavor, it got more than $500k in funding. But you're annoyed by the fact that people aren't willing to work for free. WTF is wrong with you?

BTW I think accepting retep's offer (or a similar offer) is the only way to save Mastercoin from failure. But you can keep thinking that trusting design to amateurs is a good idea.

People like J. R. Willet and ripper234 might be good software developers, but it's quite obvious they didn't have any experience in designing decentralized cryptographic systems and protocols for them.

On the other hand, retep is one one few people who know Bitcoin protocol inside-out (not just how to use it, but design considerations which go into it).

I'm afraid you misunderstood - at no point did I imply he should work for free.  I am simply questioning why he felt a need to work outside of the already established framework to utilize the 500k in funding.  I'm pretty certain if he just did what he proposed, he'd avail himself to a large portion of the current and future amounts made available anyways.

Or maybe I just had too many beers. I'll stay quiet..carry on.

[killerstorm]

Fair enough..I only hope at some point the potential of MasterCoin will be a bigger lure than a guaranteed 40 BTC to bring you into the mix.

People who see the potential in ideas behind Mastercoin are working on similar systems: BitShares, Freimarkets, etc.

Why would they want to make a system based on J. R. Willet's inept design if they can design a better system on their own?

Really, the only potential advantage of Mastercoin is funding it got. There are people who would like to work in the field of cryptocurrencies, but have to work elsewhere to feed themselves and their family. So actually paying for work can help Mastercoin to attract qualified people... At least in theory.

[killerstorm]

I'm afraid you misunderstood - at no point did I imply he should work for free.  I am simply questioning why he felt a need to work outside of the already established framework to utilize the 500k in funding.  I'm pretty certain if he just did what he proposed, he'd avail himself to a large portion of the current and future amounts made available anyways.

Or maybe I just had too many beers. I'll stay quiet..carry on.

Do you mean that $25k competition?

Well, retep's report will likely recommend something "controversial", like a more complex design, keeping data in a separate chain etc. Because it just makes sense, I think all Bitcoin core devs will agree with this.

J. R. would not like this, so he will award him no points, and will instead reward people who work on Mastercoin implementation which goes along the lines of Mastercoin spec written by J. R. himself.

The thing is, this spec is a bit too half-assed, so while in short term it will give some tools which kinda sorta work, in the long run adherence to overly simple design will cripple Mastercoin.

I really don't see why spending ~1% of funding received on a professional analysis is a bad idea, while relying only on people who join the competition is a good idea.

I mean, it is theoretically possible that something good will come out of this competition, but why not increase chances of getting something good out of it by spending a bit extra? After all, time is crucial here.

I understand that if retep's offers is accepted, that will piss off developers who are already working on Mastercoin (Tachikoma et al.). But they are just not offering same kind of thing as retep can do, so it's fair: different kind of reward for a different kind of work.