bitcoinj produces canonical S values.
I think the best approach might be to roll these all into a transaction v2 format, so people have a more exciting feature to announce than a series of small "vegetable eating" pieces of work. Then if you want to use any other features of v2, you have to do all of it at once.
Topic: What's the latest on transaction mutability? (Read 732 times)
If the refund is constructed using P2SH you can get the other side to sign just the hash, and they won't be able to recognize the payment into the escrow— being both unable to see their own pubkey in it (due to p2sh) and having not seen the refund they signed. Thats one of the workarounds...
Full mutability fixes are very slow going. MTGOX is still producing transactions with non-canonical R,S. Bitcoin-QT GIT now uses the smaller of the two possible S values in signatures, but I'm not aware of any other signers that do. I think its not unlikely that we're going to see hardware wallets deploy which fail to do this. I'm now wondering if we shouldn't start 'fixing' these transactions on relay and just letting them cope with their txids changing out from under them rather than failing to forward completely.
As for other fix progress: https://github.com/bitcoin/bitcoin/pull/3025
Full mutability fixes are very slow going. MTGOX is still producing transactions with non-canonical R,S. Bitcoin-QT GIT now uses the smaller of the two possible S values in signatures, but I'm not aware of any other signers that do. I think its not unlikely that we're going to see hardware wallets deploy which fail to do this. I'm now wondering if we shouldn't start 'fixing' these transactions on relay and just letting them cope with their txids changing out from under them rather than failing to forward completely.
As for other fix progress: https://github.com/bitcoin/bitcoin/pull/3025
There's a lot of really interesting protocols being developed with advanced Bitcoin scripting lately. CoinSwap, trust-free guessing games, the list goes on. But in a lot of these cases, the protocols are hampered by the "transaction mutability" issue - essentially, the issue that a signed transaction can have its txid changed by any of the participants by redoing their signature, thereby invalidating any pre-built transactions that were supposed to follow on from it (e.g. time-locked cancellation transactions).
The thing is, I've seen various statements attached to interesting scripting proposals that go something like "care must be taken until mutability is fixed", as though (1) we have a plan to "fix" mutability, and (2) until then there's a way to prevent such attacks against schemes like CoinSwap if one is "careful". Searches reveal only fragmented and piecemeal discussion of the former, and almost nothing on the latter.
So I suppose my questions are, what's the plan to fix mutability, and what can we do in the meantime?
The thing is, I've seen various statements attached to interesting scripting proposals that go something like "care must be taken until mutability is fixed", as though (1) we have a plan to "fix" mutability, and (2) until then there's a way to prevent such attacks against schemes like CoinSwap if one is "careful". Searches reveal only fragmented and piecemeal discussion of the former, and almost nothing on the latter.
So I suppose my questions are, what's the plan to fix mutability, and what can we do in the meantime?
Jump to: