> There's basically an infinite number of ways to add opcodes to scriptSig, so we can't use the same trick as above of signing every possible backout transaction.
Further to this point, following up more feedback from arubi: non-push opcodes are not allowed in the scriptSig, but OP_NOP is allowed, as I understand it (please correct me if I'm wrong); if that's right, the issue is specifically related to the NOP opcodes, and extra data can be disallowed with OP_DEPTH (or does cleanstack cover that? only for standard?).
(Also logging any thoughts on this here: https://github.com/AdamISZ/CoinSwapCS/issues/25 ).
Topic: Salvaging refund protocols from malleability attacks with P2SH (Read 6030 times)
Waxwing, arubi and I were discussing this for coinswap. We think we came up with another method of malleability that could cause serious problems.
In my above post I only thought about highS/lowS malleability, but there is another way involving adding OP_NOP opcodes to the scriptSig. See here (click the symbol on the top right, the first input has OP_NOP added)
I think this is non-standard but valid on the bitcoin mainnet. Which means a miner could be either Alice or Carol in the coinswap protocol and then mine a malleated paying-in TX0 to hold the other party's money to ransom. Also a miner could do this to random transactions as a way of attacking the network.
There's basically an infinite number of ways to add opcodes to scriptSig, so we can't use the same trick as above of signing every possible backout transaction.
If there's no way to fix this then we can't safely do coinswap. One thing we need to check if whether this thing is really non-standard but valid.
In my above post I only thought about highS/lowS malleability, but there is another way involving adding OP_NOP opcodes to the scriptSig. See here (click the symbol on the top right, the first input has OP_NOP added)
I think this is non-standard but valid on the bitcoin mainnet. Which means a miner could be either Alice or Carol in the coinswap protocol and then mine a malleated paying-in TX0 to hold the other party's money to ransom. Also a miner could do this to random transactions as a way of attacking the network.
There's basically an infinite number of ways to add opcodes to scriptSig, so we can't use the same trick as above of signing every possible backout transaction.
If there's no way to fix this then we can't safely do coinswap. One thing we need to check if whether this thing is really non-standard but valid.
I've been thinking about this a lot recently.
Since the last post, highS signatures have been made non-standard so they won't propagate on the p2p network. However this malleability can still be done by a miner and recently this happened.
Another way to deal with s-malleability is for Alice to mutate the transactions herself and require Bob to sign two transaction hashes. One for each of the highS and lowS versions. Then if the transaction gets mutated that way Alice can use the other signature to get her coins back.
Only problem is, for N inputs there are 2^N ways of mutating the transaction, so transactions with many inputs require a lot more data to be transferred between Alice and Bob.
(My earlier comments on this thread 18 month ago sound a bit ignorant hah, I get it now)
Since the last post, highS signatures have been made non-standard so they won't propagate on the p2p network. However this malleability can still be done by a miner and recently this happened.
Another way to deal with s-malleability is for Alice to mutate the transactions herself and require Bob to sign two transaction hashes. One for each of the highS and lowS versions. Then if the transaction gets mutated that way Alice can use the other signature to get her coins back.
Only problem is, for N inputs there are 2^N ways of mutating the transaction, so transactions with many inputs require a lot more data to be transferred between Alice and Bob.
(My earlier comments on this thread 18 month ago sound a bit ignorant hah, I get it now)
September 08, 2015, 08:12:03 AM
From what I can tell, bip65 is a better way to solve the problem in OP
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Noninteractive_timelocked_refunds
It can be implemented with a softfork and also allows many other applications as well as timelocked refunds.
Of course this would be a great thing.https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Noninteractive_timelocked_refunds
It can be implemented with a softfork and also allows many other applications as well as timelocked refunds.
Still dont you feel that allowing ANYBODY to just mess with your txid a bit wrong? The real world analogy would be that ANYBODY at ANYTIME could theoretically just change the check # for a check that you send to someone.
Alice: "I sent you check #1234, didnt you get it?"
Bob: "No, but I did get check #7364 for the same amount from you. Are you sure you know what you are doing?"
Alice: "Of course, it was the malleability gremlin that just changed the checknumber. Dont worry, bitcoin is 100% secure"
James
Well... yeah.
We'll just have to build our software to never rely on the txid unless its already been mined.
Alice and Bob shouldnt talk about txid but instead addresses or whatever comes after addresses in bip70.
September 08, 2015, 01:25:57 AM
From what I can tell, bip65 is a better way to solve the problem in OP
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Noninteractive_timelocked_refunds
It can be implemented with a softfork and also allows many other applications as well as timelocked refunds.
Of course this would be a great thing.https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Noninteractive_timelocked_refunds
It can be implemented with a softfork and also allows many other applications as well as timelocked refunds.
Still dont you feel that allowing ANYBODY to just mess with your txid a bit wrong? The real world analogy would be that ANYBODY at ANYTIME could theoretically just change the check # for a check that you send to someone.
Alice: "I sent you check #1234, didnt you get it?"
Bob: "No, but I did get check #7364 for the same amount from you. Are you sure you know what you are doing?"
Alice: "Of course, it was the malleability gremlin that just changed the checknumber. Dont worry, bitcoin is 100% secure"
James
September 07, 2015, 11:15:17 AM
From what I can tell, bip65 is a better way to solve the problem in OP
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Noninteractive_timelocked_refunds
It can be implemented with a softfork and also allows many other applications as well as timelocked refunds.
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Noninteractive_timelocked_refunds
It can be implemented with a softfork and also allows many other applications as well as timelocked refunds.
September 07, 2015, 09:12:15 AM
Ignoring compatibility issues, the following would fix this once and for all, wouldnt it?
This is a hard fork, since old clients would consider those signatures invalid. With a hard fork, there are lots of solutions to the problem.
September 07, 2015, 08:55:58 AM
Ignoring compatibility issues, the following would fix this once and for all, wouldnt it?
This is a hard fork, since old clients would consider those signatures invalid. With a hard fork, there are lots of solutions to the problem.
September 07, 2015, 04:17:06 AM
Ignoring compatibility issues, the following would fix this once and for all, wouldnt it?
**********
#define SIGHASH_TXID 0x40
change https://en.bitcoin.it/wiki/OP_CHECKSIG:
Final signature check
An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type and if SIGHASH_TXID is set followed by the txid. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash. The secp256k1 elliptic curve is used for the verification with the given public key.
**********
also the txid cant include the sig. Not sure why the txid calc isnt using the same data as the signature calc.
James
**********
#define SIGHASH_TXID 0x40
change https://en.bitcoin.it/wiki/OP_CHECKSIG:
Final signature check
An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type and if SIGHASH_TXID is set followed by the txid. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash. The secp256k1 elliptic curve is used for the verification with the given public key.
**********
also the txid cant include the sig. Not sure why the txid calc isnt using the same data as the signature calc.
James
My question a year ago has not been answered. As someone may attack the network by randomly mutating txs, just like what we had last year, no txid should be considered as final before it is written in the blockchain.
What to answer? That was the limitation here-- pointed out in the post; someone might choose to take that risk-- e.g. if their alternative is to just trust their counterparty instead such a scheme could only be an improvement. But isn't that precisely what this proposal is intended to deal with?
so he would have to mutate every possible transaction in order to get a mutant mined instead. This would be much harder/more costly (at least if P2SH were widely used).
This proposal assume that Bob would not take a spray-and-pray strategy. As someone is now randomly mutating transactions on the network, the proposal won't work
My question a year ago has not been answered. As someone may attack the network by randomly mutating txs, just like what we had last year, no txid should be considered as final before it is written in the blockchain.
We change the protocol so that the escrow payment is to P2SH(2 of 2 Alice2, Bob2) and Alice2 and Bob2 are new keys that they've never used elsewhere and Bob does not know Alice2.
Alice computes the refund but instead of telling bob the refund transactions, she tells Bob only the hash value she wants signed with Bob2.
Is there a library that supports this?
Any Bitcoin library that gives you sufficiently low-level access to transaction signing will support this. For instance my own python-bitcoinlib lets you, as you can see in the P2SH signing example.
We change the protocol so that the escrow payment is to P2SH(2 of 2 Alice2, Bob2) and Alice2 and Bob2 are new keys that they've never used elsewhere and Bob does not know Alice2.
Alice computes the refund but instead of telling bob the refund transactions, she tells Bob only the hash value she wants signed with Bob2.
Is there a library that supports this?
Let's say I wanted to implement this payment protocol, do I have to "manually" construct the hash value from the unsigned transaction, and later "manually" putting together the transaction that includes Bob2's signature?
And one more question: Does BitcoinJ follow the protocol described above, or is BitcoinJ still prone to transaction malleability?
Any help is greatly appreciated, I'm working on a payment channel implementation for my bachelor thesis
February 11, 2014, 11:33:41 AM
But isn't that precisely what this proposal is intended to deal with?
so he would have to mutate every possible transaction in order to get a mutant mined instead. This would be much harder/more costly (at least if P2SH were widely used).
This proposal assume that Bob would not take a spray-and-pray strategy. As someone is now randomly mutating transactions on the network, the proposal won't work
February 11, 2014, 11:22:53 AM
But isn't that precisely what this proposal is intended to deal with?
February 11, 2014, 11:07:07 AM
With the ongoing malleability attack, this proposal no longer works. Any hope to safe it (except by fixing malleability)?
Why does it no longer work?
Someone is randomly mutating unconfirmed transactions. So the txid of all unconfirmed transactions are not reliable
February 11, 2014, 11:00:53 AM
With the ongoing malleability attack, this proposal no longer works. Any hope to safe it (except by fixing malleability)?
Why does it no longer work?
February 11, 2014, 10:55:39 AM
With the ongoing malleability attack, this proposal no longer works. Any hope to save it (except by fixing malleability)?
February 11, 2014, 10:43:44 AM
Alice computes the refund but instead of telling bob the refund transactions, she tells Bob only the hash value she wants signed with Bob2.
Doesn't that mean that Bob is blindly signing something? Wouldn't that be incredibly risky? EDIT: never mind, Bob is signing with a brand new key.
December 14, 2013, 09:38:05 AM
... and this is assuming that it doesn't turn out that there are any more ways to mutate DSA signatures (e.g. by jointly modifying R and S). Adam Back was very concerned that there were.
I didnt so far find a way to do it with ECDSA, but that is not a proof. Also there exist other crypto schemes that are self-reblindable (without knowing the private key).
But it seemed to be rather than relying on this additional and perhaps not designed for property of signatures non-malleability (of the anti-malleability-canonicalized serialization) that maybe longer term bitcoin could include the public key in the hashed data rather than the signature. By definition the signed data must also be unique as txins are spent in full.
We were also talking at the physical meetup about possibility to fix the malleability before forwarding and Greg had mentioned this as a work-around used by blockchain.info as they were unable to modify their wallet due to apple's regressive policies.
Adam
Jump to: