Bitcoin Forum
December 04, 2020, 12:08:27 AM *
News: Bitcointalk Community Awards
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Banning scriptSig malleability will not interfere with later extensions  (Read 1555 times)
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
August 10, 2013, 03:30:15 PM
 #1

In bitcoin wiki (https://en.bitcoin.it/wiki/Transaction_Malleability), it states that
Quote
Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.

We can make this restriction only applicable to version 1 tx. Therefore, future extension (e.g. script 2.0) can use a new version code and won't be affected.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1607040507
Hero Member
*
Offline Offline

Posts: 1607040507

View Profile Personal Message (Offline)

Ignore
1607040507
Reply with quote  #2

1607040507
Report to moderator
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
September 27, 2013, 04:53:21 AM
Last edit: September 27, 2013, 05:37:31 AM by jl2012
 #2

I think we should ban tx malleability with the following approach:

1. Make anything except P2KH and multi-sig P2SH non-standard

2. Change the transaction version to 2.

3. Define the most significant bit of transaction version as "malleability bit"

4. If malleability bit = 0 AND version = 2, the following new rules are applied (with soft-fork). For other combinations, existing rules apply (ie.  malleability is allowed.)

5. Use "low S" as malleability breaker in signature (e.g. https://github.com/bitcoin/bitcoin/commit/e0e14e43d9586409e42919f6cb955540134cda2a )

6. For P2KH, the scriptSig must and must only push 2 values to the stake, without any other actions

7. For P2SH, the scriptSig must and must only push n values to the stake (in addition to the serialized script), for a n-or-m multisig.

8. Malleability is allowed for any non-standard tx even the malleability bit = 0.

Therefore, the user can choose whether they want to allow malleability. Any future protocol upgrade will use a new transaction version so the anti-malleability rules will not apply.

(p.s. If I have learnt bitcoin earlier, I would have proposed a similar approach to the P2SH migration. The P2SH has created a permanent exceptional case in the interpretation of OP_HASH160, and that's now irreversible without a hardfork. I think a better way is to define a "P2SH bit" in the transaction version and let people to choose Sorry this won't work without adding further complexity. btw this is off-topic.)

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3262
Merit: 4598



View Profile
September 27, 2013, 05:50:20 AM
 #3

Anti-malleability is _far_ more complicated than just the S value. We've been slowly working on this in Bitcoin-QT on and off for a year now. There are at five types of malleability that I know of (± allowances for differences in how you might count)... and at the moment I am not entirely sure that it isn't possible to jointly change R and S to mutate DSA in additional ways, though I don't know how to yet.

In any case, using the transaction version to signal a soft forking protocol restriction is almost certainly what should be done.
Pages: [1]
  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!