On Thu, Oct 27, 2022 at 09:49:48AM -0400, Greg Sanders via bitcoin-dev wrote: > So there is some precedence to including an option that protocol devs don't > find useful, then removing it N years later to make sure it doesn't impact > compact blocks.
I think the lesson there is we're willing to remove options that are ridiculous. Replacements are widely used, and downright essential in high-fee situations. > Peering into the "precedence" lense, I think this does lend itself to the > theory that the transition should be as uniform as possible to avoid > degradation of fast block propagation. If not removing options(which is > deemed user hostile by a number of folks including me), then at least for a > flag day switchover. Re: compact blocks, note that RBF is a special case: for the sake of reconstruction, it'd make sense to temporarily cache transactions have have been replaced rather than discarding them entirely, in case a prior version gets mined. Irregardless of policy this will happen occasionally simple due to propagation delays. Equally, if we cached transactions that we rejected due to policy, that'd help with reconstruction success in the event that policy is changing. Anyway, since the compact blocks implementation efficiently deals with the case where miners have policy that differs from most nodes, by immediately forwarding missing transactions, I don't think the occasional full-rbf replacement is going to have much impact. The nodes that had full-rbf disabled will forward the tx to their peers directly, and then the subset of full-rbf disabled peers will do the same again. So long as the network has a mix of both types, and they're interconnected rather than in clusters, the latency impact should be minimal. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
