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

[Tachikoma]

Suggestion: put your protocol documentation in a git repo along with a reference to the git commit hashes of one or more implementations of the protocol. If a new type of transaction is sufficiently well defined to be something that should be Mastercoin "officially", PGP sign a statement saying so and saying on what block # this takes effect.

The PGP isn't really the important thing FWIW, it's having a solid definition of what's what and making that public.

This is a good idea, it will come in handy when/if we need to stop supporting older messages.


I've been prototyping the obfuscation using SHAed receiving addresses as XOR. I think for ease of use it will be better to also use a SHA of the address for the first key, this makes it more consistent. Having said that I would appreciate it if somebody could try to decode the following Simple Send.

02d52c390e52f1110410078a9db148e7a0ee924666fb10aaaa9bffcc2e2ecde300 using address 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B.

This is tricky and I'm not sure I'm doing it right. I already love the fact that it looks much more like a real key then the old method

[1714186462]

1714186462

[1714186462]

1714186462

[zathras]

Suggestion: put your protocol documentation in a git repo along with a reference to the git commit hashes of one or more implementations of the protocol. If a new type of transaction is sufficiently well defined to be something that should be Mastercoin "officially", PGP sign a statement saying so and saying on what block # this takes effect.

The PGP isn't really the important thing FWIW, it's having a solid definition of what's what and making that public.

This is a good idea, it will come in handy when/if we need to stop supporting older messages.


I've been prototyping the obfuscation using SHAed receiving addresses as XOR. I think for ease of use it will be better to also use a SHA of the address for the first key, this makes it more consistent. Having said that I would appreciate it if somebody could try to decode the following Simple Send.

02d52c390e52f1110410078a9db148e7a0ee924666fb10aaaa9bffcc2e2ecde300 using address 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B.

This is tricky and I'm not sure I'm doing it right. I already love the fact that it looks much more like a real key then the old method

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!

[zathras]

I'm 95% sure it's safe to ignore them.

Code:

13NRX88EZbS5q81x6XFrTECzrciPREo821, 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B, 1.337
13NRX88EZbS5q81x6XFrTECzrciPREo821, 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B, 0.00000013
13NRX88EZbS5q81x6XFrTECzrciPREo821, 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B, 0.00000011
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 157L78NE1PB1CjRKnXKNWjwXzroyeA9dkt, 0.5
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 15irickEziQ8qdTuT75adX15zDLrySM32W, 1.0
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 1.234
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 2.0
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 1.0
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 2.5
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 1.234
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 1.5

These are the valid multi-sig transactions, as you can see all of them are from Zathras and me. Just need to make sure Zathras didn't use any of these transactions for real.

Nope, they're all self-to-self.  

Also just so somebody doesn't come back in years to come and say we made this decision without looking at all the current multisig Mastercoin transactions, Masterchest has a few more than the above list so here is the full list from my implementation - note it does not change the conclusion that all of these transactions are those of myself & Tachikoma.

Code:

be8f8ea4d88dff8b6c04aad1ef5e6d8e5b9d5cf637f0c7b9f98cbbcfeff00e98, 13NRX88EZbS5q81x6XFrTECzrciPREo821, 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B, 133700000, 2
7e57ac70cc0a1a4eacce92dfff9a1362a017433bb1d1167d654325dce76d9b7c, 13NRX88EZbS5q81x6XFrTECzrciPREo821, 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B, 11, 2
9de348c35488f4142f4e080a80737a3965d6de473360d974d361dd8ca107152a, 13NRX88EZbS5q81x6XFrTECzrciPREo821, 1J2svn2GxYx9LPrpCLFikmzn9kkrXBrk8B, 13, 2	
3e3d345974ab7764830498694fa10ef2a9b688a4694556ee5a36d520fb5ff3ca, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 150000000, 1
72b135a3d97a478b4c3dc8766c39e9f758ad7b81a34f8ed092affcf603ff39bb, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 123400000, 1
4bdc8f5ee4906bb0723d48c390abff3ac8e15f00a6029266e32301b37bd8236c, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 250000000, 1
6b8a15f5dcc2f7a463a795ab105abcadf442669a96ddb20021b383523155196d, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 100000000, 1
826c4eb686b7c8b31acb2cb6f62e3397ba881b989fe71d2a46f2debdecabd7de, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 100000000, 1
885fb185eeee351c992ea24fdf2cdd894226f2622ace944f7ba7a78a2c8b30b0, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 200000000, 1
da71fcbeb3b9b2e36b497bf31c27f4a5f8ced772762a9484164087370ff5e47a, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 100000000, 1
dc87d24a1d5c490525dcb6162165c95cf4b1fbbb8bfcacb649962270dfd3d3f1, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 15irickEziQ8qdTuT75adX15zDLrySM32W, 100000000, 1
3418509f6e11e0c60ee777e1af3ed50c223ea70f520ec97e81ca9746ff9ede15, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8, 20000000, 1
fc442e22d1d54333cd73a006195bef85a004bf3ee8b896a090c1f8f910268e7c, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 123400000, 1
7fd9422f4ba0ac216581fa4f2d5f1f10575e1596691f5ac20a958ac1a6c07284, 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb, 157L78NE1PB1CjRKnXKNWjwXzroyeA9dkt, 112345678, 1
9db8fb5171b586baa73754720644e3ad600f82dfa336985e9d8eafe39ead065d, 1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826, 157L78NE1PB1CjRKnXKNWjwXzroyeA9dkt, 50000000, 1

As such my vote would be to scrub compatibility for these clear-text transactions while we have no transactions in the wild to provide backwards compatibility for.  (Note I would be adamantly against this if we had any transactions we couldn't identify as ours, but since we know with certainty they're all ours I'm satisfied with dropping support for them).  

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

[Bitoy]

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


For a cleartext Mastercoin packet (used in Tachikoma's example) of 01000000000000000200000000000003e80000000000000000000000000000 this would give us an obfuscated

Thanks for the detaied explanation.

For simple send the transaction type is 0.   first 4 bytes should be 00?  (Why is it 01)

[zathras]

it's not perfect but guys feel free to have a read of a draft appendix to the spec I've been putting together to button up tight how we're storing data.  JR can obviously choose to use as is or just select bits (or none at all).

I'd still like to clean it up some more and flesh out a few of the details but feedback welcome, feel free to tear it apart if needed

I've updated to reflect the additional SHA256 hashing in the obfuscation step and add a little more detail on using multiple outputs to use more than two packets etc. Link

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!

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.

[zathras]

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


For a cleartext Mastercoin packet (used in Tachikoma's example) of 01000000000000000200000000000003e80000000000000000000000000000 this would give us an obfuscated

Thanks for the detaied explanation.

For simple send the transaction type is 0.   first 4 bytes should be 00?  (Why is it 01)

No problems

The first byte is the sequence number.  Sequence numbers started at one in Tachikoma's original multisig and as per the latest revision also start at one for the suggested amendments (as we need a positive sequence number for our obfuscation process).

[Paleus]

Hello Guys,

I have a few questions I wanted to ask before I commit to joining the development team here. I've been reading the various articles and white papers on Mastercoin relentlessly over the last few days and I feel I have a good understanding of the objectives and vision behind the currency.

In regards to the currency coding contest, making an exchange, do we plan on hosting the site on mastercoin.org or where and who would the exchange be run by?

I'm very interested in working on a BTC to MasterCoin exchange, however do we plan on making this the monopoly exchange or is there going to be room for competitors to move in once Mastercoin is more established? Any details about the plans we have moving forward to build an exchange would be excellent. I want to make sure I understand how a distributed exchange would work completely.

Also, if we need a grounds for development and testing, I have an awesome domain space at Diginomics.com we could use. Perhaps this would be a suitable location for developing the exchange or a similar project?

I will await the opinion of JR & co., but I am willing to put my best foot forward and help this project realize potential in any way possible.

Cheers,

Paleus

[Bitoy]

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  =)

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

 

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


For a cleartext Mastercoin packet (used in Tachikoma's example) of 01000000000000000200000000000003e80000000000000000000000000000 this would give us an obfuscated

Thanks for the detaied explanation.

For simple send the transaction type is 0.   first 4 bytes should be 00?  (Why is it 01)

No problems

The first byte is the sequence number.  Sequence numbers started at one in Tachikoma's original multisig and as per the latest revision also start at one for the suggested amendments (as we need a positive sequence number for our obfuscation process).

[zathras]

Hello Guys,

I have a few questions I wanted to ask before I commit to joining the development team here. I've been reading the various articles and white papers on Mastercoin relentlessly over the last few days and I feel I have a good understanding of the objectives and vision behind the currency.

In regards to the currency coding contest, making an exchange, do we plan on hosting the site on mastercoin.org or where and who would the exchange be run by?

I'm very interested in working on a BTC to MasterCoin exchange, however do we plan on making this the monopoly exchange or is there going to be room for competitors to move in once Mastercoin is more established? Any details about the plans we have moving forward to build an exchange would be excellent. I want to make sure I understand how a distributed exchange would work completely.

Also, if we need a grounds for development and testing, I have an awesome domain space at Diginomics.com we could use. Perhaps this would be a suitable location for developing the exchange or a similar project?

I will await the opinion of JR & co., but I am willing to put my best foot forward and help this project realize potential in any way possible.

Cheers,

Paleus

Hey Paleus,

The exchange will not be hosted anywhere (actually that's not strictly true; technically it'll be hosted in the bitcoin blockchain) and is not 'run' by anyone (it behaves as per the rules we define in the protocol).  It's a distributed exchange, it'll run directly within the various wallets - decentralized currency exchange without the middle man - that's not a small part of what we're trying to achieve here.  Data for the exchange is stored like any other Mastercoin data - for example buy/sell offers are themselves Mastercoin transactions

Whilst the exchange itself won't be a centralized website, there will no doubt be websites tracking the various exchange rates on offer - in fact I think this is one of the criteria in the next coding contest.

Hope that helps

EDIT: for clarity

[zathras]

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.

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.

[Tachikoma]

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.

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.

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.

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.

[Bitoy]

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.

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]

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.

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

[zathras]

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.

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)

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!

[Bitoy]

Thanks Tachikoma and  Zathras ,


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



How do you check for ecdsa?

[Tachikoma]

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.

[Tachikoma]

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.

[Bitoy]

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

[Tachikoma]

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: <REMOVED FOR NOW :) >
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.

[vokain]

dream team