|
|
|
|
|
|
|
"If you don't want people to know you're a scumbag then don't be a scumbag." -- margaritahuyan
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
Tachikoma
|
 |
October 24, 2013, 06:56:01 PM
Last edit: October 24, 2013, 07:31:45 PM by Tachikoma |
|
I've added up an intermediate tool. Updating my wallet software all the time is pretty time intensive so I made something that is easier up-to-dateable until we finalise everything. You can now create a simple send transaction online and sign and broadcast it via Bitcoin-qt.To do this do the following: - Get the public key for your Mastercoin address. You can do this by using the validateaddress <youraddress> function in the Bitcoin-qt console.
- Navigate to this page on mastercoin-explorer. and fill in your details.
- Copy the hex string you get.
- Make sure the transaction is what you would want it to be by using decoderawtransaction <HASH FROM SITE> from the Bitcoin-qt console. Never trust that the software did everything 100%. The site might have been hacked, or I have become evil. Don't skip this step.
- If you are happy with the result sign it with signrawtransaction <HASH FROM SITE> followed by sendrawtransaction <HASH FROM SITE>
You require an unspend output big enough to fund the whole transaction. The pre of this method is that you don't have to trust a third party tool/application with your private keys. I would really appreciate it if somebody could test this functionality, it will be hardcode to test until somebody can verify it works  |
|
|
|
|
Tachikoma
|
|
October 24, 2013, 06:56:28 PM |
|
Awesome, good to know |
|
|
|
dacoinminster (OP)
Legendary
 Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
