Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-27 📝 Original message:On Thu, Oct 27, 2022 at ...
📅 Original date posted:2022-10-27
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/9719c3e0/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221027/9719c3e0/attachment.sig>;