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-boun...@lists.linuxfoundation.org> On Behalf > Of Luke Dashjr via bitcoin-dev > Sent: Tuesday, January 18, 2022 1:19 PM > To: email@example.com > 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 _______________________________________________ bitcoin-dev mailing list firstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev