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

[Tachikoma]

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"
                ]
            }
        }
    ]
}

I think you almost have it but it seems you might be using the wrong input n; I think your vout should be 0 not 1; but I might be mistaken there.

Which Ruby version are you using currently? The script somehow thinks the builder is not included; while it certainly should be.

[zathras]

I think you almost have it but it seems you might be using the wrong input n; I think your vout should be 0 not 1; but I might be mistaken there.

Good eye Tachikoma, vout should be 0 not 1 yep.  Thanks.  

Which Ruby version are you using currently? The script somehow thinks the builder is not included; while it certainly should be.

Code:

ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]

Also if it helps - Ruby was installed with rvm, mastercoin-ruby installed with gem install. I'm really green on Ruby though so it could be environment related.

[HammerFist]

there is no good reason to be using the Bitcoin blockchain.
The reason to use the Bitcoin blockchain is to freeload on the existing network

Obviously, the network is well established.  This is a very good reason to use bitcoin.  'freeload' is a dumb word.  Everyone who uses bitcoin for whatever their own purpose may be 'freeloads' the same as Mastercoin.  Mastercoin pays the same transaction fees all others pay.  If the load is overly burdensome, raise the fees.  Mastercoin hasn't asked for a discount on fees.  Mastercoin loves the bitcoin protocol.  Master is a protocol layer on top of the bitcoin protocol. It relies fully on the bitcoin rules. 

People against Master haven't put forth any legitimate reasons why it should be stopped.  Bloat is agnostic and comes the same equally with every transaction whether Mastercoin or not.  Bloat problems existed before Mastercoin.  If there were no mastercoin and bitcoin became wildly popular - we'd still have a bloat problem.  Mastercoin is merely the first system to come which will put a serious load on the chain.  Many other uses of bitcoin could have cause an equal load.  Mastercoin didn't invent the bloat problem - stop saying the solution to bloat is to exclude Mastercoin.  Bitcoin foundation will find a great solution to bloat and that won't include exclusion of great systems which load the chain more than Satoshi imagined in the beginning.

[Tachikoma]

I think you almost have it but it seems you might be using the wrong input n; I think your vout should be 0 not 1; but I might be mistaken there.

Good eye Tachikoma, vout should be 0 not 1 yep.  Thanks.  

Which Ruby version are you using currently? The script somehow thinks the builder is not included; while it certainly should be.

Code:

ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]

Also if it helps - Ruby was installed with rvm, mastercoin-ruby installed with gem install. I'm really green on Ruby though so it could be environment related.

Hmm that should work! What actually might work better is installing the actual wallet app I made; it dumps the transaction I create in a format that bitcoind's decoderawtransaction can decode. That way you can compare the transactions in the same format (Bitcoin ruby dumps it in a different ruby format). Check the log file in ~/.mastercoin-wallet/debug.log and look for the hex string there after the json dump. You might want to comment out the line that actually relays the transaction if you don't want to actually send anything yet.

[jgarzik]

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.

nValue is the bitcoin amount, in satoshis.

GetSerializeSize() is the serialization of the transaction output, not the script.

[dacoinminster]

For complete financial transparency:

---------- Forwarded message ----------
From: J.R. Willett
Date: Tue, Oct 1, 2013 at 8:12 AM
Subject: Notice of proposed expenditures
To: Mastercoin Board


Please be advised of a couple upcoming payments from MasterCoin project funds.

$45.90 in BTC to 1CTctpqg7JdomAeq3fz7Ynw43VDVJjc4o3 to reimburse David's purchase of a couple MasterCoin-related domains
1 BTC to 1KLoFjuq6o4Q6RGNdDSdHoWjazQqQLRnmH to Mich for our slick new website

I'll try to process these tomorrow if I don't hear any objections.

Thanks!

[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.

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.

I think if we remove the requirement to have outputs be for the same amount I think we're going to run up against a lot of transactions that are ambiguous.  It's worth pointing out that in multisig transactions the seq number now always starts with 0, so there are no sequence numbers to help us distinguish destination vs change outputs.

Let's say we remove the requirement for outputs to be for the same amount & allow any value to be used, example tx:

Output 1: 0.0005 (what is this output for? change or destination?)
Output 2: 0.0043 (what is this output for? change or destination?)
Output 3: 0.0006 (easily identifiable as Exodus from the address used)
Output 4: 0.001 (easily identifiable as multisig)

I'm not sure how we'd determine destination vs change in that scenario.  

If we really wanted to remove the same amount requirement, perhaps we could:
* drop a few bytes of checksum for the destination address in the data pubkey?
* require that mastercoin clients always make the change address the same as the sending address?

I'm keen to firm this up as I notice people are trading thousands of dollars on the buyer/seller thread and once I throw a windows desktop wallet into the mix I think there will be an increasing level of transactions - it's critical to our success that our community have confidence a valid transaction now will not be invalidated in future, and vice versa that an invalid transaction now will not become valid in future (hence my desire to explicitly lock in 'simple send' transaction processing rules).

Please let me know if there is a set of transaction processing rules that I've somehow glossed over or if I'm missing something obvious (eg destination address will always be vout1 of the sendmany transaction) but I haven't seen anything stated.

Thanks!

[Tachikoma]

I think if we remove the requirement to have outputs be for the same amount I think we're going to run up against a lot of transactions that are ambiguous.  It's worth pointing out that in multisig transactions the seq number now always starts with 0, so there are no sequence numbers to help us distinguish destination vs change outputs.

Actually all my multisig sequences start with 1 because otherwise I couldn't create valid looking ECDSA points. Could you check your implementation if you can get that to work? If so we should probably switch to 0.

If we really wanted to remove the same amount requirement, perhaps we could:
* drop a few bytes of checksum for the destination address in the data pubkey?
* require that mastercoin clients always make the change address the same as the sending address?

I have been doing the latter; making sure the change always goes back to the sending address. It makes sense since you need funds to keep making transactions and it makes the parsing much easier. By forcing such rules we also force users to start using real clients with multisig support instead of using the parasitic address version.

[grazcoin]

I think if we remove the requirement to have outputs be for the same amount I think we're going to run up against a lot of transactions that are ambiguous.  It's worth pointing out that in multisig transactions the seq number now always starts with 0, so there are no sequence numbers to help us distinguish destination vs change outputs.

Actually all my multisig sequences start with 1 because otherwise I couldn't create valid looking ECDSA points. Could you check your implementation if you can get that to work? If so we should probably switch to 0.

If we really wanted to remove the same amount requirement, perhaps we could:
* drop a few bytes of checksum for the destination address in the data pubkey?
* require that mastercoin clients always make the change address the same as the sending address?

I have been doing the latter; making sure the change always goes back to the sending address. It makes sense since you need funds to keep making transactions and it makes the parsing much easier. By forcing such rules we also force users to start using real clients with multisig support instead of using the parasitic address version.

I am more for optimization of the multisig tx, so I repeat my previous suggestion at:
https://bitcointalk.org/index.php?topic=265488.msg3143365#msg3143365

how about having only 2 outputs:

• dust limit to 1EXoDus
• All the rest to the BIP11 that includes [changeAddr, (modified)recipientAddr, dataAddr]

This is not very different from what we have now. We just drop 2 extra outputs (to recipientAddr and to changeAddr).
In order to avoid spending of the tx by the recipient address, we would modify it lightly (e.g. by changing the first 0 to 1), so it is still readable, but it can't sign the tx. By using this method we avoid the need to differ between the outputs (there are only one simple and one multisig).

[Mooshire]

Now what do I do with the 2 mastercoins I have XD

[murraypaul]

If we really wanted to remove the same amount requirement, perhaps we could:

Design a protocol and blockchain that actually support what you need to do?

I know noone wants to hear this, but you are having all these problems just encoding a simple altcoin A->B transaction.
How much worse it is going to be when you are trying to trade coins built on top of MasterCoin, or implement distributed exchanges, or any of the other cool ideas?
You have created an altcoin, but rather than running an altcoin blockchain, you are trying to cram your information into someone else's blockchain.

You are trying to take a car chassis and transmission and built an aircraft.
You might eventually manage it, but it will be one hell of an ugly aircraft, and probably won't fly well.

[Tachikoma]

how about having only 2 outputs:

• dust limit to 1EXoDus
• All the rest to the BIP11 that includes [changeAddr, (modified)recipientAddr, dataAddr]

This is not very different from what we have now. We just drop 2 extra outputs (to recipientAddr and to changeAddr).
In order to avoid spending of the tx by the recipient address, we would modify it lightly (e.g. by changing the first 0 to 1), so it is still readable, but it can't sign the tx. By using this method we avoid the need to differ between the outputs (there are only one simple and one multisig).

We don't have to change the recipient address, as far as I know you can only use public keys, not addresses. The problem is that you can't just make a public key that looks like an address since it's hex only. We could convert an address to hex but this would increase the amount of bytes needed for encoding. The other problem is that multisigs are harder to spent then a normal address at the moment. However this could be tackled by automatically creating a 'clean-up' transaction from a mastercoin-client that looks for all multisigs and send them to a normal address.

[dacoinminster]

Wow. Dread Pirate Roberts in jail, silk road seized, bitcoin prices plummeting.

Just a reminder: the contest is for $25k, not a specific number of bitcoins. I was thinking of making the next contest for a specific number of bitcoins, but . . . maybe not.

This is a good opportunity to mention something important: once we have features which COULD be used for illegal things, all devs should make sure to have really bold and visible warnings that everyone is responsible to know the laws in their own jurisdiction, and not break them. We must never be seen as encouraging illegal activity, even though our tools can be used in that way.

[TraderTimm]

If we really wanted to remove the same amount requirement, perhaps we could:

Design a protocol and blockchain that actually support what you need to do?

I know noone wants to hear this, but you are having all these problems just encoding a simple altcoin A->B transaction.
How much worse it is going to be when you are trying to trade coins built on top of MasterCoin, or implement distributed exchanges, or any of the other cool ideas?
You have created an altcoin, but rather than running an altcoin blockchain, you are trying to cram your information into someone else's blockchain.

You are trying to take a car chassis and transmission and built an aircraft.
You might eventually manage it, but it will be one hell of an ugly aircraft, and probably won't fly well.

Don't forget being targeted for encouraging money-laundering. If you think this 'protocol' idea isn't going to be under scrutiny from the Federal authorities, you're mistaken.

I'd recommend dacoinminster to return all the funds and take his ball and go home, before he ends up in a cell next to Dread Pirate Roberts.

But of course, he'll rationalize a way not to suspend development.

[dacoinminster]

Don't forget being targeted for encouraging money-laundering. If you think this 'protocol' idea isn't going to be under scrutiny from the Federal authorities, you're mistaken.

I'd recommend dacoinminster to return all the funds and take his ball and go home, before he ends up in a cell next to Dread Pirate Roberts.

But of course, he'll rationalize a way not to suspend development.

To my knowledge, nothing we are doing breaks any laws. We are building tools, which users could use to break laws, just like any tool.

Speaking of dangerous tools, this whole silk road situation brings to the forefront of my mind something that has been percolating for awhile. The MasterCoin protocol could be rather trivially extended to support decentralized e-commerce. For instance:

• Define a message for declaring what you are selling, your alias name and a link to a webpage with more info (if webpage gets taken down, simply rebroadcast this message with a new URL)
• Define a message for a buyer to initiate a purchase, with funds held in escrow by the protocol
• Define a message for a seller to accept a purchase initiated by a buyer (required before a buyer can complete payment and leave feedback)
• Define a message for a buyer to complete the transaction (either destroy funds in escrow or pay them to seller)
  
  • Includes feedback as a rating number and a link to a webpage with feedback comments
  • If purchase is completed successfully, a percentage of funds are destroyed (to make it more expensive to create fake feedback) Percentage can be lower once seller is established)

If we made something like this, it would then be possible to parse these messages to create a list of sellers and their reputations (and buyers and their reputations). Identities would be tied to bitcoin addresses. Payments would be in MasterCoin (or MasterCoin-derived currencies).

I'm not sure we'll ever do this though. I'm not sure there are enough legal use cases to justify it!

[TraderTimm]

To my knowledge, nothing we are doing breaks any laws. We are building tools, which users could use to break laws, just like any tool.

Carefully consider why Satoshi took great pains to be anonymous.

Do you really think that anything built upon your 'protocol' won't be subject to reprisal? If anything, it will be a "live" simulation of how governments react when they have a target.

You're either horribly naive, or fatally idealistic to think this is going to end well.

[W2014]

Finally back up - any developments? 

[bitcoinian]

and...... we're back

[grazcoin]

Finally back up - any developments?  

The blackout did only good to mastercoin-tools:
https://bitcointalk.org/index.php?topic=291914.msg3290646#msg3290646

Added

• send mastercoin transaction (the real thing, not "advisor")
• implement sending and parsing of "simple multisig"

simple multisig

• dust limit to 1EXoDus
• all the change to BIP11 1-of-2
  
  • pubkey1 is the one of the sender (redeemable)
  • pubkey2 is recipientHex+dataHex+padding

