rich1.0npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mhttps://nostr.ae/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mnjumphttps://nostr.ae📅 Original date posted:2022-11-02 📝 Original message:> 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. To be clear, a pinner is attempting to *not* pay the most fees, by definition. If we're somehow sure something is a pin, we should not allow it, because miners rationally do not want it vs an "honest" bid for fees. V3 design is one attempt to carve out a safe space for fee bidding. Carving out a safe space for *non-bidding* is not the same thing. I think this mostly boils down having knobs or not. I'm fine with knobs with paternalistic defaults, especially when a non-zero percentage of users disagree with a value in either direction. Greg On Tue, Nov 1, 2022 at 11:07 PM Anthony Towns <aj at erisian.com.au> wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221102/a1614798/attachment.html>