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

[Ola]

FYI I'm in the "Bitcoin Alternatives" panel today at the Bitcoin Europe conference today, will talk about Mastercoin.

This is great, break a leg.....I hope most people saw this:   http://thegenesisblock.com/btc-trading-corp-shutters-operations-cites-regulatory-environment/

 and know what it means for the first to market decentralized security exchange??

I have a happy announcement to make - mastercoin.org website is launched!
(DNS propagation might take a while)

If you have suggestions for improving the content of the website, please post them here.

I'd like to thank Mich Palmer for taking the time to setup the site, just in time for my talk today

This is great news, but you know the video on the website doesn't to much to introduce new people to mastercoin right?? and people have been asking about such an explainer...

[ripper234]

I have a happy announcement to make - mastercoin.org website is launched!
(DNS propagation might take a while)

If you have suggestions for improving the content of the website, please post them here.

I'd like to thank Mich Palmer for taking the time to setup the site, just in time for my talk today

This is great news, but you know the video on the website doesn't to much to introduce new people to mastercoin right?? and people have been asking about such an explainer...

You're right, I also think we need a better video.
Willet - do we have a bounty up for that?

[vokain]

We need more working, functioning developments on mastercoin before we do too much with a video I think. Ie at least the exchange and another milestone that exemplifies what the protocol will allow.

[ASICSRUS]

"..Mastercoin is a layer on top of bitcoin allowing creation or trades of escrow backed currencies and commodity without the licensing or regulatory limitation..."


sounds safe like mr pirates' pipedream ?  

