300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 58.

Bitoy

sr. member

Activity: 449

Merit: 250

I was able to decode the 1st packet

Code:

Data to Parse: 02d52c390e46f1110410078a9db1482ba4cf924666fb1b41689be9cc2e2ecde3e5
OBFUSCATED MASTERCOIN PACKET: d52c390e46f1110410078a9db1482ba4cf924666fb1b41689be9cc2e2ecde3
SHA256 HASH: d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344
REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 0100000014000000020000000000cc07c9000000000bebc200160000000000

Clear text looks ok

01: 1 (01)
Trans Type: 20 (00000014)
Currency ID: 2 (00000002)
Amount for Sale: 13371337 (0000000000cc07c9)
BTC Desired: 200000000 (000000000bebc200)
Time Limit: 1 (1)

But have a problem on the 2nd

Code:

Data to Parse: 026c17b960d1aa810b6f736760a03166dec0ecc617de661915e06981d5d88f28b5
OBFUSCATED MASTERCOIN PACKET: 6c17b960d1aa810b6f736760a03166dec0ecc617de661915e06981d5d88f28
SHA256 HASH: 4266395eef8a3a62fb74ed5ff4d6201573fd51318fce9eaf452eecb3ab9a8ba9
REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 2e71803e3e20bb6994078a3f54e746cbb311972651a887baa5476d667315a3

Should the 2nd packet be 2x sha?

Quote from: Tachikoma on October 23, 2013, 10:47:32 AM

Ok! With all this new found knowledge let's try decoding this 'Selling Mastercoins for Bitcoins' (SMFB from now on) message again.

Code:

XOR Reference: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
Clear text Mastercoin message:
Result: 02d52c390e46f1110410078a9db1482ba4cf924666fb1b41689be9cc2e2ecde3e5, 026c17b960d1aa810b6f736760a03166dec0ecc617de661915e06981d5d88f28b5

Some notes. When I SHA the reference I only take the first 62 bytes since this is the exact amount we need for the obfuscation. This will change the the SHA of the next iteration of hashes that follow so I'm open to discuss this.

Once we agree on the output of these keys I think it's safe to try and broadcast a message

Edit: Updated keys since I forgot to increment the amount of hashes.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Bitoy on October 23, 2013, 10:23:32 AM

Quote from: Tachikoma on October 23, 2013, 09:01:29 AM

I use OpenSSL to check ECDSA validity. I believe Zathras has an implementation you could probably use since he is also using something Microsoft(y) to create his code, excuse my ignorance I'm not sure what language you are using Zathras.

Zathras is using Microsoft .net. Zathras, can I borrow your ecdsa validity check and multi sig sending module Wink

