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
On Tue, Mar 02, 2021 at 06:21:59PM +, Chris Belcher via bitcoin-dev wrote:
> It is wrong to say that using miner signalling alone for activation
> (LOT=false) is a bug.
That depends on the definition you choose to work with but since the community
had to produce a fix that implies something
To clarify, it is the soft fork enforcement by majority hash power that is the
51% attack, not the stopping of it. Majority hash power censors non-conforming
transactions. To counter it requires only a non-censoring majority to continue
mining.
It is correct that the purpose of supermajority
It is wrong to say that using miner signalling alone for activation
(LOT=false) is a bug.
As we vividly saw in the events of the 2017 UASF, the purpose of miner
signalling isn't to activate or enforce the new rules but to stop a
chain split. A majority of miners can stop a chain split by
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
On Tue, Mar 02, 2021 at 01:06:14AM +1000, Anthony Towns via bitcoin-dev wrote:
> On Sun, Feb 28, 2021 at 07:33:30PM +, 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
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
On Sun, Feb 28, 2021 at 07:33:30PM +, 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*
(Note: I am writing this as a general case against LOT=False, but using
Taproot simply as an example softfork. Note that this is addressing
activation under the assumption that the softfork is ethical and has
sufficient community support. If those criteria have not been met, no
activation
