<unnamed>

Public Key

npub1h3rwn9t2waw3awmlrf3vgdkeqlknnl4fv9k40035gaxhhr5xscuqc77mc5

Profile Code

nprofile1qqstc3hfj448whg7hdl35ckyxmvs0mfel65kzm2hhc6ywntm36rgvwqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszz8gcx

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:17:30 CEST

- reply

📅 Original date posted:2022-12-09
📝 Original message:I think the fundamental disagreement here that's causing the controversy and impasse is this:
Those in favour of Full RBF see trusting and relying on predictable mempool policy as a fundamentally flawed bad idea. Node policy is not a consensus rule - a miner has always been allowed to produce a block in the way a Full RBF node now would. An otherwise valid block that contains a tx that your not-full-RBF node ignored because it double-spent an earlier lower fee tx that didn't opt in to RBF is still a valid block. Knowing this, we conclude that it doesn't matter how useful or widely used Zero Conf is, it is fundamentally unsafe and should be actively discouraged, and changing mempool policy is a way to do this. The existence of Lightning as an alternative for immediate settlement makes this case stronger.
(As I see it) those that oppose Full RBF and want Zero Conf use to continue argue that node mempool policy can and has been relied upon for a long time already, and argue (rightly) that Zero Conf acceptance is already widely used and useful for both customers and merchants. Further arguing that Full RBF can be sucessfully unshipped, which requires that majority of node operators don't particularly care about it. Lastly, that neither miners nor users have an economic incentive to switch to Full RBF from the current core First-Seen policy. (Am I missing something else?)
---
I have sympathy for the utility argument, but to me it's completely overpowered by the "node policy is not consensus and not trustworthy" argument. Zero Conf acceptance rests on trusting that nodes are running with a first-seen policy. Just because this has worked out OK so far, doesn't mean that you won't get got bigtime in the future. You can accept this risk if you want to, but it shouldn't be a soft-rule that everyone else running a node should please help reduce that risk for you.
Sure, if I'm selling something on eBay or whatever for 100k sats and someone wants to pay in BTC in person, I'll accept with zero confirmations because there's a degree of trust and the risk isn't unbearable. If I'm accepting BTC as a company though, no, I'm not considering zero-confirmation transactions as settled.
I don't think the economic incentive argument currently matters all that much - miners want to maximise fees, users want to minimise, it's hard to tell which policy would have the higher overall fees for miners, and who wins miners-vs-users. This would also seem to depend on how wallets do or don't make use of the new RBF option (particularly hard for multisig). There is still an obvious incentive for someone to double-spend attack a Zero-Conf merchant, though.
I could be convinced to reverse my stance and oppose Full RBF if there was a strong economic argument that miners (better still, miners and users) should oppose it, because that would imply first-seen is incentive aligned. Aligning policy with incentives feels like the correct principle.
But for now, I want to run a Full RBF node because I see it as ultimately making Bitcoin stronger. It eliminates a use-case that takes risk. Accepting Zero Conf changes from "hrm, you shouldn't really do that but it works most of the time" to "no, really don't do that, you will probably lose money". Perhaps this is actually somewhat "vindictive, and perverse" as John said, but Bitcoin is money for enemies.
Thanks,
Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221209/12161097/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221209/12161097/attachment-0001.sig>