Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-02 📝 Original message:This is the declining ...
📅 Original date posted:2021-03-02
📝 Original message: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 <
bitcoin-dev at lists.linuxfoundation.org> 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
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210302/1ac9853a/attachment-0001.html>;
📝 Original message: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 <
bitcoin-dev at lists.linuxfoundation.org> 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
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210302/1ac9853a/attachment-0001.html>;