+ ( escrow and bitcoin don't mix*per satoshiWP) LMAO

[ASICSRUS]

"..Mastercoin is a layer on top of bitcoin allowing creation or trades of escrow backed currencies and commodity without the licensing or regulatory limitation..."


sounds safe like mr pirates' pipedream ?  

+ ( escrow and bitcoin don't mix*per satoshiWP) LMAO

You have a good record of adding absolutely nothing of substance to the dialogue around here. Congratulations.

our group has been rooting for bitcoins since they traded at mear $zzz PPC !!! and i own MST Mastercoins investor and i'm alarmed by hijack blockchain UXTO collision!!! wow!

[hl5460]

I have a happy announcement to make - mastercoin.org website is launched!
(DNS propagation might take a while)

If you have suggestions for improving the content of the website, please post them here.

I'd like to thank Mich Palmer for taking the time to setup the site, just in time for my talk today

Good Job! The website has all the relevant information on MSC. I shall add it to my MSC Blog resources.

[zathras]

Quick update to say the wallet is progressing well & I've now implemented multisig support  Support for multisig transactions has been added to mastercoin.info also.

Tachikoma, regarding your test transactions...  

My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same
* With multisig, ref & exodus address/output amounts must be the same and multisig output should be (ref amount * 2) to avoid a rejected tx. The amount of the multisig output should be clarified (defined in the spec) - perhaps as (ref amount * num pub keys in multisig)?

The other test transactions you did had the multisig output amount as (refaddress amount * 2) but not in this particular tx (https://blockchain.info/tx/cf0edfdd0a9e4d8aea2f87fc2cec6a367e1686a1fe066390ac195a797d76c0f1).

I realize one reason it's invalid is because the sending address didn't have sufficient funds.

In my implementation the transaction is not even queued for processing/validity checking at all due to the amount on the multisig output not being (ref amount * 2) so even if the sending address did have sufficient funds I'd still throw the tx out.

I guess to summarize, would you have considered it an otherwise valid tx if the sending address would have had enough coins? Or would your implementation also throw it out based on the multisig output amount?

Appreciate your thoughts on this.  Thanks.

[Tachikoma]

Quick update to say the wallet is progressing well & I've now implemented multisig support  Support for multisig transactions has been added to mastercoin.info also.

Awesome!

Tachikoma, regarding your test transactions...  

My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same

I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction.

* With multisig, ref & exodus address/output amounts must be the same and multisig output should be (ref amount * 2) to avoid a rejected tx. The amount of the multisig output should be clarified (defined in the spec) - perhaps as (ref amount * num pub keys in multisig)?

Well the problem is that I picked the ref amount * 2 pretty random. The only reason I did it was that if I used just the ref amount the transaction would not be accepted by a bitcoind instance and I still can't for the life of me figure out why. I was hoping that your quest for building multisig transactions could perhaps shed some light on it. I think we should figure out why the normal ref amount is not enough for a valid transaction and only update the spec once we find that out.

The other test transactions you did had the multisig output amount as (refaddress amount * 2) but not in this particular tx (https://blockchain.info/tx/cf0edfdd0a9e4d8aea2f87fc2cec6a367e1686a1fe066390ac195a797d76c0f1).

I realize one reason it's invalid is because the sending address didn't have sufficient funds.

In my implementation the transaction is not even queued for processing/validity checking at all due to the amount on the multisig output not being (ref amount * 2) so even if the sending address did have sufficient funds I'd still throw the tx out.

I guess to summarize, would you have considered it an otherwise valid tx if the sending address would have had enough coins? Or would your implementation also throw it out based on the multisig output amount?

Appreciate your thoughts on this.  Thanks.

Yeah the only reason my system flags it as invalid is because it was sent from an account that did not hold coins.

If you could do some tests with your transaction creation process and see if you can send multisig with a normal amount and not * 2 I would highly appreciate it

[Tachikoma]

Wallet Alpha

The first alpha version of my wallet implementation is available and I need some testers to help me out

For now I want to ask people that are comfortable with Bitcoin and Linux/OS X to step forward and try it out (Windows won't work and might never work. Luckily we have Zathras for that . For now there is no single executable that can be run so you will have to be comfortable around a terminal to run it. To the other developers please peer-review the code and make sure vital things such as private key encoding in the config-file is secure.

This version will still allow you to create and relay transactions even if the address does not own Mastercoins this makes testing easier and reduces the risk of sending transactions you did not intent to send. So feel free to use a brand new address when testing it out.

The main dependencies are the Qt framework (most distributions have it in their package managers, make sure you get a version >= 4) and Ruby >= 1.9.2. Once these dependencies are satisfied you can install the app using the rubygems package mastercoin-wallet (gem install mastercoin-wallet).

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

[zathras]

Tachikoma, regarding your test transactions...  

My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same

I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction.

I believe this is actually already explicitly defined by JR both in his comments and the spec.  It's less about the value of the amount, more that all outputs have the same amount.

All protocol transactions should have the same output amount. If one output is different, that is the change address.

(From the spec)
All transaction outputs should be for the same amount, which should be above the “dust” threshold, and should include an appropriate fee to ensure that miners include them in the block chain in a timely manner. For instance, the first MasterCoin transactions had three outputs of 0.00006 BTC each, with a 0.0001 BTC transaction fee.

Based on the above those rules are applied in my implementation and I require all outputs to be for the same amount.  The exception is multisig where I've temporarily allowed the multisig output amount to be ref/exodus amount * 2 while we firm up the discussion.

* With multisig, ref & exodus address/output amounts must be the same and multisig output should be (ref amount * 2) to avoid a rejected tx. The amount of the multisig output should be clarified (defined in the spec) - perhaps as (ref amount * num pub keys in multisig)?

Well the problem is that I picked the ref amount * 2 pretty random. The only reason I did it was that if I used just the ref amount the transaction would not be accepted by a bitcoind instance and I still can't for the life of me figure out why. I was hoping that your quest for building multisig transactions could perhaps shed some light on it. I think we should figure out why the normal ref amount is not enough for a valid transaction and only update the spec once we find that out.

As you note you found during testing that your transactions were rejected using the same output amount and thus you had to double it.  I was under the impression this was proposing that we amend the spec to state multisig outputs = ref amount * n (so ref*2 for 1-of-2, ref*3 for 1-of-3 etc).  I had not realized you'd chosen the *2 amount just as a value to get the transaction through (I shouldn't make assumptions!).  Without an amendment to the spec we're basically saying all multisig transactions thus far are invalid (as they don't meet the 'All protocol transactions should have the same output amount' requirement).

In a nutshell we either need to amend the spec to allow the multisig output to be different to ref/exodus outputs (eg ref*2 for 1-of-2, ref*3 for 1-of-3 etc) or identify/resolve whatever problem it was you had keeping the multisig output amount the same as the ref/exodus outputs.

I'll do some testing with my implementation and start sending some transactions to dig a bit deeper into this to see what I can come up with.

Thanks, and well done on the wallet alpha

EDIT:

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.

Do you happen to recall/have notes on what error was returned?

[Tachikoma]

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.

Do you happen to recall/have notes on what error was returned?

I think I got a very non-informative tx-reject (error 22). I think the debug log mentioned something about it being a non-standard transaction. I will check it out tonight if I can find some time

[jgarzik]

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.

Do you happen to recall/have notes on what error was returned?

I think I got a very non-informative tx-reject (error 22). I think the debug log mentioned something about it being a non-standard transaction. I will check it out tonight if I can find some time

That's because the amount is below the dust threshold (0.000534 or thereabouts).

[Tachikoma]

This would mean I used a very small output to begin with, sadly I did not keep my rejected transactions around. I will see what I can find out tonight, thanks for the suggestion.

[NewLiberty]

Mastercoin is the friendliest hostile fork I've seen in a long time.

[samson]

Mastercoin is the friendliest hostile fork I've seen in a long time.

Maybe implementing this in one of the alternate blockchains would be an idea for consideration.

Apparently there's a colored coin launching using Florin today.

[bitcool]

Mastercoin is the friendliest hostile fork I've seen in a long time.

Maybe implementing this in one of the alternate blockchains would be an idea for consideration.

Apparently there's a colored coin launching using Florin today.

It needs to overcome OP's snub against altcoins, unlikely.

[Tachikoma]

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.

Do you happen to recall/have notes on what error was returned?

I think I got a very non-informative tx-reject (error 22). I think the debug log mentioned something about it being a non-standard transaction. I will check it out tonight if I can find some time

That's because the amount is below the dust threshold (0.000534 or thereabouts).

This transaction is getting flagged as invalid.

Code:

{
    "txid" : "88b32ad8a0b9181c97ce1cab49ea745621c05ac20fe90364b72bb18c4f88896b",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "9de348c35488f4142f4e080a80737a3965d6de473360d974d361dd8ca107152a",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "3045022100a5a61491ee0682342140dbe7846be08e1ce1f0361fb3fc758ef66ee434a83e8a02203aaea5ba9cacb3e9ec7eff736436882258add92f17b09c58b11b6c4296b10b5a01 04e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f",
                "hex" : "483045022100a5a61491ee0682342140dbe7846be08e1ce1f0361fb3fc758ef66ee434a83e8a02203aaea5ba9cacb3e9ec7eff736436882258add92f17b09c58b11b6c4296b10b5a014104e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.00938000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 19fd7459d1c21227f3e87582fa1de350b1549ae2 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a91419fd7459d1c21227f3e87582fa1de350b1549ae288ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "13NRX88EZbS5q81x6XFrTECzrciPREo821"
                ]
            }
        },
        {
            "value" : 0.00006000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 bad510ef5889498cc9340ec00d71733440817b77 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914bad510ef5889498cc9340ec00d71733440817b7788ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B"
                ]
            }
        },
        {
            "value" : 0.00006000,
            "n" : 2,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
                ]
            }
        },
        {
            "value" : 0.00006000,
            "n" : 3,
            "scriptPubKey" : {
                "asm" : "1 04e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f 02010000000000000002000000000000000e000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "hex" : "514104e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee3419a40b939c24ac813c692a323ca5207a6fb387ffe28e48f706c95dbf46648f2102010000000000000002000000000000000e00000000000000000000000000000052ae",
                "reqSigs" : 1,
                "type" : "multisig",
                "addresses" : [
                    "13NRX88EZbS5q81x6XFrTECzrciPREo821",
                    "1BByZwb4cTUL3mWzNE4XqJXCZiFTX7Z48f"
                ]
            }
        }
    ]
}

