Peter Todd [ARCHIVE] on Nostr: š Original date posted:2021-12-18 š Original message:On Sat, Dec 18, 2021 at ...
š
Original date posted:2021-12-18
š Original message:On Sat, Dec 18, 2021 at 08:51:46AM -0800, Jeremy via bitcoin-dev wrote:
> Small idea:
>
> ease into getting rid of full-rbf by keeping the flag working, but make
> enforcement of non-replaceability something that happens n seconds after
> first seen.
>
> this reduces the ability to partition the mempools by broadcasting
> irreplaceable conflicts all at once, and slowly eases clients off of
> relying on non-RBF.
>
> we might start with 60 seconds, and then double every release till we get
> to 600 at which point we disable it.
Making replacability turn on _after_ an expiry time is reached has been
suggested before, IIRC by Matt Corallo. However I believe the approach of
enabling full-rbf _until_ a time is reached is clever and novel.
I'd suggest doing both at once. Long-running txs are certainly useful. But if a
tx hasn't been mined in a few blocks, it certainly can't be relied on for
zeroconf.
--
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/20211218/4f6f02f0/attachment-0001.sig>
š Original message:On Sat, Dec 18, 2021 at 08:51:46AM -0800, Jeremy via bitcoin-dev wrote:
> Small idea:
>
> ease into getting rid of full-rbf by keeping the flag working, but make
> enforcement of non-replaceability something that happens n seconds after
> first seen.
>
> this reduces the ability to partition the mempools by broadcasting
> irreplaceable conflicts all at once, and slowly eases clients off of
> relying on non-RBF.
>
> we might start with 60 seconds, and then double every release till we get
> to 600 at which point we disable it.
Making replacability turn on _after_ an expiry time is reached has been
suggested before, IIRC by Matt Corallo. However I believe the approach of
enabling full-rbf _until_ a time is reached is clever and novel.
I'd suggest doing both at once. Long-running txs are certainly useful. But if a
tx hasn't been mined in a few blocks, it certainly can't be relied on for
zeroconf.
--
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/20211218/4f6f02f0/attachment-0001.sig>