Pages:
Author

Topic: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread) - page 60. (Read 129207 times)

sr. member
Activity: 266
Merit: 250
Awesome stuff Zathras.

Can anybody think of a reason to prefer the public key to the receiving address or visa-versa?

Actually thinking about it public key would be preferred over the receiving address just purely for length purposes (ideally we need >=31 bytes) - the compressed public key will always be 33 bytes compared to the address which could technically be as low as 27 - though <31 is extremely rare I believe we'd still have to cover that scenario in the code for completeness with looping or something, so I'd say save ourselves the trouble and just use the public key which we know has enough bytes.

I'll amend the draft accordingly Smiley
hero member
Activity: 938
Merit: 1000
Awesome stuff Zathras.

Can anybody think of a reason to prefer the public key to the receiving address or visa-versa?
sr. member
Activity: 284
Merit: 250
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.

+1 for xor with redeemable public key (the first key in the multisig).

sr. member
Activity: 266
Merit: 250
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.

That's what I've been thinking for the obfuscation step, combined with byte rotation I believe we'll be in pretty good shape - it's not perfect but guys feel free to have a read of a draft appendix to the spec I've been putting together to button up tight how we're storing data.  JR can obviously choose to use as is or just select bits (or none at all).

I'd still like to clean it up some more and flesh out a few of the details but feedback welcome, feel free to tear it apart if needed Smiley
hero member
Activity: 938
Merit: 1000
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.
sr. member
Activity: 449
Merit: 250
For the distributed exchange. Smart Property

1. Transaction type = 50 for creating new property (32-bit unsigned integer, 4 bytes)
2. Property Type = 1 for indivisible shares (2 is divisible currency) (32-bit unsigned integer, 4 bytes)
3. Property Name = “ master miner corp.  \0” (21 bytes)
4. Number Properties = 1,000,000 indivisible shares (64-bit unsigned integer, 8 bytes)

To create the property, send data above to the exodus address. 
(I think we should add if it is denominated in MSC or BTC)

This will become  property of the Issuer (Sender)

Seller IPO (Initial Public Offering)
Allow anyone to post Max highest bid price for a share.  Bidder must have sufficient BTC balance
At the end of IPO period.
Arrange Bids Highest to lowest

Ex. Total Shares 1,000,000
UserA 500,000 @ 9.0
UserB 400,000 @ 8.5
UserC 300,000 @ 7.0  <- Cut off
UserD 300,000 @ 7.0

Final Share Distribution (System post to exodus,Seller Address,Bidder Address?)
UserA 500,000 @ 7.0
UserB 400,000 @ 7.0
UserC 100,000 @ 7.0

What protocol should we use to post shares?


legendary
Activity: 1260
Merit: 1031
Rational Exuberance
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.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance

Regarding the output amounts & change, we've already removed the requirement for outputs to be the same amount in an earlier effort (ref).

The ECDSA issue affects the first key same as any other.  The last byte rotation method (ref) gives us all available sequence numbers at the cost of the last byte.  In total I think Tachikoma & I have tested a combined million plus keys with this method successfully.  I believe my suggestion solves the ECDSA point validity issue for good.

As to obfuscation - that's how we avoid obvious ascii (eg "000000") - the method has not yet been decided upon, I'm just advocating for it's use right now - if we agree on the need for it, we can focus on the how.

Excuse spelling/grammar in this post, I'm currently sitting in a keynote typing this on a tablet Smiley


I see from your first referenced post that you require the change address to be the same as the sending address. Since we are reusing addresses all over the place (including the Exodus Address) I don't see any problem with doing that. We'll never get a sequence number collision that way. Any objections on this?

One way to avoid looking like ASCII without a lot of work would be to flip (XOR) the most-significant bit of every byte. This would be essentially zero cost to us, and would make all ASCII characters non-ASCII (and many non-ASCII characters would consequently become ASCII). How does that sound? We could also just XOR everything (flip every bit we store), if that seems simpler.

I realize that the spec is overdue for a revision - this stuff will go in there for sure Smiley
sr. member
Activity: 266
Merit: 250
Replying to some development-related stuff from the other thread . . .


Paid or not Peter this is extremely helpful, thank you (though it will take multiple readings for me to even remotely try to understand it all!).  

JR, without wanting to be badgering I feel this is the most critical issue for mastercoin right now.  How we store data in the blockchain is fundamental and should be locked away as early as possible (and ideally written into the spec).  As you made that the number one goal of the first coding contest I'm guessing you feel the same Smiley  Tachikoma's work is great but perhaps we could refine it somewhat - in development we're spitting out invalid ECDSA points in multi-sigs some of the time and as Jeff has raised above, pubkey checking is on the way regardless of mastercoin.

As I've mentioned before I view the miners as our critical issue and if some of the major pools are doing things like looking for obvious compressable/text data as Peter notes, perhaps some further investigation into steganography (an apt analogy I think) would be in order - obfuscating the data we're storing in the pubkey (IMO) seems quite achievable and spotting our padding ("000000000" etc) isn't going to be hard.

Thoughts?

I agree that Peter's comments are extremely helpful. I think  you guys are on the right track (massaging Tachikoma's multisig method output until it is valid). I can offer some general guidelines here:

  • We don't want to to anything that can be easily blocked without specifically targeting MasterCoin. For instance anything which could be screened out by a validity check, or a "too much ASCII" check
  • We can't really worry about blacklists. If something like that happens, we have a few options. The Exodus Address can always be changed. We could even get rid of it altogether, although that would make finding MasterCoins transactions MUCH more difficult (we'd have to watch the transactions from any address which holds MasterCoins).
  • We also have the "nuclear option" of returning to the original spec (spending to fake addresses), but I don't think that will be needed.
  • All clients should be generous with fees to bitcoin miners by default. We want to create a situation where an anti-mastercoin stance by a miner should be very expensive for them!

Found the problem, the official spec is still not updated. This makes it a lot harder for new developers (and developers who forget stuff...)

J.R. Could you please update the spec with all the new data packet order stuff and the new validation rules? (broken sequence, ambiguous sequence etc.)

Rolling out fix in the next few minutes.

Edit:

Transaction should be fixed.

I somehow missed part of the sequence discussion.

Quote
If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!

Is this really necessary? We have no control over the sequence number for a change address, is it fair to disregard a transaction based on random luck? I would like to propose to do a sanity check before invalidating a transaction based on sequence. You could try to decode the address and see if the transaction_type and the other options based on that transaction_type make sense. If one of the addresses with the same sequence for instance does that, but an other does not you know which one is the data address and which one the target. If that also fails it seems safe to flag it as invalid but I think we should try harder before falling back to invalid.

Sorry for the out-of-date spec. Fixing this (and adding some new stuff) is at the top of my list.

Note that the sequence number of the change address only needs to be considered when the change amount is exactly the same as all the other outputs. Invalidating a MasterCoin transaction because the change amount just happens to be 0.00006 BTC AND a bad sequence number should be exceedingly rare.


Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

Spending multisig bitcoins is painful right now, and I'd rather avoid that extra complexity until it isn't painful. Let's keep that extra output to the destination address for now. I think that supporting two different encoding methods will end up increasing the testing burden dramatically, and I'd rather not do that yet.

Let me see if I understand the current proposal:

We are (if I understand it correctly) taking Tachikoma's proposed multisig, then for each key after the first one we change the sequence number until we get a valid ECDSA point? Can anybody explain why this problem only affects keys after the first one (sorry if I missed this somewhere)?

Current valid transactions (not using multisig) have the last data packet sequence number before the target address be n-1. Theoretically, earlier data packets would have had n-2, n-3, all the way back to the first data packet (although simple send never has more than one data packet). Perhaps for multi-sig we should change this paradigm. It might be easier to start at the sequence number of the destination/target address, then increment up from there. If a given sequence number does not pass our "valid ECDSA" test, we just go on to the next one. Is that what you guys are doing already?

It sounds like this method significantly reduces how much data we can potentially store per transaction. Can anybody give a guess as to what a reasonable upper bound for how much data we should try to store using this method in a single transaction?

