Bitcoin Forum
March 28, 2024, 04:10:54 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Banning scriptSig malleability will not interfere with later extensions  (Read 1578 times)
jl2012 (OP)
Legendary
*
Offline Offline

Activity: 1792
Merit: 1087


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
1711642254
Hero Member
*
Offline Offline

Posts: 1711642254

View Profile Personal Message (Offline)

Ignore
1711642254
Reply with quote  #2

1711642254
Report to moderator
1711642254
Hero Member
*
Offline Offline

Posts: 1711642254

View Profile Personal Message (Offline)

Ignore
1711642254
Reply with quote  #2

1711642254
Report to moderator
1711642254
Hero Member
*
Offline Offline

Posts: 1711642254

View Profile Personal Message (Offline)

Ignore
1711642254
Reply with quote  #2

1711642254
Report to moderator
I HATE TABLES I HATE TABLES I HA(╯°□°)╯︵ ┻━┻ TABLES I HATE TABLES I HATE TABLES
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711642254
Hero Member
*
Offline Offline

Posts: 1711642254

View Profile Personal Message (Offline)

Ignore
1711642254
Reply with quote  #2

1711642254
Report to moderator
1711642254
Hero Member
*
Offline Offline

Posts: 1711642254

View Profile Personal Message (Offline)

Ignore
1711642254
Reply with quote  #2

1711642254
Report to moderator
1711642254
Hero Member
*
Offline Offline

Posts: 1711642254

View Profile Personal Message (Offline)

Ignore
1711642254
Reply with quote  #2

1711642254
Report to moderator
jl2012 (OP)
Legendary
*
Offline Offline

Activity: 1792
Merit: 1087


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
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
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!