.NET yep. The most recent changes haven't made their way into the masterchest library yet as they're in a separate codebase (you can still use the encodetx function to build the cleartext mastercoin packet but that function also builds the entire transaction, not just the packet so you'll have to pull the relevant data out of the final raw transaction hex). I'll have a modified version up with new functions for encoding/decoding reflecting the suggested amendments over the weekend.

For ECDSA validity (I'll also put a check function into the masterchest library) I took my inspiration from the casascius bitcoin address utility - have a read through some of the pubkey and ECDSA stuff to point you in the right direction.

Thanks!

zathras

sr. member

Activity: 266

Merit: 250

Quote from: dacoinminster on October 23, 2013, 02:15:53 PM

Quote from: jadair10 on October 23, 2013, 01:57:34 PM

JR,

Can you add a link in the OP to where the discussion begins for *this* contest so people can jump right to the new discussion? https://bitcointalksearch.org/topic/m.3381794

Good idea. Done!

Is the contest actually running now btw? FYI I'm (and think Tachikoma is also) still spending my time to properly achieve the goals of the last contest (storing data in the blockchain) as I don't feel that's actually finished yet (though we're close).

Thanks

zathras

sr. member

Activity: 266

Merit: 250

Posting this here too as I think it's a critical issue we need to clear up as it affects a transaction in the wild:

Quote from: zathras on October 23, 2013, 07:22:08 PM

Quote from: Tachikoma on October 23, 2013, 04:51:22 PM

I've checked it out and fixed it, your transaction shows up on mastercoin-explorer now.

It will probably show up on Masterchest as well since I can't find anything wrong with it.

Please understand that we are currently working hard on a new encoding standard which requires us to reparse the data a lot, during these times our sites might not miss some transactions or perhaps not display them correctly. This is all very cutting edge software so things might go wonky from time to time.

Sorry guys have to be quick - back to back meetings today.

Long story short according to the current rules that transaction is not valid due to ambiguous sequence numbers, this is why masterchest.info throws the transaction out.

19b5BiXWZERFoCNhVKiYDf9i829P1W1wiE has a sequence number of 94
19UjqqjXmQxyyn4xStA7mWXVkzXwVDgu7Z has a sequence number of 93
19feAR37pguLwDyEMc8oiW2WT4esrgR5z6 has a sequence number of 95

Quote from: dacoinminster on September 30, 2013, 11:25:01 AM

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.

So I removed the requirement for outputs to be the same amount to allow for multisig outputs no longer meeting said requirement. So as it stands now I no longer evaluate what the value is of each vout, only the sequence numbers matter.

I think we need some further discussion on backwards compatibility for these Class A transactions. Perhaps we need to re-introduce the 'same output amount' rule as a requirement just for Class A transactions as we can then use the amounts to help identify change as per the original spec - at the moment there seems to be some ambiguity around Class A transaction validity between our implementations and we need to clear this up. You can probably understand now why I'm putting so much effort into having these rules explicitly defined and documented

I do concur that random chance of sequence number collisions should not be a factor in transaction validity.

None of this is an issue in multisig as we require change to be from the sender as a method of removing address ambiguity.

Could I please suggest the parties involved in this transaction just hold for a little, while the development team have a discussion around Class A transaction validity.

Thanks!

EDIT: for clarity

Tachikoma

hero member

Activity: 938

Merit: 1000

Cool, glad we are getting up-to-date! I still need to rewrite mastercoin-explorer with the new obfuscation code. So much to do, so little time

I will take a few minutes to verify your key.

Edit: Confirmed, looks good!

grazcoin

sr. member

Activity: 284

Merit: 250

I was trying to collect all the great ideas from you all, and implement them in mastercoin-tools send and parse.
It includes:
1. using compressed pubkeys.
2. using only valid ecdsa points.
3. obfuscating the data.
4. ignore all previous multisig experiments

All code available on the head on https://github.com/grazcoin/mastercoin-tools

The first transaction was generated with debug on:

Code:

$ python msc_send.py -m multisig -c 1 -a 0.12345678 -x 0.0001 -r 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX -f 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL -k -d
[I] main: Using settings: {'broadcast': False, 'recipient_address': '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX', 'fee': '0.0001', 'from_address': '182osbPxCo88oaSX4ReJwUr9uAcchmJVaL', 'key_prompt': True, 'host_port': None, 'currency_id': 1, 'amount': '0.12345678', 'debug_mode': True, 'priv_key': None, 'tx_method': 'multisig'}
Enter your private key:
[I] main: Private key was entered
[D] main: plain dataHex: --0100000000000000010000000000bc614e0000000000000000000000000000--
[D] main: obfus dataHex: 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd4
[I] get_nearby_valid_pubkey: trying 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd4
[I] get_nearby_valid_pubkey: trying 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd5
[I] get_nearby_valid_pubkey: trying 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd6
[I] get_nearby_valid_pubkey: valid 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd7
[D] main: valid dataHex: 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd7
[D] main: change address is 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL
[D] main: receipent is 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX
[D] main: total inputs value is 34000
[D] main: fee is 10000
[D] main: dust limit is 5430
[D] main: BIP11 script is 1 [ 031f204911ec19cb5b7b10dd87ccf6a52552466d14356212e881288512eeff8e20 ] [ 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd7 ] 2 checkmultisig
Added input 886710238086cdc020d2e74c9c1773648beb9c55aac9c154d4ca5b8b9fedccd3:1
Added output sending 5430 Satoshis to 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P.
Added output sending 5430 Satoshis to 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX.
Added output sending 10860 Satoshis to 1 [ 031f204911ec19cb5b7b10dd87ccf6a52552466d14356212e881288512eeff8e20 ] [ 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd7 ] 2 checkmultisig.
[D] main: inputs_outputs are /dev/stdout -i 886710238086cdc020d2e74c9c1773648beb9c55aac9c154d4ca5b8b9fedccd3:1 -o 1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P:5430 -o 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX:5430 -o 5121031f204911ec19cb5b7b10dd87ccf6a52552466d14356212e881288512eeff8e2021021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd752ae:10860
[D] main: parsed tx is {'inputs': [{'previous_output': '886710238086cdc020d2e74c9c1773648beb9c55aac9c154d4ca5b8b9fedccd3:1', 'sequence': 4294967295, 'address': None, 'script': ''}], 'locktime': 0, 'version': 1, 'hash': '797ace6b846b99c2182ca4ab31734de4ae96fa180b25d870e8b813cd66687fd6', 'outputs': [{'address': '1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P', 'value': 5430, 'script': 'dup hash160 [ 946cb2e08075bcbaf157e47bcb67eb2b2339d242 ] equalverify checksig'}, {'address': '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX', 'value': 5430, 'script': 'dup hash160 [ 46727d1b3d6847f9ed344561a315f54b801edf63 ] equalverify checksig'}, {'address': None, 'value': 10860, 'script': '1 [ 031f204911ec19cb5b7b10dd87ccf6a52552466d14356212e881288512eeff8e20 ] [ 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd7 ] 2 checkmultisig'}]}
[I] sign: signing tx
[I] main: validating tx: Status: Success
[I] main: SIGNED tx (multisig) of 0.12345678 Mastercoin to 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX signed by 182osbPxCo88oaSX4ReJwUr9uAcchmJVaL
0100000001d3cced9f8b5bcad454c1c9aa559ceb8b6473179c4ce7d220c0cd868023106788010000008b483045022100b42b3facdafdd9033e5572e745dbc2704efb985b0bc0002d2629b00b90d42d6e02205fede2b0a26e3f296dc0c223341176426ca958a0b09be17b8d51c6c4f39fcb210141041f204911ec19cb5b7b10dd87ccf6a52552466d14356212e881288512eeff8e2084ddff9997fdfb22fae6b09a255e3937a7890491ab5106ce7912bc253e430887ffffffff0336150000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac36150000000000001976a91446727d1b3d6847f9ed344561a315f54b801edf6388ac6c2a000000000000475121031f204911ec19cb5b7b10dd87ccf6a52552466d14356212e881288512eeff8e2021021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd752ae00000000
[I] parse_test: {'tx_hash': 'unknown', 'tx_type_str': 'Simple send', 'from_address': '182osbPxCo88oaSX4ReJwUr9uAcchmJVaL', 'currencyId': '00000001', 'padding': '000000', 'tx_method_str': 'multisig', 'amount': '0000000000bc614e', 'currency_str': 'Mastercoin', 'formatted_amount': '0.12345678', 'to_address': '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX', 'baseCoin': '00', 'dataSequenceNum': '01', 'transactionType': '00000000'}
[I] main: please send using "sx broadcast-tx signed_tx.tx"

A commentary for to the debug log:

The padded dataHex is 0100000000000000010000000000bc614e0000000000000000000000000000
After obfuscation (using sha256 of the string '17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX') and adding 02 at the beginning and a random tail, it becomes 021bf733f7aab3932560cd8e8a3ec11b45ee47f0694a0b61c86ab48e63bba57cd4
Within 4 iterations of searching for a valid pubkey (each time adding 1), a valid one is found.
A transaction is created and signed.
A parsing test shows the same values.

On blockchain.info, the transaction looks this way. Note that the input used for the transaction was too small to include also change (the change was less than the dust limit), so all the under-dust change got added to the fee. The fee then increased to 0.0001228 instead of the requested 0.0001.

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: jadair10 on October 23, 2013, 01:57:34 PM

JR,

Can you add a link in the OP to where the discussion begins for *this* contest so people can jump right to the new discussion? https://bitcointalksearch.org/topic/m.3381794

Good idea. Done!

jadair10

newbie

Activity: 52

Merit: 0

Quote from: dacoinminster on September 11, 2013, 07:40:56 PM

This thread is devoted to the current MasterCoin contest (this thread was originally for contest #1).

JR,

Can you add a link in the OP to where the discussion begins for *this* contest so people can jump right to the new discussion? https://bitcointalksearch.org/topic/m.3381794

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: Bitoy on October 23, 2013, 10:23:32 AM

Quote from: Tachikoma on October 23, 2013, 09:01:29 AM

I use OpenSSL to check ECDSA validity. I believe Zathras has an implementation you could probably use since he is also using something Microsoft(y) to create his code, excuse my ignorance I'm not sure what language you are using Zathras.

Zathras is using Microsoft .net. Zathras, can I borrow your ecdsa validity check and multi sig sending module Wink

I'll speak to this: feel free to use anybody's code. Just please be clear that you are doing so and don't try to take credit for it when payout time comes. If other people build on Zathras' code, the contest rules state that his payout gets bigger (how much it gets bigger is subjective, based on our collective feelings about how much his code sharing helped achieve the contest goals)

Redundancy is helpful too - if you write your own version of the code, the differences will help find bugs. The payouts in the last contest reflected this, with four people getting a share of the pot with a lot of overlap between their work.

I agree with vokain about the work you guys are doing - I couldn't be happier.

vokain

legendary

Activity: 1834

Merit: 1019

dream team

Tachikoma

hero member

Activity: 938

Merit: 1000

Ok! With all this new found knowledge let's try decoding this 'Selling Mastercoins for Bitcoins' (SMFB from now on) message again.

Code:

XOR Reference: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
Clear text Mastercoin message:
Result: 02d52c390e46f1110410078a9db1482ba4cf924666fb1b41689be9cc2e2ecde3e5, 026c17b960d1aa810b6f736760a03166dec0ecc617de661915e06981d5d88f28b5

Some notes. When I SHA the reference I only take the first 62 bytes since this is the exact amount we need for the obfuscation. This will change the the SHA of the next iteration of hashes that follow so I'm open to discuss this.

Once we agree on the output of these keys I think it's safe to try and broadcast a message

Edit: Updated keys since I forgot to increment the amount of hashes.

Bitoy

sr. member

Activity: 449

Merit: 250

Quote from: Tachikoma on October 23, 2013, 09:01:29 AM

I use OpenSSL to check ECDSA validity. I believe Zathras has an implementation you could probably use since he is also using something Microsoft(y) to create his code, excuse my ignorance I'm not sure what language you are using Zathras.

Zathras is using Microsoft .net. Zathras, can I borrow your ecdsa validity check and multi sig sending module Wink

Tachikoma

hero member

Activity: 938

Merit: 1000

We haven't discussed what we will use to XOR data for a 'Selling MasterCoins for Bitcoins' package. I want to propose using the sending address whenever a Mastercoin message does not contain a recipient address.

Tachikoma

hero member

Activity: 938

Merit: 1000

I use OpenSSL to check ECDSA validity. I believe Zathras has an implementation you could probably use since he is also using something Microsoft(y) to create his code, excuse my ignorance I'm not sure what language you are using Zathras.

Bitoy

sr. member

Activity: 449

Merit: 250

Thanks Tachikoma and Zathras ,

(Hurray! I feel like a student who (barely) passed the exam

How do you check for ecdsa?

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Tachikoma on October 23, 2013, 04:14:53 AM

This transaction is using a public keys that are not valid ECDSA points. In my implementation these were rejected.

Ahh thanks perfect yep that makes sense, I don't do a ECDSA point validity check for the current multisig.

Quote from: Bitoy on October 23, 2013, 04:54:25 AM

Thanks again Zathras,

Missing some paddings in my code. ( Will re-read the multi-sig protocol =)

The code below is for sending 188 "satoshi" master coin.

Oops, yep you're right (I just popped 188 into my old multisig encodetx function forgetting to add the 00000000s) Wink

Quote from: Bitoy on October 23, 2013, 04:54:25 AM

if sending 188 MSC, Is this code correct?

Code:

REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 0100000000000000010000000460913c000000000000000000000000000000
SHA256 HASH: d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344
OBFUSCATED MASTERCOIN PACKET: d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3
FINAL RESULT: 02d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3b4

Yep, that code looks correct! As Tachikoma mentioned you'll need to rotate the last byte as the key isn't a valid ECDSA point at the moment, but other than that looks good!

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: Bitoy on October 23, 2013, 04:54:25 AM

Thanks again Zathras,

Missing some paddings in my code. ( Will re-read the multi-sig protocol =)

The code below is for sending 188 "satoshi" master coin.

Quote from: zathras on October 23, 2013, 02:45:00 AM

Code:

REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 01000000000000000100000000000000bc0000000000000000000000000000
SHA256 HASH: D42C390E52F1110412078A9DB148E7A306924666FB10AAAA9BFFCC2E2ECDE344
OBFUSCATED MASTERCOIN PACKET: D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3
FINAL RESULT: 02D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3B4

if sending 188 MSC, Is this code correct?

Code:

REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 0100000000000000010000000460913c000000000000000000000000000000
SHA256 HASH: d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344
OBFUSCATED MASTERCOIN PACKET: d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3
FINAL RESULT: 02d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3b4

You are almost there! The only thing you are missing is making sure the final result is a valid ECDSA point. In your case it's not, manipulate the last two characters until it is

Bitoy

sr. member

Activity: 449

Merit: 250

Thanks again Zathras,

Missing some paddings in my code. ( Will re-read the multi-sig protocol =)

The code below is for sending 188 "satoshi" master coin.

Quote from: zathras on October 23, 2013, 02:45:00 AM

Code:

REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 01000000000000000100000000000000bc0000000000000000000000000000
SHA256 HASH: D42C390E52F1110412078A9DB148E7A306924666FB10AAAA9BFFCC2E2ECDE344
OBFUSCATED MASTERCOIN PACKET: D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3
FINAL RESULT: 02D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3B4

if sending 188 MSC, Is this code correct?

Code:

REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 0100000000000000010000000460913c000000000000000000000000000000
SHA256 HASH: d42c390e52f1110412078a9db148e7a306924666fb10aaaa9bffcc2e2ecde344
OBFUSCATED MASTERCOIN PACKET: d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3
FINAL RESULT: 02d52c390e52f1110413078a9db528769f06924666fb10aaaa9bffcc2e2ecde3b4

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: zathras on October 22, 2013, 10:37:40 PM

EDIT: Tachikoma, I checked a few transactions against mastercoin-explorer and the reason your list is shorter is there are some transactions that my implementation flags as valid where yours does not. An example would be 7fd9422f4ba0ac216581fa4f2d5f1f10575e1596691f5ac20a958ac1a6c07284. Please don't spend too much time on it if we're dropping support for them anyway, but if you have the info to hand I'd be interested to know the reason for the invalid flags? Thanks

This transaction is using a public keys that are not valid ECDSA points. In my implementation these were rejected.

Quote from: zathras on October 23, 2013, 12:44:56 AM

After looking at is this further it's probably unnecessary and just adds complexity. I'm testing what kind of compute we'd use to simply test each packet against hashing S times (up to 255) until the decoded output has a sequence number of S. For most transactions with just a few packets or less we'd be testing only a few values of S against each packet.

I even think the public keys are saved in order. So if you create a transaction that as the public keys in the correct order you might not even have to test the keys. Although it's probably safer to do it anyway.

Quote from: zathras on October 23, 2013, 02:45:00 AM

Quote from: Bitoy on October 23, 2013, 02:18:11 AM

btw In Tachikoma's example 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B is the sender's address?

I don't think he specified, but as the amendment stands right now the reference (recipient) address is used.

Yeah this was the recipient address.

Quote from: zathras on October 22, 2013, 09:54:23 PM

You're on the money there Tachikoma. You have a Mastercoin transaction, simple send, test mastercoin with an amount of 0.00001000.

For everyone else, let's break this down.

So we have our reference address of 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B.

We convert to bytes (UTF8) and SHA256 them, then take the resulting 32 bytes as hex (in this example said hex string is D42C390E52F1110412078A9DB148E7A306924666FB10AAAA9BFFCC2E2ECDE344). We then take the first 31 bytes of our hash and XOR with the 31 byte cleartext Mastercoin packet.

For a cleartext Mastercoin packet (used in Tachikoma's example) of 01000000000000000200000000000003e80000000000000000000000000000 this would give us an obfuscated Mastercoin packet of D52C390E52F1110413078A9DB14A1D5386924666FB10AAAA9BFFCC2E2ECDE3. We then simply prepend the address identifer (02) and append a random byte before checking for ECDSA validity.

Thus we have the obfuscated public key (02) d52c390e52f1110410078a9db148e7a0ee924666fb10aaaa9bffcc2e2ecde3 (00). Tachikoma, I noticed you used 00 but I think we should use random byte testing rather than sequencial for the ECDSA manipulation byte as that contributes to the obfuscation (random might cost a few more CPU cycles if we need to test 10 or 20 bytes but it's not expensive work & using sequential means most of our keys will end in 00 or 01).

I'm also doing some thinking on supporting multiple OP_MULTISIG outputs to increase our packet count >2 and how we would order packets to know how many nested SHA passes to apply when decoding. At the moment I'm playing with having just the first byte of the packet (the sequence number) XOR with a fixed value across the transaction (say the last byte of the ref address) - that we we can always easily decode the sequence number as X, then we know we need to run X sha256 passes to decrypt the rest of the packet. Hopefully that makes sense!

I'll update the appendix with this info when I get a mo.

Thanks!

Thanks for verifying my key

I agree that a random manipulation byte is probably a better option so I will change that.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Bitoy on October 23, 2013, 02:18:11 AM

Zathras,

Ok I think I got it.

Here is the code generated, for a simple send 188 Mastercoins using address 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B

02d52c390e52f1110413078a9db528769f06924666b4

('02' is fixed and the last 2 hex 'b4' are random)

Can anyone verify =)

Your final result is only 22 bytes, your final result should be 33 bytes.

To send 188 Mastercoins to address 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B you should get (assuming seq num=1):

Code:

REFERENCE ADDRESS: 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B
CLEARTEXT MASTERCOIN PACKET: 01000000000000000100000000000000bc0000000000000000000000000000
SHA256 HASH: D42C390E52F1110412078A9DB148E7A306924666FB10AAAA9BFFCC2E2ECDE344
OBFUSCATED MASTERCOIN PACKET: D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3
FINAL RESULT: 02D52C390E52F1110413078A9DB148E7A3BA924666FB10AAAA9BFFCC2E2ECDE3B4

Then pass that final result through an ECDSA test to ensure it's a valid point and if not rotate that last byte again.

Quote from: Bitoy on October 23, 2013, 02:18:11 AM

btw In Tachikoma's example 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B is the sender's address?

I don't think he specified, but as the amendment stands right now the reference (recipient) address is used.

Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 58. (Read 129207 times)