rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 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>