{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-17\n📝 Original message:Hi AJ,\n\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\nTo give more context, the initial approach of enabling full RBF through\n#25353 + #25600 wasn't making the assumption the enablement itself would\nreach agreement of the economic majority or unanimity. Rather, it would\ngive the tools to node operators to build full-rbf relay paths and as such\nto fulfill their applications requirements (e.g lightning dual-funding).\nWithout denying that such equilibrium would be unstable, it was designed to\nremove the responsibility of the Core project itself to \"draw a hard line\"\non the subject. Moreover, relying on node operators turning on the setting\nprovides a smoother approach offering time to zero-conf services to react\nin consequence.\n\nSo the current path definitely belongs more to a 3) approach. While this\nway cannot be denied to be a zero-risk deployment for business accepting\nunconfirmed transactions, it should be weighed in face of multi-party\ncontracting protocols encumbering an annoying pinning vector. It sounds to\nme that an adequate way to resolve such a \"split-risk\" situation has been\nto adopt a \"micro\" release practice rather than a \"macro\" one, namely offer\nthe options to node operators and let them vote with their respective\neconomic traffics.\n\nSince Dario's mail, I think we have learnt new data points, a) on the long\nterm full RBF to align miner incentives is acknowledged and b) a clear\ntimeline based on e.g a block height is favored over the pollination\ndeployment.\n\nAs such, I think it makes sense to revise the full RBF deployment approach,\nconcentrating the discussion on the reasonable time buffer we should adopt\nbefore activating full RBF on mainet. A time buffer realistic with respect\nto the engineering,\noperational and vendoring needs of the zero-conf businesses/applications. I\nhope both #26305 and #26323 answer those criterias. Tie-breaking between\nboth, I believe I would favor something like #26323 though only post 24.0\nto avoid introducing a bikeshedding precedent in terms of release process,\nand with a longer timeline to be sure we ship 25.0 before the activation\nday. Though listening to more feedback and decision factors, if we have\nmore things to consider.\n\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\nConcerning my statement only, it should be re-contextualize with the other\nstatements calling the zero-conf operators to adapt their services, or\nraise concerns, or be proactive at least [0]. On the other hand, from my\nperspective, a status quo situation is also unsafe, as we left things like\nmulti-party coinjoins being DoSed by deanonymizing attackers. So in case of\nrisk arbitrage situation, as developers, best we can do is be vocal about\nit and if possible find a common ground among all stakeholders. And I think\nthis is what this current thread aims to achieve, which I would say is a\nhealthy release process.\n\nBest,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\nLe dim. 16 oct. 2022 à 04:09, Anthony Towns via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\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/1123fc5d/attachment-0001.html\u003e"}