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

[dacoinminster]

Selling Mastercoin for Bitcoin spec

Now that multiple wallet releases are coming closer it seems like a good time to look ahead. One of the things that I think we should build next is the option to buy Mastercoins with Bitcoin via the spec.

I have a couple of problems with the current plan laid out by the official spec. For those who are unfamiliar the current idea is that somebody can create an offer transaction that will list how many Mastercoins he or she is selling and how many Bitcoins should be send in return. If I would want to take somebody up on that offer I would first send a 'accept offer' transactions followed by a transaction of the actual Bitcoins.

Fake offers can be a real problem with this implementation. Currently fake offers are discouraged by setting a high transaction fee required for the 'accept offer' transactions, however this is not a perfect solution. For one; people who have coins to burn can still spam accept offer transactions without ever sending them and if two legitimate offers come in and there are not enough coins available the last person will have paid this steep transaction fee without having actually bought the coins.

My solution has other problems and I am not even sure it's better but I wanted to provide an alternative.

The idea is that we cut out the 'accept offer' transaction and that in order to accept an offer you send the actual transaction with the required Bitcoin amount using a 2-out-of-3 multisig transaction. This multisig transaction will have three public keys. One public key will be the key of the person that broadcasted the offer. One public key will be that of the person accepting the offer. The third public key will be of a escrow party. For now I consider this escrow party to be the Mastercoin foundation.

Let's see how this would work in practice.

* User A broadcasts an offer of 100 Mastercoins for 20 Bitcoin.
* User B and User C both accept this offer in the exact specified quantity.

Once these transactions are included in the blockchain it shows that User C's transaction was included before User B's and this the winner of these coins.

User A now wants to spend his just received Bitcoins. He creates a transaction to send the multisig transaction he received to a address he solely owns and signs it with his key. He then uploads/transmits the partly signed transaction to a site/application owned by the Mastercoin foundation that checks if User A is allowed to spend those 20 Bitcoins. The application will verify that User A did indeed sell User C Mastercoins and that he is allowed to spend these coins, the app will automatically sign the transaction and broadcast it (or return the signature transaction).

The same can be done for User B, who's offer lost. The middleman app will recognise that User B did indeed lose the race and will sign his transaction as well.

However if User C now tries to use this service the app will recognise that he was actually a winner and won't sign his transaction.

The main problem with this implementation is that it requires trust, something I think we should try to avoid as much as possible. However this solution does solve all the points I addressed in the opening. I hope somebody can come up with a way to further decentralise this solution. If not we should probably decide if it's worth it to centralise a bit in order to have a better user experience.

Feedback welcome, as always

I'd definitely like to experiment with some alternate implementations of the distributed exchange at some point. Tachikoma is correct that the suggested changes here would reduce the cost overhead while increasing centralization. I'd make one major change: the MasterCoin Foundation should not play middle-man, for legal reasons. We need to stay out of the money flows lest we be held liable for them. Allowing users to choose their own middleman would fix that problem and make the solution less centralized, but we would end up with multiple middle-man apps, and therefore multiple exchanges with multiple order books.

Another potential problem is keeping the middle-man secure. It would be a potential attack vector to compromise the middle-man account and then set up situations that allow stealing of BTC from market participants.

I'd like to stick with the existing implementation described in the spec for now, which is decentralized but marginally more expensive to users (it should only be expensive when the exchange is under attack, and since attackers lose money and can't actually shut down the exchange, I don't expect any attack would last very long or be effective).

If we find that fees rise unreasonably high, we can play around with middle-man apps, but I expect that fees will not be very high long term, except for brief periods when hostile forces decide to burn some bitcoins. During those periods, we'll always have the option of using escrow just like we do today.

Keep in mind that the decentralized exchange can't be burdened with fees in this way when exchanging between MasterCoins and other MasterCoin-derived currencies. This only affects MasterCoin/bitcoin exchange.

[1715240317]

1715240317

[dacoinminster]

