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