{"type":"rich","version":"1.0","author_name":"npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","author_url":"https://nostr.ae/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-11-02\n📝 Original message:\u003e I 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\nTo be clear, a pinner is attempting to *not* pay\nthe most fees, by definition. If we're somehow sure something is a pin,\nwe should not allow it, because miners rationally do not want it vs\nan \"honest\" bid for fees. V3 design is one attempt to carve out a safe\nspace for fee bidding. Carving out a safe space for *non-bidding* is not the\nsame thing.\n\nI think this mostly boils down having knobs or not. I'm fine with knobs\nwith paternalistic defaults, especially when a non-zero percentage of users\ndisagree with a value in either direction.\n\nGreg\n\nOn Tue, Nov 1, 2022 at 11:07 PM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e On Mon, Oct 31, 2022 at 12:25:46PM -0400, Greg Sanders via bitcoin-dev\n\u003e wrote:\n\u003e \u003e For 0-conf services we have potential thieves who are willing\n\u003e \u003e to *out-bid themselves* to have funds come back to themselves. It's not a\n\u003e \u003e \"legitimate\" use-case, but a rational one.\n\u003e\n\u003e I think that's a huge oversimplification of \"rational\" -- otherwise\n\u003e you might as well say that deliberately pinning txs is also rational,\n\u003e because it allows the person doing the pinning to steal funds from their\n\u003e counterparty by forcing a timeout to expire.\n\u003e\n\u003e There's no need for us as developers, or us as node operators, to support\n\u003e every use case that some individual might find rational at some point in\n\u003e time. After all, it might be individually rational for someone to want the\n\u003e subsidy to stop decreasing, or to include 8MB of transactions per block.\n\u003e\n\u003e Note that it's also straightforwardly rational and incentive compatible\n\u003e for miners to not want this patch to be available, under the following\n\u003e scenario:\n\u003e\n\u003e  - a significant number of on-chain txs are for zeroconf services\n\u003e  - fee income would be reduced if zeroconf services went away\n\u003e    (both directly due to the absence of zeroconf payments, and by\n\u003e    reducing mempool pressure, reducing fee income from the on-chain txs\n\u003e    that remain)\n\u003e  - miners adopting fullrbf would cause zeroconf services to go away,\n\u003e    (and won't enable a comparable volume of new services that generates\n\u003e    comparable transaction volume)\n\u003e  - including the option in core would make other miners adopting\n\u003e    fullrbf more likely\n\u003e\n\u003e I think the first three of those are fairly straightforward and objective,\n\u003e at least at this point in time. The last is just a risk; but without\n\u003e any counterbalancing benefit, why take it?\n\u003e\n\u003e Gaining a few thousand sats due to high feerate replacement txs from\n\u003e people exploiting zeroconf services for a few months before all those\n\u003e services shutdown doesn't make up for the lost fee income over the months\n\u003e or years it might have otherwise taken people to naturally switch to\n\u003e some better alternative.\n\u003e\n\u003e Even if fullrbf worked for preventing pinning that likely doesn't directly\n\u003e result in much additional fee income: once you know that pinning doesn't\n\u003e work, you just don't try it, which means there's no opportunity for\n\u003e miners to profit from a bidding war from the pinners counterparties\n\u003e repeatedly RBFing their preferred tx to get it mined.\n\u003e\n\u003e That also excludes second order risks: if you can't do zeroconf with BTC\n\u003e anymore, do you switch to ERC20 tokens, and then trade your BTC savings\n\u003e for ETH or USDT, and do enough people do that to lower the price of BTC?\n\u003e If investors see BTC being less used for payments, does that lower their\n\u003e confidence in bitcoin's future, and cause them to sell?\n\u003e\n\u003e \u003e Removing a\n\u003e \u003e quite-likely-incentive-compatible option from the software just\n\u003e encourages\n\u003e \u003e miners to adopt an additional patch\n\u003e\n\u003e Why shouldn't miners adopt an additional patch if they want some unusual\n\u003e functionality?\n\u003e\n\u003e Don't we want/expect miners to have the ability to change the code in\n\u003e meaningful ways, at a minimum to be able to cope with the scenario where\n\u003e core somehow gets coopted and releases bad code, or to be able to deal\n\u003e with the case where an emergency patch is needed?\n\u003e\n\u003e Is there any evidence miners even want this option? Peter suggested\n\u003e that some non-signalling replacements were being mined already [0], but\n\u003e as far as I can see [1] all of those are simply due to the transaction\n\u003e they replaced not having propagated in the first place (or having been\n\u003e evicted somehow? hard to tell without any data on the original tx).\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021012.html\n\u003e [1] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1292692367\n\u003e\n\u003e \u003e 2) Forcing miners to honor fees left on the table with respect to 0-conf,\n\u003e \u003e or forcing them to run a custom patchset to go around it, is a step\n\u003e \u003e backwards.\n\u003e\n\u003e As you already acknowledged, any miner that wants this behaviour can just\n\u003e pick up the patch (or could run Knots, which already has the feature\n\u003e enabled by default). It's simply false to say miners are being forced\n\u003e to do anything, no matter what we do here.\n\u003e\n\u003e If the direction you're facing is one where you're moving towards making\n\u003e life easier for people to commit fraud, and driving away businesses\n\u003e that aren't doing anyone harm, without achieving anything much else;\n\u003e then taking a step backwards seems like a sensible thing to do to me.\n\u003e\n\u003e (I remain optimistic about coming up with better RBF policy, and willing\n\u003e to be gung ho about everyone switching over to it even if it does kill\n\u003e off zeroconf, provided it actually does some good and we give people 6\n\u003e months or more notice that it's definitely happening and what exactly\n\u003e the new rules will be, though)\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/a1614798/attachment.html\u003e"}