Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Jeremy Rubin <jeremy.l.rubin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

> 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.

[-- Attachment #2: Type: text/html, Size: 4183 bytes --]