Bitcoin Forum
May 24, 2024, 07:09:18 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Salvaging refund protocols from malleability attacks with P2SH  (Read 6030 times)
belcher
Sr. Member
****
Offline Offline

Activity: 261
Merit: 521


View Profile
September 07, 2015, 03:15:17 PM
 #21

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.

1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9
JoinMarket - CoinJoin that people will actually use.
PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
September 08, 2015, 05:25:57 AM
 #22

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.

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
belcher
Sr. Member
****
Offline Offline

Activity: 261
Merit: 521


View Profile
September 08, 2015, 12:12:03 PM
 #23

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.

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.

1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9
JoinMarket - CoinJoin that people will actually use.
PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
belcher
Sr. Member
****
Offline Offline

Activity: 261
Merit: 521


View Profile
March 11, 2017, 05:24:35 PM
 #24

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)

1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9
JoinMarket - CoinJoin that people will actually use.
PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
belcher
Sr. Member
****
Offline Offline

Activity: 261
Merit: 521


View Profile
June 25, 2017, 07:29:37 PM
 #25

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.

1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9
JoinMarket - CoinJoin that people will actually use.
PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
waxwing
Sr. Member
****
Offline Offline

Activity: 469
Merit: 253


View Profile
June 25, 2017, 08:29:40 PM
 #26

> 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 ).

PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!