{"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-18\n📝 Original message:On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:\n\u003e \u003e  1) Continue supporting and encouraging accepting unconfirmed \"on-chain\"\n\u003e \u003e     payments indefinitely\n\u003e \u003e  2) Draw a line in the sand now, but give people who are currently\n\u003e \u003e     accepting unconfirmed txs time to update their software and business\n\u003e \u003e     model\n\u003e \u003e  3) Encourage mainnet miners and relay nodes to support unconditional\n\u003e \u003e     RBF immediately, no matter how much that increases the risk to\n\u003e \u003e     existing businesses that are still accepting unconfirmed txs\n\u003e To give more context, the initial approach of enabling full RBF through\n\u003e #25353 + #25600 wasn't making the assumption the enablement itself would\n\u003e reach agreement of the economic majority or unanimity. \n\nFull RBF doesn't need a majority or unanimity to have an impact; it needs\nadoption by perhaps 10% of hashrate (so a low fee tx at the bottom of\na 10MvB mempool can be replaced before being mined naturally), and some\nway of finding a working path to relay txs to that hashrate.\n\nHaving a majority of nodes/hashrate support it makes the upsides better,\nbut doesn't change the downsides to the people who are relying on it\nnot being available.\n\n\u003e Without denying that such equilibrium would be unstable, it was designed to\n\u003e remove the responsibility of the Core project itself to \"draw a hard line\"\n\u003e on the subject.\n\nRemoving responsibility from core developers seems like it's very much\noptimising for the wrong thing to me.\n\nI mean, I guess I can understand wanting to reduce that responsibility\nfor maintainers of the github repo, even if for no other reason than to\navoid frivolous lawsuits, but where do you expect people to find better\nadvice about what things are a good/bad idea if core devs as a whole\nare avoiding that responsibility?\n\nCore devs are supposedly top technical experts at bitcoin -- which means\nthey're the ones that should have the best understanding of all the\nimplications of policy changes like this. Is opt-in RBF only fine? If\nyou look at the network today, it sure seems like it; it takes a pretty\ngood technical understanding to figure out what problems it has, and\nan even better one to figure out whether those problems can be solved\nwhile keeping an opt-in RBF regime, or if full RBF is needed.\n\nAt that point, the technical experts *should* be coming up with a\nspecific recommendation, and, personally, I think that's exactly what\nhappened with [0] [1] and [2].\n\n[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n[1] https://github.com/bitcoin/bitcoin/pull/25353\n[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\nThat did draw hard line in the sand: it said \"hey, opt-in RBF had a good\nrun, but it's time to switch over to full RBF, for these reasons\".\n\nIt's a bit disappointing that the people that's a problem for didn't\nengage earlier -- though looking back, I guess there wasn't all that\nmuch effort made to reach out, either. There were two mentions in the\noptech newsletter [3] [4] but it wasn't called out as an \"action item\"\n(maybe those aren't a thing anymore), so it may have been pretty missable,\nespecially given RBF has been discussed on and off for so long. And the\nimpression I got from the PR review club discussion more seemed like\ndevs making assumptions about businesses rather than having talked to\nthem (eg \"[I] think there are fewer and fewer businesses who absolutely\ncannot survive without relying on zeroconf. Or at least hope so\").\n\n[3] https://bitcoinops.org/en/newsletters/2022/06/22/\n[4] https://bitcoinops.org/en/newsletters/2022/07/13/\n\nIf we're happy to not get feedback until we start doing rcs, that's fine;\nbut if we want to say \"oops, we're into release candidates, you should\nhave something earlier, it's too late now\", that's a pretty closed-off\nway of doing things.\n\nAnd I mean: all this is only about drawing a line in *sand*; if people\nthink core devs are wrong, they can still let that line blow away in\nthe wind, by running different software, configuring core differently,\npatching core, or whatever else.\n\n\u003e Moreover, relying on node operators turning on the setting\n\u003e provides a smoother approach offering time to zero-conf services to react\n\u003e in consequence.\n\nI don't think that's remotely true: take a look at taproot activation:\nit took two months between releasing code that supported signalling and\nhaving 98% of hashrate signalling; with 40% of blocks signalling within\nthe first two weeks.\n\n\u003e So the current path definitely belongs more to a 3) approach.\n\n\u003e \u003e  3) Encourage mainnet miners and relay nodes to support unconditional\n\u003e \u003e     RBF immediately, no matter how much that increases the risk to\n\u003e \u003e     existing businesses that are still accepting unconfirmed txs\n\nYes, that's how it appears to me, too. It's not my preference (giving\npeople clear warning of changes seems much better to me), but I can\ncertainly live with it.\n\nBut if the line in the sand is \"we're doing this, no matter how much that\nincreases the risk to existing businesses that weren't expecting it\" then\nit seems *very* disingenuous not to make those risks very clear so that\npeople who weren't expecting it actually take action to avoid those risks.\n\nThat is, it seems to me that Dario was exactly right in titling this\nthread \"Zero-conf apps in immediate danger\", and our co-developers who\nare dismissing the risk by saying things along the lines of \"probably\nnothing will change anytime soon\" are exactly wrong.\n\n(More generally, that's similar to one of the things I've hated\nwatching in mainstream economics over the past few years: \"doing this\nwill cause massive inflation\" \"no it won't, there's no inflation risk\"\n\"oops, inflation magically appeared, how did that happen? oh well, too\nbad, we have to live with it now\". This looks pretty similar to me: \"do\nsomething risky, deny the risk, make sure nobody can hold us accountable\nwhen the risk eventuates later\" so it makes me really uncomfortable)\n\n\u003e While this\n\u003e way cannot be denied to be a zero-risk deployment for business accepting\n\u003e unconfirmed transactions, it should be weighed in face of multi-party\n\u003e contracting protocols encumbering an annoying pinning vector.\n\nSure; that's a fine reason to draw the line in the sand. But it's not\na good reason to have it happen immediately, rather than giving people\ntime to react, and it's not a good reason to understate the risk of\nit happening now. Maybe there are good reasons for either or both of\nthose, though?\n\n\u003e Since Dario's mail, I think we have learnt new data points, a) on the long\n\u003e term full RBF to align miner incentives is acknowledged and b) a clear\n\u003e timeline based on e.g a block height is favored over the pollination\n\u003e deployment.\n\nUsing the passive voice there doesn't seem helpful. Who learnt these\nthings? You, I and Dario all seem to agree with (a), but John Carvalho\ncertainly appears not to, for instance. I'm not sure who agrees with\n(b) -- I know I do, and I think Dario does; but multiple people seem\nopposed to the clear timeline offered in #26323, and your #26305 seems\nmore likely to encourage a \"pollination\" approach rather than discourage\nit (\"oh, this will be the default option for 25.0, might as well enable\nit now like all the cool kids are\").\n\nFor what it's worth, my guess is that releasing core with full rbf\nsupport and having you and Murch and others advocating for people to\ntry it out, will mean that full RBF is usable on mainnet within two\nor three months, supported by perhaps 5%-20% hashpower, but probably\nstill requiring special effort to actually find a peer that can relay\nfull rbf txs to that hashpower (probably doing an addnode, despite the\nprivacy implications). Even if that happens, I'm not super confident\nthat it would mean people would actively steal from zeroconf businesses\nin any volume, though. It's not something I'd risk happening to me,\nbut accepting zeroconf from strangers isn't something I'd risk anyway.\n\nSlowing that down from January-ish to May seems like it ought to be a\nbig win for anyone who has been doing zeroconf, and having it be easy\nto find a path to miners when it is supported seems like a big win even\ngiven a cost of a few months delay.\n\nOTOH, if we're really not expecting full rbf to be available for many\nmonths, then I would have expected the \"disable this for mainnet,\nreconsider after the release\" PR (#26287) to have gone ahead already.\n\n\u003e Tie-breaking between\n\u003e both, I believe I would favor something like #26323 though only post 24.0\n\u003e to avoid introducing a bikeshedding precedent in terms of release process,\n\nDoing something like #26323 only after 24.0 is out does nothing to\nmitigate whatever immediate risk there is to bitcoin businesses/users...\n\nAnd if the choice is between \"bikeshedding\" and \"merge a PR, then ignore\nfeedback that it's harmful\", I'd much rather the bikeshedding. What's\nthe point of having rcs if you're going to ignore negative feedback?\n\nI mean, if you think the feedback is wrong, that's different: maybe we\nshouldn't care that zeroconf apps are in immediate danger, and maybe\nbitcoin would be better if any that don't adapt immediately all die\nhorribly as a lesson to others not to make similarly bad assumptions.\n\nBut saying \"we don't want them to be in danger\" and also refusing to do\nanything to avoid it?\n\nCheers,\naj"}