300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)

[grazcoin]

Thanks Grazcoin,

You are correct.
I didn't  add a version number in the transaction.   And the parser ignored the version number.  Will update this.

If version is 0, we should treat it as version 0, ignoring the action byte.   The transaction should still be valid.  

Btw if we allow version 0, won't that defeat the purpose of having an action byte?


+1 on invalidating all version 0 offer to sell.

Great!
So now we have to get the agreement from everyone else.
The disadvantage is that we will not have ready testing data, as there will be no valid DEx transactions.

[1715412502]

1715412502

[1715412502]

1715412502

[1715412502]

1715412502

[1715412502]

1715412502

[Bitoy]

That could also be an advantage since it will be easier to sync the test msc

Great!
So now we have to get the agreement from everyone else.
The disadvantage is that we will not have ready testing data, as there will be no valid DEx transactions.

[Bitoy]

Grazcoin,

Below is the msc spec on transaction version.  It looks like we will have to parse depending on the version number.   Previous transactions can't be invalidated.   

What if a user has an older version of a wallet.   It may lead to a fork if the old wallet uses a different version.

Transaction Definitions
The Master Protocol Distributed Exchange transactions are listed below. Transactions 0, 20, 21, 22 and 50 are to be implemented in the first deployment, per this spec. They are listed first. The other transactions will be fully defined and implemented in future releases.

Each transaction definition has its own version number to enable support for changes to each transaction definition. Up thru version 0.3.5 of this spec, the transaction type field was a 4 byte integer. Since there were only 17 transactions identified, the upper 3 bytes of the field had a value of 0. For all spec versions starting with 0.4, the first field in each transaction message is the 2 byte version number, with an initial value of 0 and the transaction type field is a 2 byte integer. So, each client must examine the first two bytes of the transaction message to determine how to parse the remainder of the message. If the value is 0, then the message is in the format specified in version 0.3.5 of this spec. If the value is at least 1, then the message is in the format associated with that version number.

Note: Master Protocol transactions are not reversible except as explicitly indicated by this spec.

[grazcoin]

Grazcoin,

Below is the msc spec on transaction version.  It looks like we will have to parse depending on the version number.   Previous transactions can't be invalidated.  

What if a user has an older version of a wallet.   It may lead to a fork if the old wallet uses a different version.

Transaction Definitions
The Master Protocol Distributed Exchange transactions are listed below. Transactions 0, 20, 21, 22 and 50 are to be implemented in the first deployment, per this spec. They are listed first. The other transactions will be fully defined and implemented in future releases.

Each transaction definition has its own version number to enable support for changes to each transaction definition. Up thru version 0.3.5 of this spec, the transaction type field was a 4 byte integer. Since there were only 17 transactions identified, the upper 3 bytes of the field had a value of 0. For all spec versions starting with 0.4, the first field in each transaction message is the 2 byte version number, with an initial value of 0 and the transaction type field is a 2 byte integer. So, each client must examine the first two bytes of the transaction message to determine how to parse the remainder of the message. If the value is 0, then the message is in the format specified in version 0.3.5 of this spec. If the value is at least 1, then the message is in the format associated with that version number.

Note: Master Protocol transactions are not reversible except as explicitly indicated by this spec.

My suggestion is just to invalidate sell offers of version 0, and keep any other transaction without change (all other version 0 of simple send and accept sell offer are valid).

Since the whole DEx is still not activated for MSC, there will be no damage. The balance of test mastercoins may be different if someone uses old software (which is not recommended anyway), but MSC balance will be the same.

The state machine that we have to keep already due to the new/modify/cancel is complicated enough within sell offer version 1 - we have to follow how much was sold on each generation of the sell offer modifications (there could be a long chain of modifications). If we do keep both version 0 and version 1 of sell offers, we *also* have to take care about interoperability between the sell offers of the different versions, e.g.:

• sell offer version 0 modification on top of new sell offer version 1 - e..g cancel using modify amount to zero valid? then how to parse further modification using version 0 and version 1?
• sell offer version 1 modification on top of new sell offer version 0 - is another modification using version 0 also valid?
• we keep the race condition within version 0
• we extend the race condition by using version 0 on top of previous version 1

[grazcoin]

Grazcoin,

Below is the msc spec on transaction version.  It looks like we will have to parse depending on the version number.   Previous transactions can't be invalidated.  