Now as far as I am concerned this is not hitting the output dust threshold. The dust limit is 0.0000534 (I think you forgot a zero). An all outputs are larger then this limit.

Bitcoind debug.log reports "ERROR: CTxMemPool::accept() : nonstandard transaction type".

[killerstorm]

Now as far as I am concerned this is not hitting the output dust threshold.

Dust threshold depends on the size of the output:

Code:

bool IsDust(int64 nMinRelayTxFee) const
    {
        // "Dust" is defined in terms of CTransaction::nMinRelayTxFee,
        // which has units satoshis-per-kilobyte.
        // If you'd pay more than 1/3 in fees
        // to spend something, then we consider it dust.
        // A typical txout is 34 bytes big, and will
        // need a CTxIn of at least 148 bytes to spend,
        // so dust is a txout less than 54 uBTC
        // (5460 satoshis) with default nMinRelayTxFee
        return ((nValue*1000)/(3*((int)GetSerializeSize(SER_DISK,0)+148)) < nMinRelayTxFee);
    }

It is 5460 satoshis for a typical output, but is larger for your multi-sig one.

[dacoinminster]

Tachikoma, regarding your test transactions...  

My understanding of the discussions so far provides for the following requirements for what I guess you could call a properly formatted Mastercoin transaction:
* Without multisig, all 3 address/output amounts must be the same