on the blockchain

• Mastercoin tx:
  https://blockchain.info/tx/aa64fd6088532156a37670e6cbd175c74bb101f1406517613a1a0ae6bc02fb02
  
• Test Mastercoin tx:
  https://blockchain.info/tx/298a6af50089184f7b434c700f83f390d5dfdd5dac10b39b95f99036a5c66df7
  

parsing

Code:

$ python msc_parse.py -t aa64fd6088532156a37670e6cbd175c74bb101f1406517613a1a0ae6bc02fb02
[I] main: {'currency_type_str': 'Mastercoin', 'transaction_type_str': 'Simple send', 'currencyId': '00000001', 'transaction_method_str': 'multisig_simple', 'recipientAddress': '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX', 'padding': '000000', 'amount': '0000000002faf080', 'changeAddress': '182osbPxCo88oaSX4ReJwUr9uAcchmJVaL', 'formatted_amount': '0.50000000', 'baseCoin': '00', 'dataSequenceNum': '45', 'transactionType': '00000000'}
$
$ python msc_parse.py -t 298a6af50089184f7b434c700f83f390d5dfdd5dac10b39b95f99036a5c66df7
[I] main: {'currency_type_str': 'Test Mastercoin', 'transaction_type_str': 'Simple send', 'currencyId': '00000002', 'transaction_method_str': 'multisig_simple', 'recipientAddress': '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX', 'padding': '000000', 'amount': '0000000000000003', 'changeAddress': '182osbPxCo88oaSX4ReJwUr9uAcchmJVaL', 'formatted_amount': '0.00000003', 'baseCoin': '00', 'dataSequenceNum': '45', 'transactionType': '00000000'}
$

outputs results
https://github.com/grazcoin/mastercoin-tools/blob/master/outputs/parse-with-multisig-simple.log

redeem multisig
https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES

help on commands

Code:

$ python msc_send.py -h
Usage: msc_send.py [options]

Options:
    -h, --help            show this help message and exit
    -m TX_METHOD, --transaction-method=TX_METHOD
                          basic or multisig
    -c CURRENCY_ID, --currency-id=CURRENCY_ID
                          1 for Mastercoin, 2 for Test Mastercoin
    -a AMOUNT, --amount=AMOUNT
                          amount of coins
    -x FEE, --fee=FEE     fee for transaction
    -r RECIPIENT_ADDRESS, --recipient=RECIPIENT_ADDRESS
                          recipient address
    -f FROM_ADDRESS, --from=FROM_ADDRESS
                          from address or pubkey
    -p PRIV_KEY, --private-key=PRIV_KEY
                          private key for signing the tx (overrides from
                          address)
    -k, --key-prompt      prompt for hidden private key for signing the tx
                          (overrides from address)
    -s HOST_PORT, --send-tx=HOST_PORT
                          transmit tx to specific bitcoin node HOST:PORT
    -b, --broadcast-tx    broadcast tx to bitcoin network
    -d, --debug           turn debug mode on

Code:

$ python msc_parse.py -h
Usage: msc_parse.py [options]

Options:
  -h, --help            show this help message and exit
  -d, --debug           turn debug mode on
  -t SINGLE_TX, --transaction=SINGLE_TX
                        hash of a specific tx to parse

[Tachikoma]

I really like your idea of using uncompressed public keys versus compressed keys. The only problem I have with it is that according to my knowledge the public key you build is not a valid ECDSA point.

Code:

0046727d1b3d6847f9ed344561a315f54b801edf637cad93d000450000000000000002000000000000000300000000000000000000000000000000000000000000

A public key should either start with 04 or 02 your starts with 004. I don't see how this could be a valid public key. Could you, or somebody else, explain why this transaction has been accepted and mined? Even if I remove the leading zero and add it to the end my software recognises that it's not a valid point address.