Awesome, love the insight. Agenda and the decisions don't match up though, kinda hard to match them right now. |
|
|
|
Ok! With all this new found knowledge let's try decoding this 'Selling Mastercoins for Bitcoins' (SMFB from now on) message again. 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. |
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
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. 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? 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 |
|
|
|
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. |
|
|
|
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 |
|
|
|
I'm 95% sure it's safe to ignore them. 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. |
|
|
|
Mastercoin-explorer is less strict at the moment then the other implementations, since it does not do some sequence checks. It might be related to that. Best wait for Zathras to come online. It's quite possible his daemon stopped processing new transactions and he simply needs to reboot it. I think this is likely since no new transactions have been added since this morning. |
|
|
|
Should I just hold on to them for now? I dont think I want to sell them but am not up to date on whats going on with mastercoin right now
I'm not in the position to give you advise about your investment, that's up to you. The output with the highest amount of BTC contributed gets the MSC. In your case this is 1Hkjo5N1CLb7XmUtCp4xWRder81CRfpdNd. Most likely this is a change address. You still have the private key for that address in all likelihood. Which client did you use for this transaction?
I used bitcoinqt, how do I do a transfer to the main address and how do i find the private key for the change address? You can use dumpprivkey from the console to get the private key for that address. You can use the advisor from J.R. to build a transaction that will send the MSC to a address you prefer. |
|
|
|
|
The output with the highest amount of BTC contributed gets the MSC. In your case this is 1Hkjo5N1CLb7XmUtCp4xWRder81CRfpdNd. Most likely this is a change address. You still have the private key for that address in all likelihood. Which client did you use for this transaction?
|
|
|
|
You can move them. There are some prototype wallets and you can always use the reference Bitcoin client to send transactions. It won't be super easy though |
|
|
|
You 'received' your Bitcoins when you send the payment. You can see your coins here. |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Awesome stuff Zathras.
Can anybody think of a reason to prefer the public key to the receiving address or visa-versa?
|
|
|
|
Another idea for obfuscation: instead of always flipping the most significant bit or flipping all bits (XOR with 0x80 or 0xFF), we could XOR with data which can only be known to someone parsing MasterCoin transactions. For instance, what if we run the user's MSC balance through SHA256, and then XOR that with the data that is being encoded. Only someone who knows the MasterCoin balance of the address could tell if the address was sending a MasterCoin transaction (aside from the Exodus Address tell, which could also be obfuscated if desired) . . .
That's probably too complicated for now, but if we get into a war with miners trying to exclude us, we have a LOT of options.
I think the question should be; how soon talking about months, do we expect such an "ASCII-protection" by miners to really become a standard. I honestly don't think we can even say with certainty that it will happen. However, since we are at the beginning stages now anyway it might be worth it to spend some extra effort in obfuscating the keys anyway. I think using data that only a Mastercoin parser would know is a great last option idea, but for now I would want to focus on something a little easier. How about we use the redeemable public key from the sender and impose it (xor it) over the data keys? I think it would great very random looking strings and it's easy to decode since the key is always easily available. |
|
|
|
|
Normally I try to stick to discussing the technical parts of Mastercoin but I want to offer my opinion about the whole clone discussion.
We are developing a protocol, we are not developing an investment vehicle. This might not be a popular opinion but in the end we want to build technology that enriches peoples lives by offering features Bitcoin currently lacks like distributed exchanges.
People will be able to clone Mastercoin and there is nothing we can do about that or even want to do about it.
|
|
|
|
I suggested supporting additionally the "compressed tx" (2 or 3 outputs) while keeping the "uncompressed tx" (4 outpus) as well.
GUI users could still use the "uncompressed tx".
I just don't want to develop the "compressed tx" if you guys don't intend to support it.
What problem are you solving by encoding the receiving address in the public key? I rather spend time working on implementing more of the protocol then rewriting the way we encode it at this moment. |
|
|
|
|
Show Posts