October 24, 2013, 07:26:23 PM |
|
It looks like I accidentally deleted or overwrote my post about OP return. Here's what I think I wrote: Gavin has had us on his mind lately - at the top of his recent blog post about 0.9 bitcoin software, he talks about explicitly supporting projects like ours with OP_RETURN: https://bitcoinfoundation.org/blog/?p=290It's looking like we'll have a "class C" transaction type soon. OP_RETURN works very well for our current model of sending transactions from a PC and viewing balances on websites which have the entire transaction history. Once 0.9 is out and miners are widely supporting OP_RETURN, I think we should start using it. |
|
|
|
|
Tachikoma
|
|
October 24, 2013, 07:31:14 PM |
|
It looks like I accidentally deleted or overwrote my post about OP return. Here's what I think I wrote: Gavin has had us on his mind lately - at the top of his recent blog post about 0.9 bitcoin software, he talks about explicitly supporting projects like ours with OP_RETURN: https://bitcoinfoundation.org/blog/?p=290It's looking like we'll have a "class C" transaction type soon. OP_RETURN works very well for our current model of sending transactions from a PC and viewing balances on websites which have the entire transaction history. Once 0.9 is out and miners are widely supporting OP_RETURN, I think we should start using it. Seconded. I will need to look into OP_RETURN though, the fact that he mentioned 80 bytes though sounds promising. |
|
|
|
|
zathras
|
|
October 24, 2013, 11:17:31 PM
Last edit: October 24, 2013, 11:42:00 PM by zathras |
|
It looks like I accidentally deleted or overwrote my post about OP return. Here's what I think I wrote: Gavin has had us on his mind lately - at the top of his recent blog post about 0.9 bitcoin software, he talks about explicitly supporting projects like ours with OP_RETURN: https://bitcoinfoundation.org/blog/?p=290It's looking like we'll have a "class C" transaction type soon. OP_RETURN works very well for our current model of sending transactions from a PC and viewing balances on websites which have the entire transaction history. Once 0.9 is out and miners are widely supporting OP_RETURN, I think we should start using it. Seconded. I will need to look into OP_RETURN though, the fact that he mentioned 80 bytes though sounds promising. Yep, my vote in for investigating OP_RETURN too. It'll be another couple of months until OP_RETURN is widely supported by the miners, but once we publish some transactions with OP_RETURN and gain confidence the majority of miners will include them (and thus we don't have long lead periods for block inclusion) then we introduce a Class C as you note. Looking through Gavin's notes he picked 80 bytes to provide for a 64 byte hash of whatever is being stored (eg SHA512) and some extra metadata. I don't think we need metadata so we could use the whole 80 bytes for Mastercoin transaction data. I just wanted to point something out though as I think you guys may have overlooked it (sorry if I'm reading your comments wrong & making a bad assumption); the pull that Gavin merged for OP_RETURN is per transaction not per output. This means each Class C (OP_RETURN) transaction could only have one 80 byte packet and thus a total transaction space of 80 bytes, where as Class B (multisig) as defined in the amendment provides for a total transaction space of 7,650 bytes. That's a distinction we need to keep in mind - things like 'simple send' would easily fit into a Class C transaction, but some of the larger functions (eg smart property) may require more than 80 bytes transaction space and thus need to stay with a Class B transaction. Thanks! |
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
October 24, 2013, 11:46:55 PM |
|
It looks like I accidentally deleted or overwrote my post about OP return. Here's what I think I wrote: Gavin has had us on his mind lately - at the top of his recent blog post about 0.9 bitcoin software, he talks about explicitly supporting projects like ours with OP_RETURN: https://bitcoinfoundation.org/blog/?p=290It's looking like we'll have a "class C" transaction type soon. OP_RETURN works very well for our current model of sending transactions from a PC and viewing balances on websites which have the entire transaction history. Once 0.9 is out and miners are widely supporting OP_RETURN, I think we should start using it. Seconded. I will need to look into OP_RETURN though, the fact that he mentioned 80 bytes though sounds promising. Yep, my vote in for investigating OP_RETURN too. It'll be another couple of months until OP_RETURN is widely supported by the miners, but once we publish some transactions with OP_RETURN and gain confidence the majority of miners will include them (and thus we don't have long lead periods for block inclusion) then we introduce a Class C as you note. Looking through Gavin's notes he picked 80 bytes to provide for a 64 byte hash of whatever is being stored (eg SHA512) and some extra metadata. I don't think we need metadata so we could use the whole 80 bytes for Mastercoin transaction data. I just wanted to point something out though as I think you guys may have overlooked it (sorry if I'm reading your comments wrong & making a bad assumption); the pull that Gavin merged for OP_RETURN is per transaction not per output. This means each Class C (OP_RETURN) transaction could only have one 80 byte packet and thus a total transaction space of 80 bytes, where as Class B (multisig) as defined in the amendment provides for a total transaction space of 7,650 bytes. That's a distinction we need to keep in mind - things like 'simple send' would easily fit into a Class C transaction, but some of the larger functions (eg smart property) may require more than 80 bytes transaction space and thus need to stay with a Class B transaction. Thanks! 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. |
|
|
|
|
zathras
|
|
October 25, 2013, 04:10:02 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... • 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.
• 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 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]
Raw data here https://masterchest.info/files/sameoutputs_duedill.txtAlso 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!) Thanks! |
|
|
|
|
|
|
zathras
|
|
October 25, 2013, 07:25:03 AM |
|
Hey Grazcoin, 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.
Currently the amendment states for a Class B transaction: Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address
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. 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! |
|
|
|
|
zathras
|
|
October 25, 2013, 07: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.
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. |
|
|
|
|
grazcoin
|
|
October 25, 2013, 09: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/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bcyou 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. |
|
|
|
|
zathras
|
|
October 25, 2013, 09: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/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bcyou 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). |
|
|
|
|
grazcoin
|
|
October 25, 2013, 09: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/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bcyou 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. |
|
|
|
|
zathras
|
|
October 25, 2013, 09: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/a67a07f54e80cd77b45e128d6404c6979c84eb39c3026fa707c20c9dbcca1e95https://blockchain.info/tx/2b488371c4488ee42e35868df29de97023be9624111dfad79a52584cef3469bcyou 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 |
|
|
|
|
Tachikoma
|
|
October 25, 2013, 11: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... • 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.
• 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 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]
Raw data here https://masterchest.info/files/sameoutputs_duedill.txtAlso 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. 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? 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 |
|
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
October 25, 2013, 03:23:43 PM |
|
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. |
|
|
|
|
zathras
|
|
October 25, 2013, 08: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 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 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! |
|
|
|
|
zathras
|
|
October 25, 2013, 09:31:06 PM
Last edit: October 25, 2013, 10:34:10 PM by zathras |
|
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: |
|
|
|
|
