Several updates to BIP62 #117

pull sipa wants to merge 10 commits into bitcoin:master from sipa:only3 changing 1 files +20 −17
  1. sipa commented at 7:42 am on November 5, 2014: member
  2. Instead of repeating some problem names, give the rules meaningful ones 47b050ac98
  3. BIP62 rule 6 and P2SH
    Clarify that BIP62 rule 6 (clean stack) only applies after potential P2SH redeemscript evaluation.
    Applying it before the redeemscript evaluation means that every P2SH script will fail it,
    as P2SH by definition uses an unclean stack (to specify the redeemscript inputs).
    bb863dc6d8
  4. sipa cross-referenced this on Nov 5, 2014 from issue BIP62: Instead of repeating some problem names, give the rules meaningful names by sipa
  5. sipa cross-referenced this on Nov 5, 2014 from issue Clarify the interaction between BIP62 rule 6 (clean stack) and P2SH by sipa
  6. sipa force-pushed on Nov 5, 2014
  7. sipa force-pushed on Nov 5, 2014
  8. Clarify that correct hashtypes are not required. 72475226e7
  9. Use v2 transactions instead of v3, and apply the optional rules only to exactly v2. 3b9d5df9f1
  10. typo 7eaf5714c3
  11. in bip-0062.mediawiki: in d9d569180b outdated
    59+To introduce these new rules in the network, we add both v3 blocks and v2 transactions.
    60 The same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of the past 1000 blocks are v3, a new consensus rule is activated:
    61-* All transactions in v3 blocks are required to follow rules #1-#2.
    62-* v3 (and higher) transactions in v3 blocks are required to follow rules #3-#7 as well.
    63+* All transactions in v3 blocks are required to follow rules #1 and #2.
    64+* v2 transactions in v3 blocks are required to follow rules #3-#7 as well. Transactions with version 1 or a version higher than 2 do not have this requirement, even when in a v3 block.
    


    luke-jr commented at 11:40 am on November 7, 2014:
    Seems to me the permanent rules should be #1 and #3. It’s conceivable we may at some point want executable scriptSig content…

    sipa commented at 4:48 pm on November 8, 2014:
    Not requiring #2: If it’s controversial, we should drop the requirement, but I really no reason. Requiring #3: no. There may be existing P2SH scripts (unknown to the senders) which do a non-compliant push (for example for the multisig counts).

    petertodd commented at 5:58 am on November 9, 2014:
    @luke-jr I’ve got a use-case for executable scriptSig content to be able to sign how much fees a tx spends, among many other cases.

    petertodd commented at 6:09 am on November 9, 2014:
    And yeah, I think only allowing pushdata ops in P2SH scriptSigs was a mistake.

    sipa commented at 12:17 pm on November 9, 2014:
    Ok, removed rule 2 being mandatory.
  12. in bip-0062.mediawiki: in d9d569180b outdated
    76 * R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required.
    77 * S-length: 1-byte length descriptor of the S value that follows.
    78 * S: arbitrary-length big-endian encoded S value. The same rules apply as for R.
    79-* sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).
    80+
    81+The DER signature must be followed by a 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).
    


    luke-jr commented at 11:44 am on November 7, 2014:
    This limitation might be better restricted to v2-only.

    sipa commented at 4:49 pm on November 8, 2014:
    Fixed. I removed it entirely, as it’s not necessary for malleability protection.
  13. in bip-0062.mediawiki: in d9d569180b outdated
    62-* v3 (and higher) transactions in v3 blocks are required to follow rules #3-#7 as well.
    63+* All transactions in v3 blocks are required to follow rules #1 and #2.
    64+* v2 transactions in v3 blocks are required to follow rules #3-#7 as well. Transactions with version 1 or a version higher than 2 do not have this requirement, even when in a v3 block.
    65 
    66-When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 (and v2) transactions remain valid forever.
    67+When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 transactions remain valid forever.
    


    luke-jr commented at 11:46 am on November 7, 2014:
    Is there a benefit to saying “v2 blocks become invalid entirely” vs “the new rules apply to v2 blocks”? I’m thinking that this could gradually turn past-block-versions into an extra nonce…

    sipa commented at 4:50 pm on November 8, 2014:
    Agreed, maybe this needs some more discussion as it diverges further from how BIP34 worked.

    petertodd commented at 6:01 am on November 9, 2014:

    Making v2 blocks invalid immediately is problematic as non-upgraded miners will end up creating false confirmations; this isn’t a security issue as v2 blocks containing invalid v2 transactions are invalid.

    I’d strongly prefer we don’t set a precident on this; it’s also coercive re: forcing people to upgrade.


    sipa commented at 12:13 pm on November 9, 2014:
    @petertodd does that mean you agree with @luke-jr’s suggestion (make the new consensus rules apply to v2 blocks as well, once 95% threshold is reached)?

    petertodd commented at 9:08 am on November 10, 2014:
    @sipa If you use @luke-jr’s suggestion, then it’s highly likely that v2-producing miners will end up creating invalid blocks given the existing rules, particularly the rule to apply strict DER encoding to even non-evaluated CHECKMULTISIG signatures. (that code isn’t even written yet!)

    sipa commented at 9:12 am on November 10, 2014:
    @petertodd it’s inevitable to have some forking… the alternative means almost by definition causing 5% of the hashrate to start producing invalid blocks just by them being non-v3.

    petertodd commented at 9:13 am on November 10, 2014:

    Sure, point is, that negates my objection as the intended result isn’t achieved anyway. So in that case we might as well just reject < v3 blocks. SPV clients should then implement the v2 -> v3 majority rules and also reject < v3 blocks after the switchover.

    edited: stupid markdown


    sipa commented at 9:18 am on November 10, 2014:
    Actually, I’m not convinced. There is no actual release currently that allows any P2SH (afaik), and in every currently-standard script checksig failure results in script failure. The only place where the strict DER encoding for non-evaluated signatures matters is in case CHECKSIG failure does not result in script failure.

    petertodd commented at 9:22 am on November 10, 2014:
    @sipa Hmm, actually that’s a good point; I think it meets my objection to my own objection. (is there a term for that? maybe a nice beautiful German word…)
  14. sipa commented at 4:51 pm on November 8, 2014: member
    Removed the hashtype requirement (as it’s not required for malleability protection, and may be useful otherwise), and added a clarification that even non-evaluated CHECKMULTISIG signatures need to be strict DER (even though the implementation of the opposite is easier, the semantics become more complex to explain). Thanks to @petertodd for pointing that out.
  15. sipa force-pushed on Nov 8, 2014
  16. sipa force-pushed on Nov 9, 2014
  17. Strict DER is also required for non-evaluated CHECKMULTISIG inputs ea0795b106
  18. Add signature reordering to list of malleability sources 8d7acb2d5e
  19. Make rule 2 non-mandatory 439f1fffb5
  20. At 95%, the new rules apply to old blocks e25e2a179e
  21. Problem 10 is also under control of the script creator 492d090c1c
  22. sipa force-pushed on Nov 10, 2014
  23. sipa cross-referenced this on Nov 10, 2014 from issue Make BIP62 rules 1 and 5 apply to non-evaluated signatures by sipa
  24. laanwj commented at 7:09 am on December 16, 2014: member
    Needs rebase
  25. laanwj commented at 2:24 pm on March 11, 2015: member
    Stil needs rebase (or close, if no longer relevant).
  26. luke-jr added the label Proposed BIP modification on Oct 23, 2015
  27. laanwj commented at 10:42 am on December 8, 2015: member
    Closing this - IIRC BIP62 is retracted
  28. laanwj closed this on Dec 8, 2015

  29. luke-jr referenced this in commit bf815005ec on Jun 6, 2017

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 03:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me