Bitcoin Forum
April 24, 2014, 11:51:46 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 ... 65
  Print  
Author Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)  (Read 61138 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
dacoinminster
Hero Member
*****
Offline Offline

Activity: 910


Rational Exuberance


View Profile WWW

Ignore
October 22, 2013, 06:01:38 PM
 #121

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

1398383506
Hero Member
*
Offline Offline

Posts: 1398383506

View Profile Personal Message (Offline)

Ignore
1398383506
Reply with quote  #2

1398383506
Report to moderator
Unbeatable Service & Product Support
Grab Your Miners at GAWMiners.com
Order Before April 25th to receive
Double your Hashing Power for 1 week!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398383506
Hero Member
*
Offline Offline

Posts: 1398383506

View Profile Personal Message (Offline)

Ignore
1398383506
Reply with quote  #2

1398383506
Report to moderator
1398383506
Hero Member
*
Offline Offline

Posts: 1398383506

View Profile Personal Message (Offline)

Ignore
1398383506
Reply with quote  #2

1398383506
Report to moderator
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
October 22, 2013, 08:40:19 PM
 #122

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.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Peter Todd
Hero Member
*****
Offline Offline

Activity: 742

aka retep


View Profile

Ignore
October 22, 2013, 08:40:57 PM
 #123

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

Activity: 742



View Profile WWW

Ignore
October 22, 2013, 09:17:02 PM
 #124

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 Smiley

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
zathras
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
October 23, 2013, 02:54:23 AM
 #125

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

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
zathras
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
October 23, 2013, 03:37:40 AM
 #126

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 Smiley

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
October 23, 2013, 05:23:29 AM
 #127


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
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
October 23, 2013, 05:44:56 AM
 #128

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 Smiley

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.

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
zathras
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
October 23, 2013, 05:49:00 AM
 #129


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 Smiley

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

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Paleus
Jr. Member
*
Offline Offline

Activity: 48



View Profile WWW

Ignore
October 23, 2013, 06:57:09 AM
 #130

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

http://diginomics.com | Intelligent Money Worldwide | Development Fund: 1JML47aZXgotPKhm3PpMa99s46rgtiKCPt
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
October 23, 2013, 07:18:11 AM
 #131

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 Smiley

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
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
October 23, 2013, 07:22:29 AM
 #132

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 Smiley

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


Smart Property & Distributed Exchange: Master Protocol for Bitcoin
zathras
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
October 23, 2013, 07:45:00 AM
 #133

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.



Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
October 23, 2013, 09:14:53 AM
 #134

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 Smiley

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


Thanks for verifying my key Smiley

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

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
October 23, 2013, 09:54:25 AM
 #135

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
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
October 23, 2013, 10:02:21 AM
 #136

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 Smiley

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
zathras
Full Member
***
Offline Offline

Activity: 238



View Profile

Ignore
October 23, 2013, 10:13:29 AM
 #137

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

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!



Smart Property & Distributed Exchange: Master Protocol for Bitcoin
Bitoy
Sr. Member
****
Offline Offline

Activity: 336


View Profile

Ignore
October 23, 2013, 01:38:48 PM
 #138

Thanks Tachikoma and  Zathras ,


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



How do you check for ecdsa?
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
October 23, 2013, 02:01:29 PM
 #139

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.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Tachikoma
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW

Ignore
October 23, 2013, 02:13:49 PM
 #140

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.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported | Kojn: LTC/BTC Payment processor for merchants
Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 ... 65
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!