I've added links to mastercoin.org and masterchest.info to the OP. Not sure why I didn't have a masterchest link there already - sorry Zathras.

If anybody knows of links that should be in the OP or on the MasterCoin.org page or in the reddit sidebar, please let me know!

-J.R.

[bybitcoin]

I know it might be a bit late and also off-topic, but why don't you guys try to use the off blockchain script-messaging based possibility to include and handle all transactions of the higher levels (expect the one when somebody sends bitcoins to buy some mastercoins)
Since the number of mastercoins are constants (well there will be 10% gradually being added, but at any known interval the total is a constant number), we can use a list of all mastercoin wallets with > 0 ballance, plus a modular arithmetic way of encoding every and each tx in a standard binary number (chiness remainder theorem can produce these numbers easily) to be dealt and then to be added and modified in the wallets list.
As the decentralized handling of this scheme may be questioned, there could be two ways:
1- Using several gradually increasing number of info wallets, as seeders, to just keep the wallets balance list+ recent script-based tx.
2-Making use of random double-spending-check functioning nodes, that is: for each tx, two or three random online wallet>0 will be chosen to check the tx correctness due to their list and if they all permit it, tx can be finalized and included in their balance lists  (and new one be informed to others as well)
*Or rather an optimal combination of 1,2.

[Tachikoma]

Forgive my ignorance but could you explain what 'off blockchain script-messaging' is in this context?

[wizzardTim]

One newbie question: Can I send and recieve Mastercoin to/from a MultiBit BTC Wallet? Or only from a qt wallet with the full blockchain downloaded?

I'm asking because I ran out of disk space and cannot longer use the qt wallet (I would be grateful to anyone who tells me how I can use the qt-wallet to a different drive than c:/).

[Tachikoma]

If MultiBit can do 'sendmany' transactions then yes; you can use MultiBit to send Mastercoin transactions uses the old style transactions; although I would not suggest you do this.

[wizzardTim]

If MultiBit can do 'sendmany' transactions then yes; you can use MultiBit to send Mastercoin transactions uses the old style transactions; although I would not suggest you do this.

I doubt it can do that.. so now that I can't use Multibit or qt(due to space restriction) you suggest me to wait for a light-wallet client to be developed?

[Tachikoma]

If you are feeling adventurous you can try out my wallet implementation; but you will need to be comfortable around a terminal for now.

[dacoinminster]

If you are feeling adventurous you can try out my wallet implementation; but you will need to be comfortable around a terminal for now.

Yes, we need more testers!

There's also blockchain.info - a lot of people seem to be using that. It can do sendmany, and I understand it can be fairly secure if used correctly.

[bybitcoin]

Forgive my ignorance but could you explain what 'off blockchain script-messaging' is in this context?

