Has it already been decided what the timestamping of events (order submission, order cancellation, order execution) of the distributed exchange will be? Seconds / milliseconds / microseconds / nanoseconds?
What will be the format of the data feed? This is important to know, based on the format, what third party frontends (if any) one will be able to hook up.
Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 55. (Read 129207 times)
October 26, 2013, 02:39:56 PM
October 26, 2013, 01:18:55 PM
Excellent, thank you both.
I will post an update tomorrow or early next week.
I will post an update tomorrow or early next week.
October 26, 2013, 12:36:37 PM
I've been underway with the BTC/MSC price ticker. So far I've completed some of the HTML framework and the stylesheet.
The repository is available here: https://github.com/travispatron/mastercoin-ticker
I have contacted BitcoinWisdom to gain some insight into how they have developed their Javascript framework, so I am hoping they can collaborate on the project with me. Note, some of the work is pulled from their source code, he is aware of this.
I invite others to join me in developing this price ticker, perhaps someone strong in Javascript. I am not an expert yet in this area, but I will continue to work on it and tweak the HTML/CSS.
Areas we are looking to finish up for price tracking:
Are we going to continue to use the thread/google docs to hold the bid/ask offers? If so, how would we pull these requests to display them on the ticker?
Let me know how this fits in with the rest of the developments, what we should focus on to create a program which will best serve mastercoin's users.
The repository is available here: https://github.com/travispatron/mastercoin-ticker
I have contacted BitcoinWisdom to gain some insight into how they have developed their Javascript framework, so I am hoping they can collaborate on the project with me. Note, some of the work is pulled from their source code, he is aware of this.
I invite others to join me in developing this price ticker, perhaps someone strong in Javascript. I am not an expert yet in this area, but I will continue to work on it and tweak the HTML/CSS.
Areas we are looking to finish up for price tracking:
- Linking bids & asks to market data charts
- Creating javascript framework so the program can properly communicate with changes in demand
- Making the chart look professional and informative
Are we going to continue to use the thread/google docs to hold the bid/ask offers? If so, how would we pull these requests to display them on the ticker?
Let me know how this fits in with the rest of the developments, what we should focus on to create a program which will best serve mastercoin's users.
http://www.wakanda.org/ would be a good tool to build with. It has A JavaScript framework.
October 26, 2013, 11:31:53 AM
Areas we are looking to finish up for price tracking:
- Linking bids & asks to market data charts
- Creating javascript framework so the program can properly communicate with changes in demand
- Making the chart look professional and informative
I suggest you contact these guys: https://www.tradingview.com/
This is how BTCUSD charts look like (html5, not java; you should play around with the charting features for a while): https://www.tradingview.com/e/?symbol=MTGOX:BTCUSD
These guys are also behind this: http://www.multicharts.com/ this trading and charting software should be the reference.
October 26, 2013, 09:39:13 AM
Trying to parsing from the Exodus address (and build a database).
The code below looks like a multi sig transaction. How can I get the public key ?
Sender
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 is the
Receipients
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
Are the address below the data?
1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3
13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR
The code below looks like a multi sig transaction. How can I get the public key ?
Sender
1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826 is the
Receipients
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb
Are the address below the data?
1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3
13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR
Code:
{[
{
"n": 0,
"value": 9950000,
"addr": "1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826",
"tx_index": 94812526,
"type": 0
},
{
"n": 1,
"value": 6000,
"addr": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P",
"tx_index": 94812526,
"type": 0
},
{
"n": 2,
"value": 6000,
"addr": "1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb",
"tx_index": 94812526,
"type": 0
},
{
"addr2": "1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3",
"n": 3,
"value": 12000,
"addr": "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
"tx_index": 94812526,
"type": 1
}
]}
{
"n": 0,
"value": 9950000,
"addr": "1MCHESTbJhJK27Ygqj4qKkx4Z4ZxhnP826",
"tx_index": 94812526,
"type": 0
},
{
"n": 1,
"value": 6000,
"addr": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P",
"tx_index": 94812526,
"type": 0
},
{
"n": 2,
"value": 6000,
"addr": "1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb",
"tx_index": 94812526,
"type": 0
},
{
"addr2": "1HiYAgHPd3F7Sr4nxpa8q8RyYPEzWinMQ3",
"n": 3,
"value": 12000,
"addr": "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
"tx_index": 94812526,
"type": 1
}
]}
October 26, 2013, 08:48:01 AM
Thanks Zathras,
I will check your library =)
I will check your library =)
Check (and fix) ECDSA validity:
Encode a simple send transaction using Class B (requires sufficient fees at from address):
Thanks!
P.S. Can any of you guys think of any further changes needed to the amendment? Feel free to criticize and suggest changes!
Code:
Dim valid As Boolean = False
Do While valid = False
Dim rbyte As String = getrandombyte()
encodedpubkey = encodedpubkey.Substring(0, 64) & rbyte
valid = validateecdsa(encodedpubkey)
Loop
Do While valid = False
Dim rbyte As String = getrandombyte()
encodedpubkey = encodedpubkey.Substring(0, 64) & rbyte
valid = validateecdsa(encodedpubkey)
Loop
Encode a simple send transaction using Class B (requires sufficient fees at from address):
Code:
Dim rawhex As String = mlib.encodetx(bitcoin_connection, from_address, to_address, currency, amount)
Thanks!
P.S. Can any of you guys think of any further changes needed to the amendment? Feel free to criticize and suggest changes!
October 26, 2013, 07:24:03 AM
I've been underway with the BTC/MSC price ticker. So far I've completed some of the HTML framework and the stylesheet.
The repository is available here: https://github.com/travispatron/mastercoin-ticker
I have contacted BitcoinWisdom to gain some insight into how they have developed their Javascript framework, so I am hoping they can collaborate on the project with me. Note, some of the work is pulled from their source code, he is aware of this.
I invite others to join me in developing this price ticker, perhaps someone strong in Javascript. I am not an expert yet in this area, but I will continue to work on it and tweak the HTML/CSS.
Areas we are looking to finish up for price tracking:
Are we going to continue to use the thread/google docs to hold the bid/ask offers? If so, how would we pull these requests to display them on the ticker?
Let me know how this fits in with the rest of the developments, what we should focus on to create a program which will best serve mastercoin's users.
The repository is available here: https://github.com/travispatron/mastercoin-ticker
I have contacted BitcoinWisdom to gain some insight into how they have developed their Javascript framework, so I am hoping they can collaborate on the project with me. Note, some of the work is pulled from their source code, he is aware of this.
I invite others to join me in developing this price ticker, perhaps someone strong in Javascript. I am not an expert yet in this area, but I will continue to work on it and tweak the HTML/CSS.
Areas we are looking to finish up for price tracking:
- Linking bids & asks to market data charts
- Creating javascript framework so the program can properly communicate with changes in demand
- Making the chart look professional and informative
Are we going to continue to use the thread/google docs to hold the bid/ask offers? If so, how would we pull these requests to display them on the ticker?
Let me know how this fits in with the rest of the developments, what we should focus on to create a program which will best serve mastercoin's users.
October 26, 2013, 05:26:09 AM
Hey guys,
I've moved my code from dev into the masterchest library
This includes:
Masterchest.info has had the new library deployed & the two Class A transactions from the other thread with ambiguous sequence numbers are now interpreted correctly and considered valid Of the four Class B transactions you guys posted about, masterchest.info sees these as:
I've broadcast a few of my own transactions (I just plugged the new library into my wallet and sent a couple of transactions from it) - yours seems to be spot on Tachikoma & Grazcoin I tried to test against yours but it's not showing any transactions and times out when I try to check a transaction - could you please let me know how your implementation sees these?
Bitoy, please feel free to use as you like You can just import the library (at my github) and use what you need. Some of the extra functions this time round:
Obfuscate a mastercoin packet:
Check (and fix) ECDSA validity:
Encode a simple send transaction using Class B (requires sufficient fees at from address):
Thanks!
P.S. Can any of you guys think of any further changes needed to the amendment? Feel free to criticize and suggest changes!
I've moved my code from dev into the masterchest library
This includes:
- Code adjustments to apply the transaction processing rules as defined in the amendment
- Support for decoding the new Class B obfuscated keys
- Support for encoding the new Class B obfuscated keys
- Support for ECDSA point validity checking
- Various bugfixes
Masterchest.info has had the new library deployed & the two Class A transactions from the other thread with ambiguous sequence numbers are now interpreted correctly and considered valid
Of the four Class B transactions you guys posted about, masterchest.info sees these as:Code:
95869c648953ee937d1956a62cbde051cedc26c8d33855d951930340e7c45fd0 invalid
7a02df33eddfb9dbcc7988f980630297089454f13a8bd059ada4b7842e2d1615 valid
a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95 valid
2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc valid
7a02df33eddfb9dbcc7988f980630297089454f13a8bd059ada4b7842e2d1615 valid
a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95 valid
2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc valid
I've broadcast a few of my own transactions (I just plugged the new library into my wallet and sent a couple of transactions from it) - yours seems to be spot on Tachikoma & Grazcoin I tried to test against yours but it's not showing any transactions and times out when I try to check a transaction - could you please let me know how your implementation sees these?
Code:
5885b1aa8938f234da483a5190084c3c425ab03363810e68b0214d358a8144c6 - should be invalid (no funds at source)
5fe5e0a2c7a4c9ae92708631b0559c32ebad33aa65d12d9d13b23869a1a68cbf - should be invalid (no funds at source)
cca8984303daf2304845b72cfe3b797b391792db7fad28f38cb3d8cb3296908c - should be valid
5fe5e0a2c7a4c9ae92708631b0559c32ebad33aa65d12d9d13b23869a1a68cbf - should be invalid (no funds at source)
cca8984303daf2304845b72cfe3b797b391792db7fad28f38cb3d8cb3296908c - should be valid
Bitoy, please feel free to use as you like
You can just import the library (at my github) and use what you need. Some of the extra functions this time round:Obfuscate a mastercoin packet:
Code:
Dim encodedpacket As String = mlib.encryptmastercoinpacket(fromaddress, seqence_number, 31_byte_clear_text_mastercoin_packet)
Check (and fix) ECDSA validity:
Code:
Dim valid As Boolean = False
Do While valid = False
Dim rbyte As String = getrandombyte()
encodedpubkey = encodedpubkey.Substring(0, 64) & rbyte
valid = validateecdsa(encodedpubkey)
Loop
Do While valid = False
Dim rbyte As String = getrandombyte()
encodedpubkey = encodedpubkey.Substring(0, 64) & rbyte
valid = validateecdsa(encodedpubkey)
Loop
Encode a simple send transaction using Class B (requires sufficient fees at from address):
Code:
Dim rawhex As String = mlib.encodetx(bitcoin_connection, from_address, to_address, currency, amount)
Thanks!
P.S. Can any of you guys think of any further changes needed to the amendment? Feel free to criticize and suggest changes!
October 26, 2013, 03:14:54 AM
Yeah looks good!
October 25, 2013, 04:31:06 PM
Prophetx wanted to use the graphic I modified from Tachikoma's original on the blog - I've advised it's a bit out of date and quickly thrown together a new one. Would you guys call this reflective of the amendments?
Thanks!
Class B multisig example:
Thanks!
Class B multisig example:
October 25, 2013, 03:56:59 PM
Did we discuss how to determine the receiving address when there is a change address present? Basically did we formalise that the outputs for Exodus and Receiving address should be the same for Class B transactions?
We'd discussed that Class B required the change output to go to the sender address.
This way if we have an output to the same address as the sender, we take that output out of the equation. So we're only ever dealing with three outputs - the multisig and two other outputs; one to exodus and one to the reference address - easy to identify.
We still have to consider the 'what if' though. So what if someone sends a Class B transaction and sends the change to a new address for example? Do we call it invalid or try to parse another way etc? I don't think that's a major concern as it'll only be our respective Mastercoin softwares that are building the raw transactions and thus we can always enforce the rule, but still worth considering.
If you guys think there are better ways though let's look at those
Quote
I would give a simpler instruction for tx constructing:
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.
I'm taking a different approach which I think should give the correct result regardless of the what type of key is being used for the spending public key. I'm looking at the inputs for this transaction and then getting the previous output and I generate that address. That way the key format does not matter anymore. That's my theory at least Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.
That's exactly how I work out the sending address also, I think going on the inputs is the only way we should trust to enumerate the 'from' address.
Grazcoin,
Did I have any luck trying to convince you of the merits of standardizing on a compressed public key as a signatory in the multisig?
Thanks!
October 25, 2013, 10:23:43 AM
Most of those no-change sends were me doing the giveaway thread. I was feeling a little paranoid and wasn't quite sure that I knew all the edge cases for change addresses, so I just used exact-change transactions to be safe.
October 25, 2013, 09:40:25 AM
Anybody in the market to buy some Test Mastercoins? Limited offer 1 MSC for just 1000 Satoshi's!
Edit: Since I am getting PM's, this is a joke. This transaction is actually a Mastercoin sell offer to sell 2 test coins for 1000 Satoshi's.
Edit: Since I am getting PM's, this is a joke. This transaction is actually a Mastercoin sell offer to sell 2 test coins for 1000 Satoshi's.
October 25, 2013, 06:38:55 AM
Hey Tachikoma,
Regarding our discussions over the last couple of days about making the output amounts the same a solid requirement (ie not just a convenience) in Class A transactions...
Would you mind double checking my sanity checks on this? There is a single fail; a transaction with 4 outputs all the same. We both already consider that transaction valid by the other rules (eg sequence numbers) so that's a non-issue.
My conclusion is that we can require all the outputs except change to be the same in a Class A transaction without affecting any transactions already done, which is good news
Raw data here https://masterchest.info/files/sameoutputs_duedill.txt
Also of interest may be that almost 40% of simple sends done to date didn't have a change output (that surprised the hell out of me to be honest!)
Regarding our discussions over the last couple of days about making the output amounts the same a solid requirement (ie not just a convenience) in Class A transactions...
• All outputs that contain Mastercoin data for Class A transaction should have the same output amount, but it doesn't matter how much this amount is.
I will make some time today to see if this change would affect any existing transactions but I highly doubt it.
I will make some time today to see if this change would affect any existing transactions but I highly doubt it.
Quote from: The-Amendment
• Has all output values equal & above the 'dust' threshold (currently 0.00005430 BTC)
Would you mind double checking my sanity checks on this? There is a single fail; a transaction with 4 outputs all the same. We both already consider that transaction valid by the other rules (eg sequence numbers) so that's a non-issue.
My conclusion is that we can require all the outputs except change to be the same in a Class A transaction without affecting any transactions already done, which is good news
Code:
Performing summary...
139 transactions PASS with [3 outputs exist with the same value and a 4th output exists with a different value (change)]
90 transactions PASS with [3 outputs exist with the same value and no change detected]
1 transactions FAIL with [more than 3 outputs exist with the same value]
18 transactions SKIP with [tranasction detected as deprecated multisig]
139 transactions PASS with [3 outputs exist with the same value and a 4th output exists with a different value (change)]
90 transactions PASS with [3 outputs exist with the same value and no change detected]
1 transactions FAIL with [more than 3 outputs exist with the same value]
18 transactions SKIP with [tranasction detected as deprecated multisig]
Raw data here https://masterchest.info/files/sameoutputs_duedill.txt
Also of interest may be that almost 40% of simple sends done to date didn't have a change output (that surprised the hell out of me to be honest!)
Awesome news; I'm glad you found some time to do this. Since it makes it much easier to move forward enforcing this rule and thus increasing the flexibility of our transaction parsing. I think that in one of the earliest communication on creating Mastercoin transactions J.R. told them to fund the exact amount to the Mastercoin address that was needed for the transaction. This could explain it.
Tachikoma:
It seems that in 2 of the multisig tx I have sent (this time with obfuscation using the sender address), you mis-parse the receiving address:
http://mastercoin-explorer.com/transactions/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
http://mastercoin-explorer.com/transactions/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
My parsing looks this way:
http://masterchain.info/Transaction.html?tx=a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95¤cy=MSC
http://masterchain.info/Transaction.html?tx=2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc¤cy=MSC
Can you please check your parsing?
Just a note:
On the first one the public key for the change address in the BIP11 is uncompressed.
On the second one the public key for the change address in the BIP11 is compressed.
It seems that in 2 of the multisig tx I have sent (this time with obfuscation using the sender address), you mis-parse the receiving address:
http://mastercoin-explorer.com/transactions/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
http://mastercoin-explorer.com/transactions/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
My parsing looks this way:
http://masterchain.info/Transaction.html?tx=a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95¤cy=MSC
http://masterchain.info/Transaction.html?tx=2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc¤cy=MSC
Can you please check your parsing?
Just a note:
On the first one the public key for the change address in the BIP11 is uncompressed.
On the second one the public key for the change address in the BIP11 is compressed.
Thanks for spotting that, the code I was using to define the receiving address was not updated for the new situation. I'm rolling out a fix now which I think should fix the problem.
Did we discuss how to determine the receiving address when there is a change address present? Basically did we formalise that the outputs for Exodus and Receiving address should be the same for Class B transactions?
Quote
I would give a simpler instruction for tx constructing:
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.
I'm taking a different approach which I think should give the correct result regardless of the what type of key is being used for the spending public key. I'm looking at the inputs for this transaction and then getting the previous output and I generate that address. That way the key format does not matter anymore. That's my theory at least
October 25, 2013, 04:52:13 AM
Is there any reason you can think of to use an uncompressed public key? Since it's only a couple of lines of code to compress a key that happens to be uncompressed in the wallet I currently have the amendment using all compressed keys to keep things simple. Happy to change this if there are good reasons to use uncompressed keys for the sender in the multisig output, but if it's just a case of being uncompressed originally, it makes sense to just compress it before using. It's storing exactly the same data (the uncompressed key can be derived from the compressed key by just using the X co-ordinates to calculate the Y) so in my view there is no value in taking up the extra 32 bytes in the blockchain.
If you compare those two "mastercoin identical" transactions on blockchain.info:
https://blockchain.info/tx/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
you see that on the first (uncompressed pubkey), you see the correct change address (182osb...) and on the second (compressed pubkey), it is the "dual" bitcoin address (a compressed pubkey generates always a different bitcoin address).
In the "both pubkeys compressed" option - it is not clear that the BIP11 funds go back to the change address. It will be a little harder to show on a wallet that more funds are available. We can overcome this issue by considering always the two dual addresses as one, but to simplify things - I recommend using uncompressed pubkey for the change address and compressed pubkey for the data. That's exactly the first transaction.
Yeah, you'll get a different address if you hash the compressed vs uncompressed public key (expected since your hash inputs are now different). I'm not sure how that's a factor though to be honest - change goes to the sender in a regular non-multisig output so the public key is not involved at all with change (& a wallet balance would only reduce by the fee amounts).
The only place we need the public key is as a signatory in a multisig output & only then so it can be redeemed (which can be done with the private key regardless of compressed/uncompressed public key).
I would give a simpler instruction for tx constructing:
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.
If it was compressed - use compressed format in the BIP11 as well.
If it was uncompressed - use uncompressed format in the BIP11 as well.
If you wanted to validate that way just hash the compressed key & check equals sending address, if not decompress it & then hash the uncompressed key and check equals sending address. Not expensive work.
In my view still no need to add 32 bytes extra weight to some transactions when (IMO) it's not necessary, we should aim to be as light as possible
October 25, 2013, 04:40:15 AM
Is there any reason you can think of to use an uncompressed public key? Since it's only a couple of lines of code to compress a key that happens to be uncompressed in the wallet I currently have the amendment using all compressed keys to keep things simple. Happy to change this if there are good reasons to use uncompressed keys for the sender in the multisig output, but if it's just a case of being uncompressed originally, it makes sense to just compress it before using. It's storing exactly the same data (the uncompressed key can be derived from the compressed key by just using the X co-ordinates to calculate the Y) so in my view there is no value in taking up the extra 32 bytes in the blockchain.
If you compare those two "mastercoin identical" transactions on blockchain.info:
https://blockchain.info/tx/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
you see that on the first (uncompressed pubkey), you see the correct change address (182osb...) and on the second (compressed pubkey), it is the "dual" bitcoin address (a compressed pubkey generates always a different bitcoin address).
In the "both pubkeys compressed" option - it is not clear that the BIP11 funds go back to the change address. It will be a little harder to show on a wallet that more funds are available. We can overcome this issue by considering always the two dual addresses as one, but to simplify things - I recommend using uncompressed pubkey for the change address and compressed pubkey for the data. That's exactly the first transaction.
Yeah, you'll get a different address if you hash the compressed vs uncompressed public key (expected since your hash inputs are now different). I'm not sure how that's a factor though to be honest - change goes to the sender in a regular non-multisig output so the public key is not involved at all with change (& a wallet balance would only reduce by the fee amounts).
The only place we need the public key is as a signatory in a multisig output & only then so it can be redeemed (which can be done with the private key regardless of compressed/uncompressed public key).
I would give a simpler instruction for tx constructing:
Make sure that the address in the BIP11 is the same as the sender's address.
This means that you should use the same format of public key as used at the sender.
If it was compressed - use compressed format in the BIP11 as well.
If it was uncompressed - use uncompressed format in the BIP11 as well.
October 25, 2013, 04:25:23 AM
Is there any reason you can think of to use an uncompressed public key? Since it's only a couple of lines of code to compress a key that happens to be uncompressed in the wallet I currently have the amendment using all compressed keys to keep things simple. Happy to change this if there are good reasons to use uncompressed keys for the sender in the multisig output, but if it's just a case of being uncompressed originally, it makes sense to just compress it before using. It's storing exactly the same data (the uncompressed key can be derived from the compressed key by just using the X co-ordinates to calculate the Y) so in my view there is no value in taking up the extra 32 bytes in the blockchain.
If you compare those two "mastercoin identical" transactions on blockchain.info:
https://blockchain.info/tx/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
you see that on the first (uncompressed pubkey), you see the correct change address (182osb...) and on the second (compressed pubkey), it is the "dual" bitcoin address (a compressed pubkey generates always a different bitcoin address).
In the "both pubkeys compressed" option - it is not clear that the BIP11 funds go back to the change address. It will be a little harder to show on a wallet that more funds are available. We can overcome this issue by considering always the two dual addresses as one, but to simplify things - I recommend using uncompressed pubkey for the change address and compressed pubkey for the data. That's exactly the first transaction.
Yeah, you'll get a different address if you hash the compressed vs uncompressed public key (expected since your hash inputs are now different). I'm not sure how that's a factor though to be honest - change goes to the sender in a regular non-multisig output so the public key is not involved at all with change (& a wallet balance would only reduce by the fee amounts).
The only place we need the public key is as a signatory in a multisig output & only then so it can be redeemed (which can be done with the private key regardless of compressed/uncompressed public key).
October 25, 2013, 04:08:07 AM
Is there any reason you can think of to use an uncompressed public key? Since it's only a couple of lines of code to compress a key that happens to be uncompressed in the wallet I currently have the amendment using all compressed keys to keep things simple. Happy to change this if there are good reasons to use uncompressed keys for the sender in the multisig output, but if it's just a case of being uncompressed originally, it makes sense to just compress it before using. It's storing exactly the same data (the uncompressed key can be derived from the compressed key by just using the X co-ordinates to calculate the Y) so in my view there is no value in taking up the extra 32 bytes in the blockchain.
If you compare those two "mastercoin identical" transactions on blockchain.info:
https://blockchain.info/tx/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
you see that on the first (uncompressed pubkey), you see the correct change address (182osb...) and on the second (compressed pubkey), it is the "dual" bitcoin address (a compressed pubkey generates always a different bitcoin address).
In the "both pubkeys compressed" option - it is not clear that the BIP11 funds go back to the change address. It will be a little harder to show on a wallet that more funds are available. We can overcome this issue by considering always the two dual addresses as one, but to simplify things - I recommend using uncompressed pubkey for the change address and compressed pubkey for the data. That's exactly the first transaction.
October 25, 2013, 02:53:57 AM
Good point. I hadn't noticed that limitation.
I think the most commonly used messages will fit in 80 bytes. The ones that don't (mainly the ones that allow for a bit of ASCII in them) should also be the ones that don't get used very often.
I think the most commonly used messages will fit in 80 bytes. The ones that don't (mainly the ones that allow for a bit of ASCII in them) should also be the ones that don't get used very often.
Actually that's a very good point, going through the spec you have defined a total of 11 different transaction types, the largest of which requires a payload of 57 bytes. 'Class C' could thus handle all (currently defined) types in a single packet & we'd only need to attach multi-sig when we need extra space.
October 25, 2013, 02:25:03 AM
Hey Grazcoin,
Currently the amendment states for a Class B transaction:
I don't see anything wrong with these transactions (other than ideally the first one would have a compressed pubkey for the sender), they're both identical Mastercoin transactions to 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX with a cleartext Mastercoin packet of 0100000000000000010000000000CC02900000000000000000000000000000.
I'll be updating the Masterchest codebase with my dev implementation on all this stuff over the weekend so you should be able to test your transactions there too
Thanks!
Just a note:
On the first one the public key for the change address in the BIP11 is uncompressed.
On the second one the public key for the change address in the BIP11 is compressed.
On the first one the public key for the change address in the BIP11 is uncompressed.
On the second one the public key for the change address in the BIP11 is compressed.
Currently the amendment states for a Class B transaction:
It seems that in 2 of the multisig tx I have sent (this time with obfuscation using the sender address), you mis-parse the receiving address:
http://mastercoin-explorer.com/transactions/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
http://mastercoin-explorer.com/transactions/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
My parsing looks this way:
http://masterchain.info/Transaction.html?tx=a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95¤cy=MSC
http://masterchain.info/Transaction.html?tx=2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc¤cy=MSC
Can you please check your parsing?
http://mastercoin-explorer.com/transactions/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95
http://mastercoin-explorer.com/transactions/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc
My parsing looks this way:
http://masterchain.info/Transaction.html?tx=a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95¤cy=MSC
http://masterchain.info/Transaction.html?tx=2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bc¤cy=MSC
Can you please check your parsing?
I don't see anything wrong with these transactions (other than ideally the first one would have a compressed pubkey for the sender), they're both identical Mastercoin transactions to 17RVTF3vJzsuaGh7a94DFkg4msJ7FcBYgX with a cleartext Mastercoin packet of 0100000000000000010000000000CC02900000000000000000000000000000.
I'll be updating the Masterchest codebase with my dev implementation on all this stuff over the weekend so you should be able to test your transactions there too
Thanks!
Jump to: