{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-16\n📝 Original message:On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev wrote:\n\u003e On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote:\n\u003e \u003e In my view, it is just what I said: a step towards getting full RBF\n\u003e \u003e on the network, by allowing experimentation and socializing the notion\n\u003e \u003e that developers believe it is time.\n\u003e We \"believe it is time\" for what exactly, though? (a) To start\n\u003e deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or\n\u003e 18 months; or (b) to start switching mainnet mining and relay nodes over\n\u003e to full RBF?\n\nFor what it's worth, that was a serious question: I don't feel like I\nknow what other people's answer to it is.\n\nSeems to me like there's fundamentally maybe three approaches:\n\n 1) Continue supporting and encouraging accepting unconfirmed \"on-chain\"\n    payments indefinitely\n\n 2) Draw a line in the sand now, but give people who are currently\n    accepting unconfirmed txs time to update their software and business\n    model\n\n 3) Encourage mainnet miners and relay nodes to support unconditional\n    RBF immediately, no matter how much that increases the risk to\n    existing businesses that are still accepting unconfirmed txs\n\nI think Antoine gave a pretty decent rationale for why we shouldn't\nindefinitely continue with conditional RBF in [0] [1] -- it makes it\neasy to disrupt decentralised pooling protocols, whether that be for\nestablishing lightning channels or coinjoins or anything else.\n\n[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\nIt's also an unstable equilibrium -- if everyone does first-seen-is-final\nat the mempool level, everything is fine; but it only takes a few\ndefectors to start relaying and mining full RBF txs to spoil zeroconf\nfor everyone -- so even if it were desirable to maintain it forever,\nit's probably not actually possible to maintain it indefinitely.\n\nIf so, that leaves the choice between (2) and (3). You might argue\nthat there's a 4th option: ignore the problem and think about it later;\nbut to me that seems like it will just eventually result in outcome (3).\n\n\nAt least a few people are already running full RBF relay nodes [2] [3]\n[4], and there's a report that non-signalling RBF txs are now getting\nmined [5] when they weren't a few months ago [6]. I wasn't able to\nconfirm the latter to my satisfaction: looking at mempool.observer, the\nnon-RBF signalling conflicting txs don't seem to have been consistently\npaying a higher feerate, so I couldn't rule out the possibility that\nthe difference might just be due to inconsistent relaying.\n\n[2] https://twitter.com/murchandamus/status/1552488955328831492\n[3] https://twitter.com/LukeDashjr/status/977211607947317254\n[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html\n[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html\n[6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html\n\nIt seems to me that the best approach for implementing (3) would be\nto change the default for -mempoolfullrbf to true immediately, which\nis both what Knots has been doing for years, and what #26305 proposes\n[7].  So from seeing what people are actually *doing*, I could easily\nbe convinced that (3) is the goal people are actually working towards.\n\n[7] https://github.com/bitcoin/bitcoin/pull/26305\n\nBut if (3) *is* what we're really trying to do, I think it's a bit\ndisingenuous to assume that that effort will fail, and tell people that\nnothing's going to change on mainnet in the near future [8] [9] [10]\n[11]. If pools are starting to allow replacements of txs that didn't\nsignal according to BIP 125 and mine blocks including those replacements,\nthen it's true that zero-conf apps are in much more immediate danger\nthan they were a month ago, and as far as I can see, we shouldn't be\npretending otherwise.\n\n[8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204\n[9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043\n[10] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html\n[11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html\n\nPersonally, I prefer an approach like (2) -- commit to doing something\nfirst, give people time to prepare for it, and then do it, and outside\nof Knots, I don't think there's been any clear commitment to deprecating\nzeroconf txs up until now. But what we're currently doing is suboptimal\nfor that in two ways:\n\n - there's no real commitment that the change will actually happen\n - even if it does, there's no indication when that will be\n - it's not easy to test your apps against the new world order, because\n   it's not well supported on either testnet or signet, being disabled\n   by default on both those networks\n\nDario suggested an approach [12] that seems like it would resolve all\nthese issues:\n\n] This could be one such proposal:\n] 1. We activate [..] full-RBF on testnet now.\n] 2. We commit now (in the code) to a block height in the future at\n]    which [..] full-RBF will activate on mainnet.\n\n(I've delted the words \"opt-in\" and \"opt-out\" from the quote above,\nbecause they didn't make sense to me)\n\n[12] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html\n\nI've made up a patch along these lines [13]; it's easy to use a timestamp\nrather than a block height, so I've arbitrarily picked 1st May (slightly\nover 6 months away) as the changeover time. If people are willing to\ngive zeroconf businesses some time to adapt, including something along\nthose lines in 24.0 seems a better approach to me:\n\n * it gives a clear deadline for businesses to adapt, so that they don't\n   defer it and suddenly complain \"oh no, we didn't think you were\n   serious, please give us more time\" later\n\n * it gives plenty(?) of time to update your code and test it, as well\n   as teach customers and customer support about the new behaviour\n\n * when the deadline hits, presumably plenty of nodes and miners will\n   immediately start supporting the new behaviour on mainnet, so that\n   protocols can quickly start relying on that method of tx pinning no\n   longer being applicable\n\n * nodes on signet and testnet will quickly adopt the new behaviour,\n   well before it's available on mainnet, making testing easier\n\n[13] https://github.com/bitcoin/bitcoin/pull/26323\n\nTo me, this seems like a good way of achieving what I said previously:\n\n\u003e If we're trying to socialise the idea that zeroconf deprecation is\n\u003e happening and that your business now has a real deadline for migrating\n\u003e away from accepting unconfirmed txs if the risk of being defrauded\n\u003e concerns you, then enabling experimentation on test nets and not touching\n\u003e mainnet until a later release seems fairly fine to me -- similar to\n\u003e activating soft forks on test nets prior to activating it on mainnet.\n\nCheers,\naj"}