No, it's not the same. This approach is not guaranteed to activate. On
flag day, it'd check for (say) 20% miner support, and activate if so. If
>80% of miners oppose, it'd fail. LOT=true (and declining percentage) will activate unconditionally.
Also, the day before lock-in, this would still have 95% as the limit,
not a linear interpolation between 95% and the lock-in limit.
This checks: if miner support > 95% support it (ever) or miner support >
X% (on flag day), activate
DP checks: if miner support > lerp(95%, 0%) (ever), activate
LOT=true checks: on flag day, activate unconditionally
(Erik: I forgot to hit reply all on my last e-mail, that's why you're
seeing this twice)
On 2021-03-02 06:11, Erik Aronesty wrote:
This is the declining percentage of signaling activation.
It has all the benefits of both.
Eventually it becomes a LOT=true, so any argument for LOT=true holds
And all of the arguments for LOT=false are satisfied by the cool down
period.
On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev
<[email protected]> wrote:
How about a compromise?
With LOT=false, taproot will be activated if at least 95% of the
miners
vote yes.
With LOT=true, taproot will be activated if at least 0% of the
miners
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of
the
miners vote yes?
If you want the 'emergency cancel' feature without binding yourself
to
it, couldn't you have some middle-of-the-road solution? "Taproot
will be
enabled if miner support ever goes above 95%, or on flag day if
miner
support is >20% then". That would prevent obstreperous miners from
doing
too much damage, while still hopefully making it possible to bail
out of
a disaster.
On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
On Sun, Feb 28, 2021 at 07:33:30PM +0000, Luke Dashjr via
bitcoin-dev
wrote:
As we saw in 2017 with BIP 9, coordinating activation by miner
signal
alone,
despite its potential benefits, also leaves open the door to a
miner
veto.
To the contrary, we saw in 2017 that miners could *not*
successfully
veto a BIP 9 activation. It was certainly more effort and risk
than was
desirable to override the attempted veto, but the attempt at
vetoing
nevertheless failed.
It wouldn't be much different than adding back the inflation bug
(CVE-2018-17144) and trusting miners not to exploit it.
That is ridiculous FUD.
With LOT=False in the picture, however, things can get messy:
LOT=false is always in the picture if we are talking about a
soft-fork:
the defining feature of a soft-fork is that old node software
continues
to work, and old node software will be entirely indifferent to
whether
activation is signalled or not.
some users will
enforce Taproot(eg) (those running LOT=True), while others will
not
(those
with LOT=False)
If you are following bip8 with lockinontimeout=false, you will
enforce
taproot rules if activation occurs, you will simply not reject
blocks
if
activation does not occur.
Users with LOT=True will still get all the safety thereof,
but those with LOT=False will (in the event of miners deciding to
produce a
chain split) face an unreliable chain, being replaced by the
LOT=True
chain
every time it overtakes the LOT=False chain in work.
This assumes anyone mining the chain where taproot does not
activate is
not able to avoid a reorg, despite having majority hashpower (as
implied
by the lot=true chain having to overtake them repeatedly). That's
absurd;
avoiding a reorg is trivially achieved via running
"invalidateblock",
or
via pool software examining block headers, or via a patch along
the
lines
of MUST_SIGNAL enforcement, but doing the opposite. For
concreteness,
here's a sketch of such a patch:
https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
For 2 weeks, users with LOT=False would not have a usable
network.
That's also ridiculous FUD.
If it were true, it would mean the activation mechanism was not
acceptable, as non-upgraded nodes would also not have a usable
network
for the same reason.
Fortunately, it's not true.
More generally, if miners are willing to lose significant amounts
of
money mining orphan blocks, they can do that at any time. If
they're
not inclined to do so, it's incredibly straightforward for them to
avoid
doing so, whatever a minority of other miners might do.
The overall risk is maximally reduced by LOT=True being the only
deployed
parameter, and any introduction of LOT=False only increases risk
probability
and severity.
LOT=false is the default behaviour of everything single piece of
node
software out there. That behaviour doesn't need to be introduced,
it's
already universal.
Cheers,
aj
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