Regarding the output amounts & change, we've already removed the requirement for outputs to be the same amount in an earlier effort (ref).

The ECDSA issue affects the first key same as any other.  The last byte rotation method (ref) gives us all available sequence numbers at the cost of the last byte.  In total I think Tachikoma & I have tested a combined million plus keys with this method successfully.  I believe my suggestion solves the ECDSA point validity issue for good.

As to obfuscation - that's how we avoid obvious ascii (eg "000000") - the method has not yet been decided upon, I'm just advocating for it's use right now - if we agree on the need for it, we can focus on the how.

Excuse spelling/grammar in this post, I'm currently sitting in a keynote typing this on a tablet Smiley
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

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.


We have to be a little careful here - if we include change in the multisig then unless we immediately redeem it, users will see their bitcoin balance drop by changeamount which could cause confusion and fear.  With the current method the bitcoin balance never drops as we return change in the original transaction.

As I've made a lot of posts on the topic, to summarize my proposed spec changes in simple form:

* We use only compressed keys (sounds like we have consensus on this now, thanks Grazcoin)
* We use only ECDSA valid points (eg via my suggestion to rotate the last byte)
* We obfuscate the data so it appears like a random key, but do not invest too much effort in encryption as censorship essentially boils down in its simplest form to miners blocking transactions with an output to Exodus

Points 1 & 2 are easy (eg I know Tachikoma and I both already have code that does this and it shouldn't be too much work for grazcoin).  Point 3 may take a little more effort depending on just how far we go to make the key look 'real'.

JR, care to weigh in?

Thanks! Smiley

I agree with this approach, but I'm curious how we would obfuscate (point 3). That might be something to do later . . .

Edit: Does byte rotation mean we can still use all sequence numbers? It sounds like we'd be sacrificing the last byte of every key, which seems like a good tradeoff to be able to store data for every sequence number.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
Replying to some development-related stuff from the other thread . . .


Paid or not Peter this is extremely helpful, thank you (though it will take multiple readings for me to even remotely try to understand it all!).  

JR, without wanting to be badgering I feel this is the most critical issue for mastercoin right now.  How we store data in the blockchain is fundamental and should be locked away as early as possible (and ideally written into the spec).  As you made that the number one goal of the first coding contest I'm guessing you feel the same Smiley  Tachikoma's work is great but perhaps we could refine it somewhat - in development we're spitting out invalid ECDSA points in multi-sigs some of the time and as Jeff has raised above, pubkey checking is on the way regardless of mastercoin.

As I've mentioned before I view the miners as our critical issue and if some of the major pools are doing things like looking for obvious compressable/text data as Peter notes, perhaps some further investigation into steganography (an apt analogy I think) would be in order - obfuscating the data we're storing in the pubkey (IMO) seems quite achievable and spotting our padding ("000000000" etc) isn't going to be hard.

Thoughts?

I agree that Peter's comments are extremely helpful. I think  you guys are on the right track (massaging Tachikoma's multisig method output until it is valid). I can offer some general guidelines here:

  • We don't want to to anything that can be easily blocked without specifically targeting MasterCoin. For instance anything which could be screened out by a validity check, or a "too much ASCII" check
  • We can't really worry about blacklists. If something like that happens, we have a few options. The Exodus Address can always be changed. We could even get rid of it altogether, although that would make finding MasterCoins transactions MUCH more difficult (we'd have to watch the transactions from any address which holds MasterCoins).
  • We also have the "nuclear option" of returning to the original spec (spending to fake addresses), but I don't think that will be needed.
  • All clients should be generous with fees to bitcoin miners by default. We want to create a situation where an anti-mastercoin stance by a miner should be very expensive for them!

Found the problem, the official spec is still not updated. This makes it a lot harder for new developers (and developers who forget stuff...)

J.R. Could you please update the spec with all the new data packet order stuff and the new validation rules? (broken sequence, ambiguous sequence etc.)

Rolling out fix in the next few minutes.

Edit:

Transaction should be fixed.

I somehow missed part of the sequence discussion.

