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