> You'd be confiscating your own funds by making an absurd spending condition. > By this argument, ALL softforks would have to be ruled out.
The argument is that transactions which can be relayed and in the mempool and then confirmed should not ever be restricted. This is so that old node's mempools don't produce invalid blocks after an upgrade. This is what a good chunk of policy is for, and we (being core) do bounce these txns to make clear what might be upgraded. Changing the detail you mentioned represents a tweak that could make old nodes mine invalid blocks. That's all I'm ruling out. > > In preparing it I just used what was available in Core now, surely the > last > > year you could have gotten the appropriate patches done? > > They were done, reviewed, and deployed in time for Taproot. You personally > > played a part in sabotaging efforts to get it merged into Core, and > violating > the community's trust in it by instead merging your BIP9 ST without > consensus. Don't play dumb. You have nobody to blame but yourself. > Even if I accept full responsibility for BIP9 ST without consensus, you still had the last year to convince the rest of the maintainers to review and merge your activation code, which you did not do. Don't confuse consensus-seeking with preference. My preference was to leave versionbits entirely. Nor am I blame seeking. I'm simply asking why, if this is _the_ most important thing for Bitcoin (as I've heard some BIP8 LOT=true people remark), did you not spend the last year improving your advocacy. And I'm suggesting that you redouble those efforts by, e.g., opening a new PR for Core with logic you find acceptable and continuing to drive the debate forward. None of these things happen without advocacy.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