I wouldn't even make it that strict (unless J.R. already wrote that in the spec) if I want to send more bitcoins then I should be free to do so and it should not invalidate the Mastercoin transaction.

I believe this is actually already explicitly defined by JR both in his comments and the spec.  It's less about the value of the amount, more that all outputs have the same amount.

All protocol transactions should have the same output amount. If one output is different, that is the change address.

(From the spec)
All transaction outputs should be for the same amount, which should be above the “dust” threshold, and should include an appropriate fee to ensure that miners include them in the block chain in a timely manner. For instance, the first MasterCoin transactions had three outputs of 0.00006 BTC each, with a 0.0001 BTC transaction fee.

Based on the above those rules are applied in my implementation and I require all outputs to be for the same amount.  The exception is multisig where I've temporarily allowed the multisig output amount to be ref/exodus amount * 2 while we firm up the discussion.

Having all the outputs be the same amount is merely a convenience for identifying the change address. I'm fine with a less strict implementation as long as it is still possible to identify the change address.

[Tachikoma]

Now as far as I am concerned this is not hitting the output dust threshold.

Dust threshold depends on the size of the output:

Code:

bool IsDust(int64 nMinRelayTxFee) const
    {
        // "Dust" is defined in terms of CTransaction::nMinRelayTxFee,
        // which has units satoshis-per-kilobyte.
        // If you'd pay more than 1/3 in fees
        // to spend something, then we consider it dust.
        // A typical txout is 34 bytes big, and will
        // need a CTxIn of at least 148 bytes to spend,
        // so dust is a txout less than 54 uBTC
        // (5460 satoshis) with default nMinRelayTxFee
        return ((nValue*1000)/(3*((int)GetSerializeSize(SER_DISK,0)+148)) < nMinRelayTxFee);
    }

It is 5460 satoshis for a typical output, but is larger for your multi-sig one.

Yeah I was just about to post that; I will see if I can calculate the needed size to prevent the dust limit whilst creating the transaction.

Can anybody verify that in the code example above; nValue is the (Bitcoin) amount and (int)GetSerializeSize(SER_DISK,0) the bytesize of the output script.