{"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-11-02\n📝 Original message:On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev wrote:\n\u003e For 0-conf services we have potential thieves who are willing\n\u003e to *out-bid themselves* to have funds come back to themselves. It's not a\n\u003e \"legitimate\" use-case, but a rational one.\n\nI think that's a huge oversimplification of \"rational\" -- otherwise\nyou might as well say that deliberately pinning txs is also rational,\nbecause it allows the person doing the pinning to steal funds from their\ncounterparty by forcing a timeout to expire.\n\nThere's no need for us as developers, or us as node operators, to support\nevery use case that some individual might find rational at some point in\ntime. After all, it might be individually rational for someone to want the\nsubsidy to stop decreasing, or to include 8MB of transactions per block.\n\nNote that it's also straightforwardly rational and incentive compatible\nfor miners to not want this patch to be available, under the following\nscenario:\n\n - a significant number of on-chain txs are for zeroconf services\n - fee income would be reduced if zeroconf services went away\n   (both directly due to the absence of zeroconf payments, and by\n   reducing mempool pressure, reducing fee income from the on-chain txs\n   that remain)\n - miners adopting fullrbf would cause zeroconf services to go away,\n   (and won't enable a comparable volume of new services that generates\n   comparable transaction volume)\n - including the option in core would make other miners adopting\n   fullrbf more likely\n\nI think the first three of those are fairly straightforward and objective,\nat least at this point in time. The last is just a risk; but without\nany counterbalancing benefit, why take it?\n\nGaining a few thousand sats due to high feerate replacement txs from\npeople exploiting zeroconf services for a few months before all those\nservices shutdown doesn't make up for the lost fee income over the months\nor years it might have otherwise taken people to naturally switch to\nsome better alternative.\n\nEven if fullrbf worked for preventing pinning that likely doesn't directly\nresult in much additional fee income: once you know that pinning doesn't\nwork, you just don't try it, which means there's no opportunity for\nminers to profit from a bidding war from the pinners counterparties\nrepeatedly RBFing their preferred tx to get it mined.\n\nThat also excludes second order risks: if you can't do zeroconf with BTC\nanymore, do you switch to ERC20 tokens, and then trade your BTC savings\nfor ETH or USDT, and do enough people do that to lower the price of BTC?\nIf investors see BTC being less used for payments, does that lower their\nconfidence in bitcoin's future, and cause them to sell?\n\n\u003e Removing a\n\u003e quite-likely-incentive-compatible option from the software just encourages\n\u003e miners to adopt an additional patch\n\nWhy shouldn't miners adopt an additional patch if they want some unusual\nfunctionality?\n\nDon't we want/expect miners to have the ability to change the code in\nmeaningful ways, at a minimum to be able to cope with the scenario where\ncore somehow gets coopted and releases bad code, or to be able to deal\nwith the case where an emergency patch is needed?\n\nIs there any evidence miners even want this option? Peter suggested\nthat some non-signalling replacements were being mined already [0], but\nas far as I can see [1] all of those are simply due to the transaction\nthey replaced not having propagated in the first place (or having been\nevicted somehow? hard to tell without any data on the original tx).\n\n[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html\n[1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367\n\n\u003e 2) Forcing miners to honor fees left on the table with respect to 0-conf,\n\u003e or forcing them to run a custom patchset to go around it, is a step\n\u003e backwards.\n\nAs you already acknowledged, any miner that wants this behaviour can just\npick up the patch (or could run Knots, which already has the feature\nenabled by default). It's simply false to say miners are being forced\nto do anything, no matter what we do here. \n\nIf the direction you're facing is one where you're moving towards making\nlife easier for people to commit fraud, and driving away businesses\nthat aren't doing anyone harm, without achieving anything much else;\nthen taking a step backwards seems like a sensible thing to do to me.\n\n(I remain optimistic about coming up with better RBF policy, and willing\nto be gung ho about everyone switching over to it even if it does kill\noff zeroconf, provided it actually does some good and we give people 6\nmonths or more notice that it's definitely happening and what exactly\nthe new rules will be, though)\n\nCheers,\naj"}