Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-19 📝 Original message:On Fri, Jun 17, 2022 at ...
📅 Original date posted:2022-06-19
📝 Original message:On Fri, Jun 17, 2022 at 04:54:11AM +0000, alicexbt via bitcoin-dev wrote:
> > If they'reparties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose suchchanges and invest the engineering effort to do so. If you're interested in advancing the state ofpolicy options in Bitcoin Core, there are a lot of interestingresourcesavailable and communities toencourage you in the learning process to contribute to the codebase [6].
>
> Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)
I don't think more RBF policies in Bitcoin Core helps much. RBF policies aren't
very useful in isolation: unless you're getting your txs to other nodes/miners
via special peering efforts, the only reason to run an uncommon RBF policy is
to accomodate local software with obsolete expectations about mempool behavior.
That's why my full-RBF patch advertised a special service bit, and did
preferential peering with other nodes advertising that service bit.
Bitcoin Core isn't going to do that for every RBF policy. So there's no reason
we should try to accomodate a bunch of them.
I can understand a -fullrbf flag from a political point of view, in the process
of enabling full-RBF all the time. But there's no reason to go beyond that.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220619/e61b93ad/attachment.sig>;
📝 Original message:On Fri, Jun 17, 2022 at 04:54:11AM +0000, alicexbt via bitcoin-dev wrote:
> > If they'reparties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose suchchanges and invest the engineering effort to do so. If you're interested in advancing the state ofpolicy options in Bitcoin Core, there are a lot of interestingresourcesavailable and communities toencourage you in the learning process to contribute to the codebase [6].
>
> Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)
I don't think more RBF policies in Bitcoin Core helps much. RBF policies aren't
very useful in isolation: unless you're getting your txs to other nodes/miners
via special peering efforts, the only reason to run an uncommon RBF policy is
to accomodate local software with obsolete expectations about mempool behavior.
That's why my full-RBF patch advertised a special service bit, and did
preferential peering with other nodes advertising that service bit.
Bitcoin Core isn't going to do that for every RBF policy. So there's no reason
we should try to accomodate a bunch of them.
I can understand a -fullrbf flag from a political point of view, in the process
of enabling full-RBF all the time. But there's no reason to go beyond that.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220619/e61b93ad/attachment.sig>;