{"type":"rich","version":"1.0","author_name":"npub1w30zwgl8947760cd62fawy9hqmxnq24cga5c8s5j6j7m07w96dnqzjzhn2","author_url":"https://nostr.ae/npub1w30zwgl8947760cd62fawy9hqmxnq24cga5c8s5j6j7m07w96dnqzjzhn2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-19\n📝 Original message:Hi aj,\n\n\u003e I mean, I guess I can understand wanting to reduce that responsibility\n\u003e for maintainers of the github repo, even if for no other reason than to\n\u003e avoid frivolous lawsuits, but where do you expect people to find better\n\u003e advice about what things are a good/bad idea if core devs as a whole\n\u003e are avoiding that responsibility?\n\nBitcoin Core contributors and maintainers should provide the options, recommendations etc. about mempool policies. If these policies are kept for users to change based on their needs, why force anything or change defaults ignoring feedback?\n\n\u003e Core devs are supposedly top technical experts at bitcoin -- which means\n\u003e they're the ones that should have the best understanding of all the\n\u003e implications of policy changes like this.\n\nWhy even provide options for users to change RBF policy in that case? Option to disable was already [removed][1] ignoring NACKs and MarcoFalke prefers users try the [workaround][2] if there is ever a need to disable it. Are we going to remove all the options to switch RBF policies in future because fullrbf has been suggested by leading technical experts? Is there a possibility of experts going wrong and has it ever happened in past?\n\n\u003e It's a bit disappointing that the people that's a problem for didn't\n\u003e engage earlier -- though looking back, I guess there wasn't all that\n\u003e much effort made to reach out, either.\n\nTo be fair, John Carvalho did [comment][3] about this in a pull request although it was wrong PR and never going to be merged.\n\n\u003e And I mean: all this is only about drawing a line in sand; if people\n\u003e think core devs are wrong, they can still let that line blow away in\n\u003e the wind, by running different software, configuring core differently,\n\u003e patching core, or whatever else.\n\nI think this is the best option for users at this point. Keep running older versions of Core and use Knots or other implementations until technical experts in core repository, other bitcoin projects and users are on the same page.\n\n\u003e And the\n\u003e impression I got from the PR review club discussion more seemed like\n\u003e devs making assumptions about businesses rather than having talked to\n\u003e them (eg \"[I] think there are fewer and fewer businesses who absolutely\n\u003e cannot survive without relying on zeroconf. Or at least hope so\").\n\nEven I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks.\n\n[1]: https://github.com/bitcoin/bitcoin/pull/16171\n[2]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1157846575\n[3]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654\n\n/dev/fd0\n\nSent with Proton Mail secure email.\n\n------- Original Message -------\nOn Tuesday, October 18th, 2022 at 12:30 PM, Anthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n\u003e On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:\n\u003e \n\u003e \u003e \u003e 1) Continue supporting and encouraging accepting unconfirmed \"on-chain\"\n\u003e \u003e \u003e payments indefinitely\n\u003e \u003e \u003e 2) Draw a line in the sand now, but give people who are currently\n\u003e \u003e \u003e accepting unconfirmed txs time to update their software and business\n\u003e \u003e \u003e model\n\u003e \u003e \u003e 3) Encourage mainnet miners and relay nodes to support unconditional\n\u003e \u003e \u003e RBF immediately, no matter how much that increases the risk to\n\u003e \u003e \u003e existing businesses that are still accepting unconfirmed txs\n\u003e \u003e \u003e To give more context, the initial approach of enabling full RBF through\n\u003e \u003e \u003e #25353 + #25600 wasn't making the assumption the enablement itself would\n\u003e \u003e \u003e reach agreement of the economic majority or unanimity.\n\u003e \n\u003e \n\u003e Full RBF doesn't need a majority or unanimity to have an impact; it needs\n\u003e adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of\n\u003e a 10MvB mempool can be replaced before being mined naturally), and some\n\u003e way of finding a working path to relay txs to that hashrate.\n\u003e \n\u003e Having a majority of nodes/hashrate support it makes the upsides better,\n\u003e but doesn't change the downsides to the people who are relying on it\n\u003e not being available.\n\u003e \n\u003e \u003e Without denying that such equilibrium would be unstable, it was designed to\n\u003e \u003e remove the responsibility of the Core project itself to \"draw a hard line\"\n\u003e \u003e on the subject.\n\u003e \n\u003e \n\u003e Removing responsibility from core developers seems like it's very much\n\u003e optimising for the wrong thing to me.\n\u003e \n\u003e I mean, I guess I can understand wanting to reduce that responsibility\n\u003e for maintainers of the github repo, even if for no other reason than to\n\u003e avoid frivolous lawsuits, but where do you expect people to find better\n\u003e advice about what things are a good/bad idea if core devs as a whole\n\u003e are avoiding that responsibility?\n\u003e \n\u003e Core devs are supposedly top technical experts at bitcoin -- which means\n\u003e they're the ones that should have the best understanding of all the\n\u003e implications of policy changes like this. Is opt-in RBF only fine? If\n\u003e you look at the network today, it sure seems like it; it takes a pretty\n\u003e good technical understanding to figure out what problems it has, and\n\u003e an even better one to figure out whether those problems can be solved\n\u003e while keeping an opt-in RBF regime, or if full RBF is needed.\n\u003e \n\u003e At that point, the technical experts should be coming up with a\n\u003e specific recommendation, and, personally, I think that's exactly what\n\u003e happened with [0] [1] and [2].\n\u003e \n\u003e [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e [1] https://github.com/bitcoin/bitcoin/pull/25353\n\u003e [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\u003e \n\u003e That did draw hard line in the sand: it said \"hey, opt-in RBF had a good\n\u003e run, but it's time to switch over to full RBF, for these reasons\".\n\u003e \n\u003e It's a bit disappointing that the people that's a problem for didn't\n\u003e engage earlier -- though looking back, I guess there wasn't all that\n\u003e much effort made to reach out, either. There were two mentions in the\n\u003e optech newsletter [3] [4] but it wasn't called out as an \"action item\"\n\u003e (maybe those aren't a thing anymore), so it may have been pretty missable,\n\u003e especially given RBF has been discussed on and off for so long. And the\n\u003e impression I got from the PR review club discussion more seemed like\n\u003e devs making assumptions about businesses rather than having talked to\n\u003e them (eg \"[I] think there are fewer and fewer businesses who absolutely\n\u003e cannot survive without relying on zeroconf. Or at least hope so\").\n\u003e \n\u003e [3] https://bitcoinops.org/en/newsletters/2022/06/22/\n\u003e [4] https://bitcoinops.org/en/newsletters/2022/07/13/\n\u003e \n\u003e If we're happy to not get feedback until we start doing rcs, that's fine;\n\u003e but if we want to say \"oops, we're into release candidates, you should\n\u003e have something earlier, it's too late now\", that's a pretty closed-off\n\u003e way of doing things.\n\u003e \n\u003e And I mean: all this is only about drawing a line in sand; if people\n\u003e think core devs are wrong, they can still let that line blow away in\n\u003e the wind, by running different software, configuring core differently,\n\u003e patching core, or whatever else.\n\u003e \n\u003e \u003e Moreover, relying on node operators turning on the setting\n\u003e \u003e provides a smoother approach offering time to zero-conf services to react\n\u003e \u003e in consequence.\n\u003e \n\u003e \n\u003e I don't think that's remotely true: take a look at taproot activation:\n\u003e it took two months between releasing code that supported signalling and\n\u003e having 98% of hashrate signalling; with 40% of blocks signalling within\n\u003e the first two weeks.\n\u003e \n\u003e \u003e So the current path definitely belongs more to a 3) approach.\n\u003e \n\u003e \u003e \u003e 3) Encourage mainnet miners and relay nodes to support unconditional\n\u003e \u003e \u003e RBF immediately, no matter how much that increases the risk to\n\u003e \u003e \u003e existing businesses that are still accepting unconfirmed txs\n\u003e \n\u003e \n\u003e Yes, that's how it appears to me, too. It's not my preference (giving\n\u003e people clear warning of changes seems much better to me), but I can\n\u003e certainly live with it.\n\u003e \n\u003e But if the line in the sand is \"we're doing this, no matter how much that\n\u003e increases the risk to existing businesses that weren't expecting it\" then\n\u003e it seems very disingenuous not to make those risks very clear so that\n\u003e people who weren't expecting it actually take action to avoid those risks.\n\u003e \n\u003e That is, it seems to me that Dario was exactly right in titling this\n\u003e thread \"Zero-conf apps in immediate danger\", and our co-developers who\n\u003e are dismissing the risk by saying things along the lines of \"probably\n\u003e nothing will change anytime soon\" are exactly wrong.\n\u003e \n\u003e (More generally, that's similar to one of the things I've hated\n\u003e watching in mainstream economics over the past few years: \"doing this\n\u003e will cause massive inflation\" \"no it won't, there's no inflation risk\"\n\u003e \"oops, inflation magically appeared, how did that happen? oh well, too\n\u003e bad, we have to live with it now\". This looks pretty similar to me: \"do\n\u003e something risky, deny the risk, make sure nobody can hold us accountable\n\u003e when the risk eventuates later\" so it makes me really uncomfortable)\n\u003e \n\u003e \u003e While this\n\u003e \u003e way cannot be denied to be a zero-risk deployment for business accepting\n\u003e \u003e unconfirmed transactions, it should be weighed in face of multi-party\n\u003e \u003e contracting protocols encumbering an annoying pinning vector.\n\u003e \n\u003e \n\u003e Sure; that's a fine reason to draw the line in the sand. But it's not\n\u003e a good reason to have it happen immediately, rather than giving people\n\u003e time to react, and it's not a good reason to understate the risk of\n\u003e it happening now. Maybe there are good reasons for either or both of\n\u003e those, though?\n\u003e \n\u003e \u003e Since Dario's mail, I think we have learnt new data points, a) on the long\n\u003e \u003e term full RBF to align miner incentives is acknowledged and b) a clear\n\u003e \u003e timeline based on e.g a block height is favored over the pollination\n\u003e \u003e deployment.\n\u003e \n\u003e \n\u003e Using the passive voice there doesn't seem helpful. Who learnt these\n\u003e things? You, I and Dario all seem to agree with (a), but John Carvalho\n\u003e certainly appears not to, for instance. I'm not sure who agrees with\n\u003e (b) -- I know I do, and I think Dario does; but multiple people seem\n\u003e opposed to the clear timeline offered in #26323, and your #26305 seems\n\u003e more likely to encourage a \"pollination\" approach rather than discourage\n\u003e it (\"oh, this will be the default option for 25.0, might as well enable\n\u003e it now like all the cool kids are\").\n\u003e \n\u003e For what it's worth, my guess is that releasing core with full rbf\n\u003e support and having you and Murch and others advocating for people to\n\u003e try it out, will mean that full RBF is usable on mainnet within two\n\u003e or three months, supported by perhaps 5%-20% hashpower, but probably\n\u003e still requiring special effort to actually find a peer that can relay\n\u003e full rbf txs to that hashpower (probably doing an addnode, despite the\n\u003e privacy implications). Even if that happens, I'm not super confident\n\u003e that it would mean people would actively steal from zeroconf businesses\n\u003e in any volume, though. It's not something I'd risk happening to me,\n\u003e but accepting zeroconf from strangers isn't something I'd risk anyway.\n\u003e \n\u003e Slowing that down from January-ish to May seems like it ought to be a\n\u003e big win for anyone who has been doing zeroconf, and having it be easy\n\u003e to find a path to miners when it is supported seems like a big win even\n\u003e given a cost of a few months delay.\n\u003e \n\u003e OTOH, if we're really not expecting full rbf to be available for many\n\u003e months, then I would have expected the \"disable this for mainnet,\n\u003e reconsider after the release\" PR (#26287) to have gone ahead already.\n\u003e \n\u003e \u003e Tie-breaking between\n\u003e \u003e both, I believe I would favor something like #26323 though only post 24.0\n\u003e \u003e to avoid introducing a bikeshedding precedent in terms of release process,\n\u003e \n\u003e \n\u003e Doing something like #26323 only after 24.0 is out does nothing to\n\u003e mitigate whatever immediate risk there is to bitcoin businesses/users...\n\u003e \n\u003e And if the choice is between \"bikeshedding\" and \"merge a PR, then ignore\n\u003e feedback that it's harmful\", I'd much rather the bikeshedding. What's\n\u003e the point of having rcs if you're going to ignore negative feedback?\n\u003e \n\u003e I mean, if you think the feedback is wrong, that's different: maybe we\n\u003e shouldn't care that zeroconf apps are in immediate danger, and maybe\n\u003e bitcoin would be better if any that don't adapt immediately all die\n\u003e horribly as a lesson to others not to make similarly bad assumptions.\n\u003e \n\u003e But saying \"we don't want them to be in danger\" and also refusing to do\n\u003e anything to avoid it?\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e \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"}