Peter Todd



Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 22, 2013, 08:40:57 PM #123 Quote from: dacoinminster on October 22, 2013, 06:01:38 PM Quote from: grazcoin on October 22, 2013, 05: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 . . .

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. 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. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

Tachikoma



Offline



Activity: 938

Merit: 1000









Hero MemberActivity: 938Merit: 1000 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 22, 2013, 09:17:02 PM #124 Quote from: retep on October 22, 2013, 08: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 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.using addressThis 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 Electrum : the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported

zathras



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 23, 2013, 02:54:23 AM #125 Quote from: Tachikoma on October 22, 2013, 09:17:02 PM Quote from: retep on October 22, 2013, 08: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

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



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!

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! Smart Property & Distributed Exchange: Master Protocol for Bitcoin

zathras



Offline



Activity: 266

Merit: 250









Sr. MemberActivity: 266Merit: 250 Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 23, 2013, 03:37:40 AM

Last edit: October 23, 2013, 04:04:06 AM by zathras #126 Quote from: Tachikoma on October 22, 2013, 08:40:19 PM



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.

I'm 95% sure it's safe to ignore them.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 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 atthe 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.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 Smart Property & Distributed Exchange: Master Protocol for Bitcoin

Paleus



Offline



Activity: 260

Merit: 100





www.diginomics.com







Full MemberActivity: 260Merit: 100www.diginomics.com Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) October 23, 2013, 06:57:09 AM #130



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



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 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 Bitcoin Aptitude Test