The idea is better explained when we use the off-chain transaction methodology (with embedded modular numbers instead of Jr.Willet's bytes code as transactions messages, which I can explain and formulate later on) using merkele-sum trees of accounts. Here I include a passage from https://en.bitcoin.it/wiki/Off-Chain_Transactions
Auditing
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are audited regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.
Gregory Maxwell has proposed[3] to use merkle-sum trees of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.

[bybitcoin]

In the passage I addressed in the previous post, if we replace the side or service in debt with the tx receiver in our context and the lender with tx sender, my first post scheme can be implemented using a similar merkele-tree of accounts using modular numbers instead of tx bytes codes explained in dacoinminster's spec paper, that handles all transactions (except buying mastercoin with bitcoin) off the bitcoin blockchain.
This will apparently resolve the blockchain bloat problem effectively.
PS: also as an additional security-protection layer, it can be settled for this off-chain merkele-tree os to send a message including the list of all accounts (> 0) balances as an on-blockchain message to the exudus address every 24 hour(or any other period) once. But this one can be neglected if looks bloating the blockchain size as well (which seems not)

[bybitcoin]

What interesting people we have here in btt community
 

[bybitcoin]

Also for ensuring that in the off-chain network a transaction is requested by the real private key owner of  that address sending the tx, though the cryptographic providence being described in off-chain methodology using SHA256 digests is enough and working, but for the sake of more transparency and security, it is possible to add the feature of having the private-key owner send to the destination address a below 54.3 micro-bitcoins transaction on the bitcoin blockchain too, to confirm his off-chain action. This micro tx sending attempt could be seen in the main bitcoin blockchain by the potential mastercoin client and be interpreted as the second confirmation that the real owner is sending the tx off-chain too. And while it works as two factor authentication, due to "dust transaction policy" the tx will be rejected and will not add anything to the bitcoin blockchain size that cause a problem.
The benefit of this scheme is that since the merkle tree, of accounts in off-cahin network, could be sent to the exudus address periodically, it is always possible to turn back to the classical-initial way of handling tx on the main bitcoin blockchain, in the case if the bitcoin devs. decide to change that dust policy or any other sensitive specs that cause our scheme become not effective.
And finally I should mention that I have been thinking on Jr.Willet's paper and my resolution for the UTXO bloat problem, during the last 15 days, just because of my love and support for this great project, and therefore I declare here that I have not any insistence about using my solution instead of any other available ones!

[zathras]

Update.  My implementation has support for decoding multisig transactions but the way I was coming at encoding was - well let's not beat around the bush - completely wrong I'm disappointed to say.

I've gone back to basics and at least now understand where I had misunderstood things.  The problem now is that it looks like bitcoind doesn't have sufficient functionality within the rawtransactions API to help me build the transaction.  createrawtransaction only takes an array of addresses & values for the outputs so I believe the only thing I'm left with is building the transaction hex completely from scratch - I've burned more hours than I care to admit attempting to figure this out but I'm not making much progress.

I've gone through Tachikoma's source in an attempt to translate logic but that calls on bitcoin-ruby to build the transaction and looking through that (my ruby is non-existent) was making my eyes go square.

In a nutshell let's keep simple - note the below example vout - anyone know of a way this can be constructed using the bitcoind/qt API?

       {
            "value" : 0.00012000,
            "n" : 3,
            "scriptPubKey" : {
                "asm" : "1 03e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee 020100000000000000020000000007f819a0000000000000000
 2 OP_CHECKMULTISIG",
                "hex" : "512103e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee210201000 00000000000020000000007f819a0000000000000
00052ae",
                "reqSigs" : 1,
                "type" : "multisig",
                "addresses" : [
                    "1HyC1C8oRzoEqnwZnoLRwMXUE2p1y3nsh9",
                    "1Nb68WTMCNXQ6LbJEyJEGft3ztWwSFcWLE"
                ]
            }
        }

Again forgive the newbieness of the question if it comes across that way, I'm learning much of this from scratch.

Thanks!

[dacoinminster]

I'd just like to bring attention to Retep's proposition at this link and Cunicula's valuable comment regarding derivatives/smart property, in case anyone didn't catch it.

https://bitcointalk.org/index.php?topic=299679.0

I really think these things need serious consideration and I'm a bit concerned with the dismissive attitude they have received. The consensus on Retep's ability and knowledge regarding Bitcoin is that of high regard from what I can tell. This seems like a potentially invaluable resource. The white paper is a good outline, but this could provide a more solid framework to build on, giving focus and direction and accelerating development. I'm sure the content of the reports can be optimized so it's effectively aligned with the projects goals, as decided by the board and community. It's at least worth negotiating, even if you don't go down that road in the end.

Regarding Cunicula's comment, is there a plan to consult someone with an economics background to be sure you're building a viable system for the smart property/derivatives? J.R., you said one of the great features of the planned smart property implementation is it's simplicity. Are you professionally qualified to claim viability of the planned design in these type of systems and markets? A well working system is as simple or complicated as it needs to be. To move forward rigidly with your plan, viability be damned because you want a "simple" design, seems like a setup for failure. I realize these aren't absolute priorities at the moment. But they will be in the (near) future and it just feels a bit flying-by-the-seat-of-your-pants with the talk about some of this.

You've laid out the basics with the white paper. Personally, I'd expect team building (probably more ad-hoc than structured for the moment, I know) so the goals for the respective parts of the project can be met effectively by those with the most suitable skills and knowledge. The coding contest and everyone doing the work they are is a great start. These considerations could be an important addition.

About that, can the board officially prononce a statement about the retep offer? 

J.R. When you have a few minutes, would you care to comment on any of this? It would be appreciated.

One of my board members said he was going to reach out to reteP to get some more info, but I haven't heard anything since then. I don't consider this high priority, as it seems pretty likely that reteP would recommend changes we are unwilling to make (like getting rid of MasterCoins or moving to an alt chain).

[zathras]

Update.  My implementation has support for decoding multisig transactions but the way I was coming at encoding was - well let's not beat around the bush - completely wrong I'm disappointed to say.

I've gone back to basics and at least now understand where I had misunderstood things.  The problem now is that it looks like bitcoind doesn't have sufficient functionality within the rawtransactions API to help me build the transaction.  createrawtransaction only takes an array of addresses & values for the outputs so I believe the only thing I'm left with is building the transaction hex completely from scratch - I've burned more hours than I care to admit attempting to figure this out but I'm not making much progress.

I've gone through Tachikoma's source in an attempt to translate logic but that calls on bitcoin-ruby to build the transaction and looking through that (my ruby is non-existent) was making my eyes go square.

In a nutshell let's keep simple - note the below example vout - anyone know of a way this can be constructed using the bitcoind/qt API?

       {
            "value" : 0.00012000,
            "n" : 3,
            "scriptPubKey" : {
                "asm" : "1 03e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee 020100000000000000020000000007f819a0000000000000000 2 OP_CHECKMULTISIG",
                "hex" : "512103e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee210201000 00000000000020000000007f819a000000000000000052ae",
                "reqSigs" : 1,
                "type" : "multisig",
                "addresses" : [
                    "1HyC1C8oRzoEqnwZnoLRwMXUE2p1y3nsh9",
                    "1Nb68WTMCNXQ6LbJEyJEGft3ztWwSFcWLE"
                ]
            }
        }

Again forgive the newbieness of the question if it comes across that way, I'm learning much of this from scratch.

Thanks!

I thought I should add some further info on my attempts to just create the raw transaction hex from scratch and see if I can get some help there (as I'm fairly confident it can't be done with the bitcoind/qt API and thus I doubt I'll get much of a response to that part).  

I just can't seem to get my head around how to build it as a multisig transaction.

If we take the following transaction I've manually constructed for example:

Code:

0100000001a1a7ca5f86c8c5c1bdc367570b8714a75e4800cc97de5a0f47abb208a7eabd7f0100000000ffffffff03204e0000000000001976a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac204e0000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac204e00000000000049010121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a00000000000000000000000000000000102ae00000000

This decodes to:

Code:

{
    "txid" : "869f499746deb77019df8b9aedbaaa0fbdfb1317e0d5387c412fe3160bb89b81",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "7fbdeaa708b2ab470f5ade97cc00485ea714870b5767c3bdc1c5c8865fcaa7a1",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "",
                "hex" : ""
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.00020000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8"
                ]
            }
        },
        {
            "value" : 0.00020000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
                ]
            }
        },
        {
            "value" : 0.00020000,
            "n" : 2,
            "scriptPubKey" : {
                "asm" : "1 021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575 020100000000000000020000000007f819a0000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "hex" : "010121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a00000000000000000000000000000000102ae",
                "type" : "nonstandard"
            }
        }
    ]
}

