{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-14\n📝 Original message:On Fri, Oct 14, 2022 at 02:44:04AM +0000, alicexbt via bitcoin-dev wrote:\n\u003e \u003e Relay of fullrbf transactions works reasonable well\n\u003e \u003e already, unless you get unlucky with your selected peers. The only\n\u003e \u003e missing piece is a few percent of hashrate that will accept fullrbf\n\u003e \u003e replacement transactions. \n\u003e \n\u003e I don't believe relay of fullrbf transactions works well right now. The missing piece you mentioned is important and a real need for all full node users to try fullrbf.\n\nRelay of full-rbf transactions works well right now precisely because a few\nimplementations exist of preferential rbf peering. I'm personally running four\nnodes with it enabled, two using my own custom patches, and another two using\nariad's patch:\n\nhttps://github.com/bitcoin/bitcoin/pull/25600\n\nI haven't seen a lot of non-opt-in doublespends get mined. But I have seen a\nfew now via my Alice OTS calendar. This can of course increase dramatically as\nminers turn on full-rbf.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221014/7d612ef5/attachment.sig\u003e"}