What if a user has an older version of a wallet.   It may lead to a fork if the old wallet uses a different version.

Transaction Definitions
The Master Protocol Distributed Exchange transactions are listed below. Transactions 0, 20, 21, 22 and 50 are to be implemented in the first deployment, per this spec. They are listed first. The other transactions will be fully defined and implemented in future releases.

Each transaction definition has its own version number to enable support for changes to each transaction definition. Up thru version 0.3.5 of this spec, the transaction type field was a 4 byte integer. Since there were only 17 transactions identified, the upper 3 bytes of the field had a value of 0. For all spec versions starting with 0.4, the first field in each transaction message is the 2 byte version number, with an initial value of 0 and the transaction type field is a 2 byte integer. So, each client must examine the first two bytes of the transaction message to determine how to parse the remainder of the message. If the value is 0, then the message is in the format specified in version 0.3.5 of this spec. If the value is at least 1, then the message is in the format associated with that version number.

Note: Master Protocol transactions are not reversible except as explicitly indicated by this spec.

My suggestion is just to invalidate sell offers of version 0, and keep any other transaction without change (all other version 0 of simple send and accept sell offer are valid).

Since the whole DEx is still not activated for MSC, there will be no damage. The balance of test mastercoins may be different if someone uses old software (which is not recommended anyway), but MSC balance will be the same.

The state machine that we have to keep already due to the new/modify/cancel is complicated enough within sell offer version 1 - we have to follow how much was sold on each generation of the sell offer modifications (there could be a long chain of modifications). If we do keep both version 0 and version 1 of sell offers, we *also* have to take care about interoperability between the sell offers of the different versions, e.g.:

• sell offer version 0 modification on top of new sell offer version 1 - e..g cancel using modify amount to zero valid? then how to parse further modification using version 0 and version 1?
• sell offer version 1 modification on top of new sell offer version 0 - is another modification using version 0 also valid?
• we keep the race condition within version 0
• we extend the race condition by using version 0 on top of previous version 1

An alternative suggestion which is more backwards compatible but still doesn't complicate the parsing state machine - and therefore it is less bugs prone:
Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).
Then we will still have enough data to check our DEx implementations with, and the only differences from 0.3.5 spec version would be with modified sell offers (there are anyway only VERY few such).
There would be no problem to keep accepting version 0 sell offers also later in production.

[dacoinminster]

An alternative suggestion which is more backwards compatible but still doesn't complicate the parsing state machine - and therefore it is less bugs prone:
Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).
Then we will still have enough data to check our DEx implementations with, and the only differences from 0.3.5 spec version would be with modified sell offers (there are anyway only VERY few such).
There would be no problem to keep accepting version 0 sell offers also later in production.

I think that sounds perfect.

[marvschneider]

Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).

There are two edge cases here -

• version 0 with Amount for sale = 0 (to cancel a sell offer) will produce a version 1 with Amount for sale = 0, which is not valid.
• version 0 with new values (to update a sell offer) will fail because it will look like an attempt to create a new sell offer while that address has one that's active

[dacoinminster]

Treat each sell offer version 0 exactly as a sell offer version 1 with action 1 (new).

There are two edge cases here -

• version 0 with Amount for sale = 0 (to cancel a sell offer) will produce a version 1 with Amount for sale = 0, which is not valid.
• version 0 with new values (to update a sell offer) will fail because it will look like an attempt to create a new sell offer while that address has one that's active

Note that this conversation is also taking place on our dev mailing list, and not everything is posted here.

Currently the consensus seems to be the above plus allowing version=0 with amount=0 to represent the cancel action on those old transactions.

[Bitoy]

Here is a new trans I posted from the wallet

2 byte trans version
1 byte action

fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58

Please check if it is correct.

[dexX7]

Thanks zathras and Bitoy!

To pick this up again, those are the API endpoints I found:

Code:

https://masterchest.info/mastercoin_verify/addresses.aspx
https://masterchest.info/mastercoin_verify/transactions.aspx?address=[ADDRESS]&currencyid=[CURRENCYID]

http://www.mymastercoins.com/jaddress.aspx?address=[ADDRESS]&currency_id=[CURRENCYID]
http://www.mymastercoins.com/jtransactions.aspx?address=[ADDRESS]&currency_id=[CURRENCYID]

https://masterchain.info/mastercoin_verify/addresses/[CURRENCYID - 1]
https://masterchain.info/mastercoin_verify/transactions/[ADDRESS]

