{"type":"rich","version":"1.0","author_name":"npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","author_url":"https://nostr.ae/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-17\n📝 Original message:AJ,\n\nThanks for the latest PR and discussion, even if we know we're all (very,\nvery, very) tired of it running almost 10 years now. I think we're close to\na resolution, (2), or (3) as you note.\n\nAs ariard notes in\nhttps://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572 we\nseem to have sketched out the sane design space for the transition, so now\nit's time to choose how we want to spend our energy and time on this.\n\nI do think patch complexity is a real concern, which\nmeans fullrbf-signalling PR has a harder road to deployment and gets push\nback from fullrbf-default-now folks who correctly argue this. It seems\nuseful to \"prove a point\" on the nature of these schemes, but not much else.\n\nPersonally I have no qualms with kicking back flag-day-fullrbf another\nrelease cycle and 6 additional months to obviate the need for a 24.0\nbackport(however small!) and to give a bit more time to weigh choices.\nPeople can begin testing with their node software on an opt-in basis(but\nnot the required ~10% of nodes), 25.0+ nodes will flag-day, then a year\nfrom now the community can start testing if miners have picked up said\nchanges.\n\nSpeaking to no one in particular, there's no virtue in dragging on the\ndiscussion to \"prove a point\" to \"merchants\"/\"Core devs\" when we could be\nspending our time more wisely fixing the many other issues with our mempool\nand wallet ecosystem.\n\nBest,\nGreg\n\nOn Sun, Oct 16, 2022 at 4:09 AM Anthony Towns via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev\n\u003e wrote:\n\u003e \u003e On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev\n\u003e wrote:\n\u003e \u003e \u003e In my view, it is just what I said: a step towards getting full RBF\n\u003e \u003e \u003e on the network, by allowing experimentation and socializing the notion\n\u003e \u003e \u003e that developers believe it is time.\n\u003e \u003e We \"believe it is time\" for what exactly, though? (a) To start\n\u003e \u003e deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or\n\u003e \u003e 18 months; or (b) to start switching mainnet mining and relay nodes over\n\u003e \u003e to full RBF?\n\u003e\n\u003e For what it's worth, that was a serious question: I don't feel like I\n\u003e know what other people's answer to it is.\n\u003e\n\u003e Seems to me like there's fundamentally maybe three approaches:\n\u003e\n\u003e  1) Continue supporting and encouraging accepting unconfirmed \"on-chain\"\n\u003e     payments indefinitely\n\u003e\n\u003e  2) Draw a line in the sand now, but give people who are currently\n\u003e     accepting unconfirmed txs time to update their software and business\n\u003e     model\n\u003e\n\u003e  3) Encourage mainnet miners and relay nodes to support unconditional\n\u003e     RBF immediately, no matter how much that increases the risk to\n\u003e     existing businesses that are still accepting unconfirmed txs\n\u003e\n\u003e I think Antoine gave a pretty decent rationale for why we shouldn't\n\u003e indefinitely continue with conditional RBF in [0] [1] -- it makes it\n\u003e easy to disrupt decentralised pooling protocols, whether that be for\n\u003e establishing lightning channels or coinjoins or anything else.\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\u003e\n\u003e It's also an unstable equilibrium -- if everyone does first-seen-is-final\n\u003e at the mempool level, everything is fine; but it only takes a few\n\u003e defectors to start relaying and mining full RBF txs to spoil zeroconf\n\u003e for everyone -- so even if it were desirable to maintain it forever,\n\u003e it's probably not actually possible to maintain it indefinitely.\n\u003e\n\u003e If so, that leaves the choice between (2) and (3). You might argue\n\u003e that there's a 4th option: ignore the problem and think about it later;\n\u003e but to me that seems like it will just eventually result in outcome (3).\n\u003e\n\u003e\n\u003e At least a few people are already running full RBF relay nodes [2] [3]\n\u003e [4], and there's a report that non-signalling RBF txs are now getting\n\u003e mined [5] when they weren't a few months ago [6]. I wasn't able to\n\u003e confirm the latter to my satisfaction: looking at mempool.observer, the\n\u003e non-RBF signalling conflicting txs don't seem to have been consistently\n\u003e paying a higher feerate, so I couldn't rule out the possibility that\n\u003e the difference might just be due to inconsistent relaying.\n\u003e\n\u003e [2] https://twitter.com/murchandamus/status/1552488955328831492\n\u003e [3] https://twitter.com/LukeDashjr/status/977211607947317254\n\u003e [4]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html\n\u003e [5]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html\n\u003e [6]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html\n\u003e\n\u003e It seems to me that the best approach for implementing (3) would be\n\u003e to change the default for -mempoolfullrbf to true immediately, which\n\u003e is both what Knots has been doing for years, and what #26305 proposes\n\u003e [7].  So from seeing what people are actually *doing*, I could easily\n\u003e be convinced that (3) is the goal people are actually working towards.\n\u003e\n\u003e [7] https://github.com/bitcoin/bitcoin/pull/26305\n\u003e\n\u003e But if (3) *is* what we're really trying to do, I think it's a bit\n\u003e disingenuous to assume that that effort will fail, and tell people that\n\u003e nothing's going to change on mainnet in the near future [8] [9] [10]\n\u003e [11]. If pools are starting to allow replacements of txs that didn't\n\u003e signal according to BIP 125 and mine blocks including those replacements,\n\u003e then it's true that zero-conf apps are in much more immediate danger\n\u003e than they were a month ago, and as far as I can see, we shouldn't be\n\u003e pretending otherwise.\n\u003e\n\u003e [8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204\n\u003e [9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043\n\u003e [10]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html\n\u003e [11]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html\n\u003e\n\u003e Personally, I prefer an approach like (2) -- commit to doing something\n\u003e first, give people time to prepare for it, and then do it, and outside\n\u003e of Knots, I don't think there's been any clear commitment to deprecating\n\u003e zeroconf txs up until now. But what we're currently doing is suboptimal\n\u003e for that in two ways:\n\u003e\n\u003e  - there's no real commitment that the change will actually happen\n\u003e  - even if it does, there's no indication when that will be\n\u003e  - it's not easy to test your apps against the new world order, because\n\u003e    it's not well supported on either testnet or signet, being disabled\n\u003e    by default on both those networks\n\u003e\n\u003e Dario suggested an approach [12] that seems like it would resolve all\n\u003e these issues:\n\u003e\n\u003e ] This could be one such proposal:\n\u003e ] 1. We activate [..] full-RBF on testnet now.\n\u003e ] 2. We commit now (in the code) to a block height in the future at\n\u003e ]    which [..] full-RBF will activate on mainnet.\n\u003e\n\u003e (I've delted the words \"opt-in\" and \"opt-out\" from the quote above,\n\u003e because they didn't make sense to me)\n\u003e\n\u003e [12]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html\n\u003e\n\u003e I've made up a patch along these lines [13]; it's easy to use a timestamp\n\u003e rather than a block height, so I've arbitrarily picked 1st May (slightly\n\u003e over 6 months away) as the changeover time. If people are willing to\n\u003e give zeroconf businesses some time to adapt, including something along\n\u003e those lines in 24.0 seems a better approach to me:\n\u003e\n\u003e  * it gives a clear deadline for businesses to adapt, so that they don't\n\u003e    defer it and suddenly complain \"oh no, we didn't think you were\n\u003e    serious, please give us more time\" later\n\u003e\n\u003e  * it gives plenty(?) of time to update your code and test it, as well\n\u003e    as teach customers and customer support about the new behaviour\n\u003e\n\u003e  * when the deadline hits, presumably plenty of nodes and miners will\n\u003e    immediately start supporting the new behaviour on mainnet, so that\n\u003e    protocols can quickly start relying on that method of tx pinning no\n\u003e    longer being applicable\n\u003e\n\u003e  * nodes on signet and testnet will quickly adopt the new behaviour,\n\u003e    well before it's available on mainnet, making testing easier\n\u003e\n\u003e [13] https://github.com/bitcoin/bitcoin/pull/26323\n\u003e\n\u003e To me, this seems like a good way of achieving what I said previously:\n\u003e\n\u003e \u003e If we're trying to socialise the idea that zeroconf deprecation is\n\u003e \u003e happening and that your business now has a real deadline for migrating\n\u003e \u003e away from accepting unconfirmed txs if the risk of being defrauded\n\u003e \u003e concerns you, then enabling experimentation on test nets and not touching\n\u003e \u003e mainnet until a later release seems fairly fine to me -- similar to\n\u003e \u003e activating soft forks on test nets prior to activating it on mainnet.\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/b9415d4b/attachment.html\u003e"}