eric at voskuil.org [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-18 📝 Original message:I won't comment on CTV at ...
📅 Original date posted:2022-01-18
📝 Original message:I won't comment on CTV at this point, but these comments on BIP9 and BIP8
deserve a response, given the intense obfuscation below.
The only material distinction between BIP9 and BIP8 is that the latter may
activate without signaled support of hash power enforcement.
As unenforced soft forks are not "backward compatible" they produce a chain
split. It was for this reason alone that BIP8 never gained sufficient
support.
Taproot activation was in no way a compromise between enforced and
unenforced activation. Unenforced activation was wholly rejected.
> BIP 9 at this point represents developers attempting to disregard and
impose their will over community consensus, as well as an attempt to force a
miner veto backdoor/vulnerability on deployment. It should never be used
again."
This appears to be the start of another marketing campaign, an attempt to
reclaim Taproot activation as some sort of "win" over the "miner backdoor".
The same sort of misleading campaign was waged in the wake of segwit, and
led directly to the conflict around Taproot activation.
The differences between ST and BIP9 are inconsequential in this regard. The
criticism you are making of BIP9 above applies equally to ST.
> As with Taproot, any future deployments should use BIP 8 again
This is one of the most misleading statements I've seen here. It's not
technically a lie, because it states what "should" happen. But it is clearly
intended to lead people to believe that BIP8 was actually used ("again") -
it was not. ST was some technical tweaks to BIP9.
I am making no statement whatsoever on what "should" happen. My interest is
in providing accurate information so that people can make informed
decisions.
The outright deception around this one topic has led to significant
unnecessary conflict in the community. Make your argument, but make it
honestly.
e
> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
Behalf
> Of Luke Dashjr via bitcoin-dev
> Sent: Tuesday, January 18, 2022 1:19 PM
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] CTV BIP review
>
> tl;dr: I don't think CTV is ready yet (but probably close), and in any
case
> definitely not worth reviving BIP 9 with its known flaws and
vulnerability.
...
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
>
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should never be used again.
>
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed
> prior to or in parallel), but using BIP 9 would destroy this.
>
> As with Taproot, any future deployments should use BIP 8 again, until a
better
> solution is developed. Reverting back to a known flawed and vulnerable
> activation method should not be done, and it would be better not to deploy
> CTV at all at such an expense.
>
> The fact that certain developers attempted to deploy a BIP 9 alternative
> activation for Taproot against community consensus, and that even managed
> to get released as "Bitcoin Core", makes it all the more important that
the
> community firmly rejects any further action to force this regression.
>
> * it is my opinion a BIP 8 ST would be an okay compromise under those
> circumstances; others do disagree that ST is acceptable at all
📝 Original message:I won't comment on CTV at this point, but these comments on BIP9 and BIP8
deserve a response, given the intense obfuscation below.
The only material distinction between BIP9 and BIP8 is that the latter may
activate without signaled support of hash power enforcement.
As unenforced soft forks are not "backward compatible" they produce a chain
split. It was for this reason alone that BIP8 never gained sufficient
support.
Taproot activation was in no way a compromise between enforced and
unenforced activation. Unenforced activation was wholly rejected.
> BIP 9 at this point represents developers attempting to disregard and
impose their will over community consensus, as well as an attempt to force a
miner veto backdoor/vulnerability on deployment. It should never be used
again."
This appears to be the start of another marketing campaign, an attempt to
reclaim Taproot activation as some sort of "win" over the "miner backdoor".
The same sort of misleading campaign was waged in the wake of segwit, and
led directly to the conflict around Taproot activation.
The differences between ST and BIP9 are inconsequential in this regard. The
criticism you are making of BIP9 above applies equally to ST.
> As with Taproot, any future deployments should use BIP 8 again
This is one of the most misleading statements I've seen here. It's not
technically a lie, because it states what "should" happen. But it is clearly
intended to lead people to believe that BIP8 was actually used ("again") -
it was not. ST was some technical tweaks to BIP9.
I am making no statement whatsoever on what "should" happen. My interest is
in providing accurate information so that people can make informed
decisions.
The outright deception around this one topic has led to significant
unnecessary conflict in the community. Make your argument, but make it
honestly.
e
> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On
Behalf
> Of Luke Dashjr via bitcoin-dev
> Sent: Tuesday, January 18, 2022 1:19 PM
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] CTV BIP review
>
> tl;dr: I don't think CTV is ready yet (but probably close), and in any
case
> definitely not worth reviving BIP 9 with its known flaws and
vulnerability.
...
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
>
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should never be used again.
>
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed
> prior to or in parallel), but using BIP 9 would destroy this.
>
> As with Taproot, any future deployments should use BIP 8 again, until a
better
> solution is developed. Reverting back to a known flawed and vulnerable
> activation method should not be done, and it would be better not to deploy
> CTV at all at such an expense.
>
> The fact that certain developers attempted to deploy a BIP 9 alternative
> activation for Taproot against community consensus, and that even managed
> to get released as "Bitcoin Core", makes it all the more important that
the
> community firmly rejects any further action to force this regression.
>
> * it is my opinion a BIP 8 ST would be an okay compromise under those
> circumstances; others do disagree that ST is acceptable at all