As you can see the last vout is a nonstandard tx type (not "multisig") and has no reqSigs value.  I've obviously made a mess of building the transaction hex for the multisig part (vin & the other basic vouts are easy).  Would anyone care to help out and let me know where I've gone wrong?

Thanks again

EDIT: Tachikoma I can't seem to get your code running to compare our transaction hex before signing:

Code:

Getting private key and public key for Mastercoin address
Getting raw transaction data
Found raw transaction; unpacking into tx
Setting fees
Total amount available from input: 0.06968
Paying 0.0001 network fees
Taking 0.00024 out of total for each mastercoin output
Sending 0.06934 back to mastercoin address
Using public key for data: 02010000000000000002000000003b9aca00000000000000000000000000000000
./wallet.rb:90:in `build_transaction': undefined method `build_tx' for #<Mastercoin::Cli::Wallet:0x00000002054ab8> (NoMethodError)
        from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
        from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
        from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
        from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
        from ./wallet.rb:169:in `<main>'

[jim618]

If MultiBit can do 'sendmany' transactions then yes; you can use MultiBit to senyd Mastercoin transactions uses the old style transactions; although I would not suggest you do this.

I doubt it can do that.. so now that I can't use Multibit or qt(due to space restriction) you suggest me to wait for a light-wallet client to be developed?

MultiBit does not give the user the ability to do sendmany so if that is required to send MasterCoin it would not work.

It is a general issue with overlay networks in the blockchain. For instance at the Amsterdam conference one proposal for encoding  colored  coins was to use the order of the transaction inputs. This is 'squeezing in a sidechannel'. A client may very well create new legal transactions and transmit them that, because it does not understand the side channel, scrambles the data.

[zathras]

Too... many... hours...  Time to take a break...

Pleased to say I've got it sorted though - couldn't find good doco anywhere so went with reverse engineering - I now have a (what I believe to be) working method to put together multisig transaction hex from scratch...  I'll do some testing and broadcast one or two after some rest

Code:

0100000001a1a7ca5f86c8c5c1bdc367570b8714a75e4800cc97de5a0f47abb208a7eabd7f0100000000ffffffff03204e0000000000001976a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac204e0000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac204e000000000000475121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a000000000000000000000000000000052ae00000000

Code:

{
    "txid" : "8734f635c103ab1362a6466c4bc4a1d206426da1abfe603e8a6985df7b197bae",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "7fbdeaa708b2ab470f5ade97cc00485ea714870b5767c3bdc1c5c8865fcaa7a1",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "",
                "hex" : ""
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.00020000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8"
                ]
            }
        },
        {
            "value" : 0.00020000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
                ]
            }
        },
        {
            "value" : 0.00020000,
            "n" : 2,
            "scriptPubKey" : {
                "asm" : "1 021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575 020100000000000000020000000007f819a0000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "hex" : "5121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a000000000000000000000000000000052ae",
                "reqSigs" : 1,
                "type" : "multisig",
                "addresses" : [
                    "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
                    "1Nb68WTMCNXQ6LbJEyJEGft3ztWwSFcWLE"
                ]
            }
        }
    ]
}

[HammerFist]

I don't consider this high priority, as it seems pretty likely that reteP would recommend changes we are unwilling to make (like getting rid of MasterCoins or moving to an alt chain).

Awesome.  Just because Peter is intelligent and knows bitcoin well, don't follow him into the naysayer's world.  TJ Watson http://en.wikipedia.org/wiki/Thomas_J._Watson, president of IBM at the time and very well versed in computers said: "I think there is a world market for maybe five computers" - in 1943.  In the early days, those near the top are largely limited by engineering constraints.  When free thinkers ignore some engineering difficulties to permit a grander view - huge things can be done.  We'll figure out the bloat problem - lets carry on with the big project.  Willet is correct in dismissing Peter the know-it-all naysayer.  Press on brave soldiers.

[murraypaul]

The issue is that there is no good reason to be using the Bitcoin blockchain. All the issues that being encountered with how to encode transactions are completely unnecessary, and would be avoided, if this was an altcoin instead. Then you could design  a network that exactly matched what you were trying to do, rather than the nasty hacks you are having to use instead.
The reason to use the Bitcoin blockchain is to freeload on the existing network, and avoid having to build your own infrastructure.
That is a purely pragmatic decision, and is leading to bad design.