Bitcoin Forum
September 27, 2018, 10:12:17 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Banning scriptSig malleability will not interfere with later extensions  (Read 1534 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
1538086337
Hero Member
*
Offline Offline

Posts: 1538086337

View Profile Personal Message (Offline)

Ignore
1538086337
Reply with quote  #2

1538086337
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1538086337
Hero Member
*
Offline Offline

Posts: 1538086337

View Profile Personal Message (Offline)

Ignore
1538086337
Reply with quote  #2

1538086337
Report to moderator
1538086337
Hero Member
*
Offline Offline

Posts: 1538086337

View Profile Personal Message (Offline)

Ignore
1538086337
Reply with quote  #2

1538086337
Report to moderator
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
September 27, 2013, 04:53:21 AM
 #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: 2520
Merit: 1514



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.

Bitcoin will not be compromised
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!