Several updates to BIP62

sipa commented at 7:42 am on November 5, 2014: member

Instead of repeating some problem names, give the rules meaningful ones 47b050ac98

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

sipa cross-referenced this on Nov 5, 2014 from issue BIP62: Instead of repeating some problem names, give the rules meaningful names by sipa

sipa cross-referenced this on Nov 5, 2014 from issue Clarify the interaction between BIP62 rule 6 (clean stack) and P2SH by sipa

sipa force-pushed on Nov 5, 2014

Clarify that correct hashtypes are not required. 72475226e7

Use v2 transactions instead of v3, and apply the optional rules only to exactly v2. 3b9d5df9f1

typo 7eaf5714c3

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.

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.

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

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.

sipa force-pushed on Nov 8, 2014

sipa force-pushed on Nov 9, 2014

Strict DER is also required for non-evaluated CHECKMULTISIG inputs ea0795b106

Add signature reordering to list of malleability sources 8d7acb2d5e

Make rule 2 non-mandatory 439f1fffb5

At 95%, the new rules apply to old blocks e25e2a179e

Problem 10 is also under control of the script creator 492d090c1c

sipa force-pushed on Nov 10, 2014

sipa cross-referenced this on Nov 10, 2014 from issue Make BIP62 rules 1 and 5 apply to non-evaluated signatures by sipa

laanwj commented at 7:09 am on December 16, 2014: member

Needs rebase

laanwj commented at 2:24 pm on March 11, 2015: member

Stil needs rebase (or close, if no longer relevant).

luke-jr added the label Proposed BIP modification on Oct 23, 2015

laanwj commented at 10:42 am on December 8, 2015: member

Closing this - IIRC BIP62 is retracted

laanwj closed this on Dec 8, 2015

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

Several updates to BIP62 #117