Quote
If there is a broken sequence (i.e. 3,4,8), then the odd-man-out is the change address (8 in this example)
If there is an ambiguous sequence (i.e. 3,4,4), then the transaction is invalid!
If there is a perfect sequence (i.e. 3,4,5), then the transaction is invalid!

Is this really necessary? We have no control over the sequence number for a change address, is it fair to disregard a transaction based on random luck? I would like to propose to do a sanity check before invalidating a transaction based on sequence. You could try to decode the address and see if the transaction_type and the other options based on that transaction_type make sense. If one of the addresses with the same sequence for instance does that, but an other does not you know which one is the data address and which one the target. If that also fails it seems safe to flag it as invalid but I think we should try harder before falling back to invalid.

Sorry for the out-of-date spec. Fixing this (and adding some new stuff) is at the top of my list.

Note that the sequence number of the change address only needs to be considered when the change amount is exactly the same as all the other outputs. Invalidating a MasterCoin transaction because the change amount just happens to be 0.00006 BTC AND a bad sequence number should be exceedingly rare.


Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

Spending multisig bitcoins is painful right now, and I'd rather avoid that extra complexity until it isn't painful. Let's keep that extra output to the destination address for now. I think that supporting two different encoding methods will end up increasing the testing burden dramatically, and I'd rather not do that yet.

Let me see if I understand the current proposal:

We are (if I understand it correctly) taking Tachikoma's proposed multisig, then for each key after the first one we change the sequence number until we get a valid ECDSA point? Can anybody explain why this problem only affects keys after the first one (sorry if I missed this somewhere)?

Current valid transactions (not using multisig) have the last data packet sequence number before the target address be n-1. Theoretically, earlier data packets would have had n-2, n-3, all the way back to the first data packet (although simple send never has more than one data packet). Perhaps for multi-sig we should change this paradigm. It might be easier to start at the sequence number of the destination/target address, then increment up from there. If a given sequence number does not pass our "valid ECDSA" test, we just go on to the next one. Is that what you guys are doing already?

It sounds like this method significantly reduces how much data we can potentially store per transaction. Can anybody give a guess as to what a reasonable upper bound for how much data we should try to store using this method in a single transaction?
sr. member
Activity: 266
Merit: 250
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.

FWIW I agree to a point - I think your multsig is the right way for us to do it (at least until other more suitable opcodes become standard).  With that said I think we need not to rewrite encoding, but to refine it so we keep ECDSA valid points and don't have obvious ascii data in the pubkey.

Sorry if I'm sounding like a broken record, I just want to make sure we build the mastercoin house on a solid foundation Smiley

Thanks!
sr. member
Activity: 266
Merit: 250
Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

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.


We have to be a little careful here - if we include change in the multisig then unless we immediately redeem it, users will see their bitcoin balance drop by changeamount which could cause confusion and fear.  With the current method the bitcoin balance never drops as we return change in the original transaction.

As I've made a lot of posts on the topic, to summarize my proposed spec changes in simple form:

* We use only compressed keys (sounds like we have consensus on this now, thanks Grazcoin)
* We use only ECDSA valid points (eg via my suggestion to rotate the last byte)
* We obfuscate the data so it appears like a random key, but do not invest too much effort in encryption as censorship essentially boils down in its simplest form to miners blocking transactions with an output to Exodus

Points 1 & 2 are easy (eg I know Tachikoma and I both already have code that does this and it shouldn't be too much work for grazcoin).  Point 3 may take a little more effort depending on just how far we go to make the key look 'real'.

JR, care to weigh in?

Thanks! Smiley
hero member
Activity: 938
Merit: 1000
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.
sr. member
Activity: 284
Merit: 250
We're using compressed keys so we only have to worry about the X co-ordinates and can thus store data - that's kind of the point.

Thanks. I have already agreed to go for the compressed pubkeys:

I see that the brute force for getting a valid point is indeed shorter/simpler with compressed pubkey.

And http://masterchain.info reflects that.

sr. member
Activity: 284
Merit: 250
Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}

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.