[jakecnn]

Any guidance on what needs to be tested currently?

[dexX7]

With the faucet one significant expense is the transportation cost. To collect all those multi-sig outputs that are spendable I did this:

1. List and store all transactions for address X
2. Iterate over all outputs and store those which are from type "mutlisig" and require one signature and include address X
3. Create a raw transaction that spents such output from (2) for each potential output
4. If signrawtransaction for (3) returns "complete", this output is indeed spendable
5. Store all those and create a transaction that uses all spendable outputs as inputs and send the coins back to address X

This is how the result looks like:

https://blockchain.info/tx/21db95ecd700438bf46e0a435410c27ab0f235218a80afacd81db4fec5bf8260 (ignore the "script translation" from blockchain.info.. of course no OP_FALSE was used)


If you like to test this yourself, feel free to use this as basis:

https://gist.github.com/dexX7/9146763


For some odd reason my local bitcoind client started to return a success for outputs that are already spent and thus the whole approach fails now, because the success or failure of signing the tx determined, if an output shall to be considered as spendable. edit: there was one case where an output was added to the list two times.

I haven't looked at alternative implementations like sx or libbitcoin. I like to know, if one of those is worth to look at and if anyone of you guys here already worked on a solution for spending multisig outputs.

[grazcoin]

Here is a new trans I posted from the wallet

2 byte trans version
1 byte action

fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58

Please check if it is correct.

On my parsing it is still invalid:
https://masterchain.info/selloffer.html?tx=fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58&currency=MSC
and the invalid reason (hover red Invalid) is "invalid last data script in BIP 11".
or the json:
https://masterchain.info/tx/fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58.json

You data script is:
0002004e2002000000000000000000000000000000000000000000000000000000
and my internal parsing says:

parse_multisig: {'action': '0', 'should_be_zeros': '2000000000000000000000000000000000000000000', 'fee_required': '004e20'}

The relevant parsing code is the function parse_2nd_data_script:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_utils_parsing.py#L60

[Bitoy]

On my parsing it is still invalid:
https://masterchain.info/selloffer.html?tx=fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58&currency=MSC
and the invalid reason (hover red Invalid) is "invalid last data script in BIP 11".
or the json:
https://masterchain.info/tx/fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58.json

You data script is:
0002004e2002000000000000000000000000000000000000000000000000000000
and my internal parsing says:

parse_multisig: {'action': '0', 'should_be_zeros': '2000000000000000000000000000000000000000000', 'fee_required': '004e20'}

The relevant parsing code is the function parse_2nd_data_script:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_utils_parsing.py#L60

The action is 1 byte 8 bit unsigned integer.  
https://github.com/mastercoin-MSC/spec#field-sell-offer-sub-action

So instead of "2" (for update) I changed it to  "02"

[BasedForLife]

Are you seriously paying out 300?

[Westphalian]

Are you seriously paying out 300?

Yes.  More info on bounties here --> http://mastercointalk.org/index.php?topic=121.0

[StarenseN]

Are you seriously paying out 300?

Half (150 btc) have been already paid.

[ripper234]

Going forward we are paying out $100,000 each month, plus an additional amount of Dev MSC.

http://mastercointalk.org/index.php?topic=121.0

[grazcoin]

On my parsing it is still invalid:
https://masterchain.info/selloffer.html?tx=fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58&currency=MSC
and the invalid reason (hover red Invalid) is "invalid last data script in BIP 11".
or the json:
https://masterchain.info/tx/fdebcfcaf4d7bceddd206dc1f334d7c5ccb7a6890c0cfe9d7926be6d7d5e2f58.json

You data script is:
0002004e2002000000000000000000000000000000000000000000000000000000
and my internal parsing says:

parse_multisig: {'action': '0', 'should_be_zeros': '2000000000000000000000000000000000000000000', 'fee_required': '004e20'}

The relevant parsing code is the function parse_2nd_data_script:
https://github.com/grazcoin/mastercoin-tools/blob/master/msc_utils_parsing.py#L60

The action is 1 byte 8 bit unsigned integer.  
https://github.com/mastercoin-MSC/spec#field-sell-offer-sub-action

So instead of "2" (for update) I changed it to  "02"

OK. I updated also to "02".

[Bitoy]

Mymastercoins Wallet v 2 released.

http://mymastercoins.com/MyMSCWallet.aspx