Ok, addressed these (and a few other things) in https://github.com/bitcoin/bips/pull/117: * Better names for the rules. * Clarify interaction of BIP62 with P2SH. * Clarify that known hashtypes are required, despite not being part of DER. * Use v2 transactions instead of v3 transactions. * Apply the optional rules only to strict v2, and not higher or lower.
On Tue, Nov 4, 2014 at 12:07 PM, Peter Todd <p...@petertodd.org> wrote: > On Tue, Nov 04, 2014 at 12:00:43PM -0800, Pieter Wuille wrote: >> On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik <jgar...@bitpay.com> wrote: >> > On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd <p...@petertodd.org> wrote: >> >> On another topic, I'm skeptical of the choice of nVersion==3 - we'll >> >> likely end up doing more block.nVersion increases in the future, and >> >> there's no reason to think they'll have anything to do with >> >> transactions. No sense creating a rule that'll be so quickly broken. >> > >> > Moderately agreed. >> > >> > Earlier in BIP 62 lifetime, I had commented on ambiguity that arose >> > from bumping tx version simply because we were bumping block version. >> > The ambiguity was corrected, but IMO remains symptomatic of potential >> > problems and confusion down the road. >> > >> > Though I ACK'd the change, my general preference remains to disconnect >> > TX and block version. >> >> I prefer to see consensus rules as one set of rules (especially >> because they only really apply to blocks - the part for lone >> transactions is just policy), and thus have a single numbering. Still, >> I have no strong opinion about it and have now heard 3 'moderately >> against' comments. I'm fine with using nVersion==2 for transactions. > > Keep in mind that we may even have a circumstance where we need to > introduce *two* different new tx version numbers in a single soft-fork, > say because we find an exploit that has two different fixes, each of > which breaks something. > > I don't think we have any certainty how new features will be added in > the future - just look at how we only recently realised new opcodes > won't be associated with tx version number bumps - so I'm loath to setup > expectations. > > Besides, transactions can certainly be verified for correctness in a > stand-alone fashion outside a block; CHECKLOCKTIMEVERIFY was > specifically designed so that verifying scripts containing it could be > done in a self-contained manner only referencing the transaction the > script was within. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000036655c955dd94ba7f9856814f3cb87f003e311566921807 ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