sr. member
Activity: 284
Merit: 250
I'm currently not implementation sequence checking in that regard, I hope to convince J.R. it's not the best solution. If it becomes part of the spec I will implement it as well. But as I said in the other topic I don't really agree with it.

It is a good idea to avoid sending such a tx in the first place, but once such a tx got sent, there is no clear way to differ which output is which, and a good solution is to consider the tx as invalid.

sr. member
Activity: 266
Merit: 250
I've simulated 200.000 simple send public keys to make sure brute-forcing is viable, the highest sequence I needed was 19.

Here is the distribution over a 20.000 sample set. Where k is amount of sequence alterations needed and v the amount of keys.

Code:
{0=>10005, 2=>2511, 4=>649, 1=>5032, 3=>1208, 7=>64, 5=>309, 8=>37, 6=>136, 9=>23, 10=>13, 11=>9, 12=>3, 13=>1}

Thanks Tachikoma, this also reflects my testing (I ran a much larger set after posting).  Given Peter's feedback also I think it's very unlikely we're not going to be able to churn a public key into a valid ECDSA point with my proposed byte rotation technique.

As per my previous posts, I propose we adopt this as the method for making our keys ECDSA valid.

The question then becomes one of what we put before the last byte (ie do we encrypt/obfuscate), and how much effort to we go to make it look like random data.

If we already run brute force iterations to make the pubkey valid, we could consider doing the same for the non-compressed pubkeys (MIP1) and have 2 outputs instead of 4, plus extra place for future required data. I didn't check how much more iteration that would take, but it would add much less contamination to the blockchain.


We're using compressed keys so we only have to worry about the X co-ordinates and can thus store data - that's kind of the point.  If we had to make a valid ECDSA key from an uncompressed key, let's take example mastercoin X co-ordinates of 0100000014000000020000000005f5e10000000000000f424006000000000000.  The y co-ordinates must be 4B808A82AA5574B899D629F4EC7D77B044D75230FD13C7530F2E6CA5E03D95C8 - we can't change these and still remain ECDSA valid so there is no data we can embed here, and if we can't embed data in the Y co-ordindates, what's the value in using them?  This is why I've personally never viewed uncompressed keys as viable - but hey, I'm certainly not the authority on these matters so happy to be corrected Smiley


Is this really necessary? We have no control over the sequence number for a change address, is it fair to disregard a transaction based on random luck? I would like to propose to do a sanity check before invalidating a transaction based on sequence. You could try to decode the address and see if the transaction_type and the other options based on that transaction_type make sense. If one of the addresses with the same sequence for instance does that, but an other does not you know which one is the data address and which one the target. If that also fails it seems safe to flag it as invalid but I think we should try harder before falling back to invalid.

It's not really about removing ambiguity about which address is the data address, the sequence numbers and the requirement that they not be all in continuous sequence are for ensuring we always pick the right reference (destination) address.  If we have ambiguous sequence numbers then sure we can decode each address to look for the data, but how do we know we're sending the mastercoins to the right recipient and not to the change address?  Note in simple sends change doesn't need to = sending address.  Example based on change and reference having the same sequence number.

Edit for clarity.

hero member
Activity: 938
Merit: 1000
Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:

It's not hard for us to do, but for somebody who needs a GUI to make payments it will be. Until we have a user friendly way to do it I rather not support it yet. But let's see what J.R. has to say about the topic :}
sr. member
Activity: 284
Merit: 250
Multisig outputs are currently hard to spend, the reference client has no Gui support for it. It will need to be build into a Mastercoin wallet to make it easier. I think we better wait until there are some stable-ish wallets out before doing this.

Simple sends transactions would have plenty of space in the output for a target address, other messages however might not have enough space. Perhaps we can support both? If there is room in the multisig use that as target address, if not use an other output.

I have showed already in https://github.com/grazcoin/mastercoin-tools/blob/master/NOTES how to spend multisig using the sx, and my wallet will support (eventually) also multisig as input, so:
I prefer that we support both - extra change address (like your current implementation) as well as change inside the multisig.

I am also for supporting both extra target address (like your current implementation) as well as embedded target address whenever possible.

dacoinminster: do we get an OK here?

Pages:
Jump to: