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

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Paleus on October 23, 2013, 01:57:09 AM

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

Bitoy

sr. member

Activity: 449

Merit: 250

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?

Quote from: zathras on October 23, 2013, 12:49:00 AM

Quote from: Bitoy on October 23, 2013, 12:23:29 AM

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

full member

Activity: 284

Merit: 122

www.diginomics.com

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

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Bitoy on October 23, 2013, 12:23:29 AM

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

sr. member

Activity: 266

Merit: 250

Quote from: zathras on October 22, 2013, 03:36:47 AM

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

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

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.

Bitoy

sr. member

Activity: 449

Merit: 250

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

sr. member

Activity: 266

Merit: 250

Quote from: Tachikoma on October 22, 2013, 03:40:19 PM

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

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Tachikoma on October 22, 2013, 04:17:02 PM

Quote from: Peter Todd on October 22, 2013, 03:40:57 PM

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!

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: Peter Todd on October 22, 2013, 03:40:57 PM

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

Peter Todd

legendary

Activity: 1120

Merit: 1152

Quote from: dacoinminster on October 22, 2013, 01:01:38 PM

Quote from: grazcoin on October 22, 2013, 12:11:43 PM

What about older multisig tx which are already on the blockchain?
The options I see are:
1. Parse the using the old method until some block height, and starting that height using the new method.
2. Ignore all old multisig tx - treat them as invalid.
3. Treat both old multisig method and new multisig method as valid tx.

I think (hope) that nobody transferred any major amount of money that way yet, at least, not to a different person than themselves. If somebody did transfer a bunch of money that way in good faith, we should try to support it . . .

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.

Also you guys really need to think through out the Mastercoin equiv of a soft-fork would work... killerstorm has a very good point re: that.

Tachikoma

hero member

Activity: 938

Merit: 1000

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.

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: grazcoin on October 22, 2013, 12:11:43 PM

What about older multisig tx which are already on the blockchain?
The options I see are:
1. Parse the using the old method until some block height, and starting that height using the new method.
2. Ignore all old multisig tx - treat them as invalid.
3. Treat both old multisig method and new multisig method as valid tx.

I think (hope) that nobody transferred any major amount of money that way yet, at least, not to a different person than themselves. If somebody did transfer a bunch of money that way in good faith, we should try to support it . . .

grazcoin

sr. member

Activity: 284

Merit: 250

What about older multisig tx which are already on the blockchain?
The options I see are:
1. Parse the using the old method until some block height, and starting that height using the new method.
2. Ignore all old multisig tx - treat them as invalid.
3. Treat both old multisig method and new multisig method as valid tx.

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: dacoinminster on October 22, 2013, 10:12:47 AM

This is brilliant. You guys are awesome.

I support the nested SHA256(address) method that Tachikoma and Zathras have been discussing here. I'll add the data in Zathras' appendix to the spec in some way.

In the unlikely event that we end up in a war with miners, we can always add the MSC balance of the address to what is being hashed, but I agree that shouldn't be done right now. At this point they would be more likely to target the Exodus Address anyway. If they ever do that, we can obfuscate the Exodus Address too (which would create unspendable UTXOs, so hopefully that won't be necessary)

Zathras, when you and Tachikoma feel the appendix is final, let me know, and I'll link to it from the OP of this thread.

grazcoin, I hope this sounds good to you too?

The appendix looks good, assuming that the nested SHA256 method is added.
I would suggest allowing another optional dust output without address limitations, mainly for class B, to allow cross-currency use (e.g. a second marker to a different exodus). Then the transactions could belong to two currencies and enable atomic exchange between them.

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

This is brilliant. You guys are awesome.

I support the nested SHA256(address) method that Tachikoma and Zathras have been discussing here. I'll add the data in Zathras' appendix to the spec in some way.

In the unlikely event that we end up in a war with miners, we can always add the MSC balance of the address to what is being hashed, but I agree that shouldn't be done right now. At this point they would be more likely to target the Exodus Address anyway. If they ever do that, we can obfuscate the Exodus Address too (which would create unspendable UTXOs, so hopefully that won't be necessary)

Zathras, when you and Tachikoma feel the appendix is final, let me know, and I'll link to it from the OP of this thread.

grazcoin, I hope this sounds good to you too?

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: jgarzik on October 22, 2013, 05:10:06 AM

The OP_RETURN patch for transaction metadata was just merged into bitcoin/bitcoin.git.

This is certainly interesting. Although I prefer compress keys because they offer more space this will mean that in the near future we could go back to address based communication.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Tachikoma on October 22, 2013, 04:34:26 AM

We could SHA the address an amount of times for each added output and use that to XOR the key.

The first would use just the address, the second output would SHA256(address), the third SHA256(SHA256(address)) etc.

That could work, I'll do some further testing. Thanks

Tachikoma

hero member

Activity: 938

Merit: 1000

We could SHA the address an amount of times for each added output and use that to XOR the key.

The first would use just the address, the second output would SHA256(address), the third SHA256(SHA256(address)) etc.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Tachikoma on October 22, 2013, 04:00:40 AM

Cool, if/when J.R. gives the go ahead I think we should create some test vectors so all our implementations will have the same result when XORing the data.

Testing may have answered this for us - it seems actually pubkey may not be such a good idea, I'll stick with addresses for now.

Since most of our data is zero, our XOR is returning an almost identical pubkey to the sender:

Code:

02 0100000000000000010000000002faf0800000000000000000000000000000 XX 'data to be encoded
02 1BFC32C40F01EFD61535CAE8B297257E536B140EE6C727F576698E70D24CF5 75 'senders pub key
02 1AFC32C40F01EFD61435CAE8B295DF8ED36B140EE6C727F576698E70D24CF5 XX 'obfuscated data pub key

The result would be great if we were not also including the senders pubkey elsewhere in the transaction. We thus have two very similar but slightly different pubkeys in the transaction. If we instead take 31 bytes from the address:

Code:

02 0100000000000000010000000002faf0800000000000000000000000000000 XX 'data to be encoded
1Cd ighsfdfRcj4ytQSskZgQXbUEamuMUNF 'reference address we take 31 bytes from for the XOR
02 464E554D756D614555625851675A6B7BFC7E7479346A7352666466736867 XX 'obfuscated data pub key

Using the address means a similar pub key won't be found anywhere else in the transaction so would be a better method for obfuscation.

Unfortunately this only goes for the first packet - but calls into question the second and subsequent packets, as if they're full of zeros also & we XOR against the same reference address bytes we're going to again end up with similar looking pubkeys.

Tachikoma

hero member

Activity: 938

Merit: 1000

Cool, if/when J.R. gives the go ahead I think we should create some test vectors so all our implementations will have the same result when XORing the data.

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