{"type":"rich","version":"1.0","author_name":"npub1r8mnta5rneza3ujqtckuz6m8es0mvvzq35ec7v4nz3lq99l3wzlsrtu3an","author_url":"https://nostr.ae/npub1r8mnta5rneza3ujqtckuz6m8es0mvvzq35ec7v4nz3lq99l3wzlsrtu3an","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-11-03\n📝 Original message:AJ/Antoine et al\n\n\u003e What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to\n\u003e solve that problem if they have only opt-in RBF available?\n\nAssuming Alice is a well funded advisory, with enough resources to spam \nthe network so that enough nodes see her malicious transaction first, \nhow does full-rbf solve this vs. opt-in rbf?\n\nCheers,\n-Yancy\n\nOn 2022-10-27 19:21, Anthony Towns via bitcoin-dev wrote:\n\n\u003e On Thu, Oct 27, 2022 at 11:56:45AM +0200, John Carvalho via bitcoin-dev \n\u003e wrote:\n\u003e \n\u003e\u003e I took the time to read your whole post. Despite a diplomatic tone, I \n\u003e\u003e find\n\u003e\u003e your takeaways from all your references to remain conveniently biased \n\u003e\u003e for\n\u003e\u003e protecting the plan of RBF\n\u003e \n\u003e Yes, I am heavily biased against zeroconf: there's no way I'd \n\u003e personally\n\u003e be willing to trust it for my own incoming funds, no matter how much\n\u003e evidence you show me that it's safe in practice. Show me a million\n\u003e transactions where every single one worked fine, and I'm still going to\n\u003e assume that the payment going to me is going to be the one that makes\n\u003e the error rate tick up from 0% to 0.0001%. That's okay; just because I\n\u003e wouldn't do something, doesn't mean other people shouldn't.\n\u003e \n\u003e It does mean I'm not going to be a particularly good advocate for \n\u003e zeroconf\n\u003e though. I mean, I might still be a fine advocate for giving people time\n\u003e to react, making it clear what's going on, finding ways that might make\n\u003e everyone happy, or just digging it to random technical details; but,\n\u003e for me, I'm more interested in a world where chargebacks are \n\u003e impossible,\n\u003e not where we just make the best of what was possible with technology\n\u003e from five or ten years ago.\n\u003e \n\u003e But that's fine: it just means that people, like yourself, who will\n\u003e tolerate the risks of zeroconf, should be involved in the discussion.\n\u003e \n\u003e\u003e You show multiple examples where, when I read them, I assume the next \n\u003e\u003e thing\n\u003e\u003e you will say will be \"so we really should stop trying to impose \n\u003e\u003e optional\n\u003e\u003e features, particularly when they affect existing use cases\" but \n\u003e\u003e instead you\n\u003e\u003e persist.\n\u003e \n\u003e Sure, that's natural: you read a sign saying \"you can have any ice \n\u003e cream\n\u003e you want for 5c\" and think \"Awesome, who wouldn't want cheap chocolate\n\u003e ice cream!!\" and see me going for a Golden Gaytime and think \"wtf \n\u003e dude\".\n\u003e Different strokes.\n\u003e \n\u003e For me, I see the gmaxwell github comment I quoted saying:\n\u003e \n\u003e There is also a matter of driving competent design rather than lazy\n\u003e first thing that works.\n\u003e \n\u003e and think \"yeah, okay, maybe we should be working harder to push \n\u003e lightning\n\u003e adoption, rather than letting people stick with wallet UX from 2015\"\n\u003e and have altcoins take over \u003e50% of payment volume.\n\u003e \n\u003e Likewise,\n\u003e \n\u003e There is also a very clear pattern we've seen in the past where\n\u003e people take anything the system lets them do as strong evidence that\n\u003e they have a irrevocable right to use the system in that way, and that\n\u003e their only responsibility-- and if their usage harms the system it's\n\u003e the responsibility of the system to not permit it.\n\u003e \n\u003e seems a pretty good match against your claim \"I expect the things I do\n\u003e with Bitcoin today to work FOREVER.\" Better to nip that thinking in the\n\u003e bud; and even if the best time to do that was years ago, the second \n\u003e best\n\u003e time to do it is still now.\n\u003e \n\u003e By contrast, from the same post, I'd guess you're focussing on:\n\u003e \n\u003e Network behavior is one of the few bits of friction\n\u003e driving good technical design rather than \"move fast, break things, and\n\u003e force everyone else onto my way of doing thing rather than discussing\n\u003e the design in public\".\n\u003e \n\u003e and thinking \"yeah, move fast, break things, force everyone else --\n\u003e that's exactly what's going on here, and shouldn't be\".\n\u003e \n\u003e But that's also okay: even when there is common ground to be found,\n\u003e sometimes it requires actual work to get people who start from \n\u003e different\n\u003e views to get there.\n\u003e \n\u003e\u003e The problem is that RBF has already been an option for years, and \n\u003e\u003e anyone\n\u003e\u003e that wants to use it can.\n\u003e \n\u003e Is that true? Antoine claims [1 [1]] that opt-in RBF isn't enough to \n\u003e avoid\n\u003e a DoS issue when utxos are jointly funded by untrusting partners, and,\n\u003e aiui, that's the main motivation for addressing this now.\n\u003e \n\u003e [1] \n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e \n\u003e The scenario he describes is: A, B, C create a tx:\n\u003e \n\u003e inputs: A1, B1, C1 [opts in to RBF]\n\u003e fees: normal\n\u003e outputs:\n\u003e [lightning channel, DLC, etc, who knows]\n\u003e \n\u003e they all analyse the tx, and agree it looks great; however just before\n\u003e publishing it, A spams the network with an alternative tx, double\n\u003e spending her input:\n\u003e \n\u003e inputs: A1 [does not opt in to RBF]\n\u003e fees: low\n\u003e outputs: A\n\u003e \n\u003e If A gets the timing right, that's bad for B and C because they've\n\u003e populated their mempool with the 1st transaction, while everyone else\n\u003e sees the 2nd one instead; and neither tx will replace the other. B and\n\u003e C can't know that they should just cancel their transaction, eg:\n\u003e \n\u003e inputs: B1, C1 [opts in to RBF]\n\u003e fees: 50% above normal\n\u003e outputs:\n\u003e [smaller channel, refund, whatever]\n\u003e \n\u003e and might instead waste time trying to fee bump the tx to get it mined,\n\u003e or similar.\n\u003e \n\u003e What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to\n\u003e solve that problem if they have only opt-in RBF available?\n\u003e \n\u003e If you're right that opt-in RBF is enough, that question has a good\n\u003e answer. I don't believe anyone's presented an answer to it in the 17\n\u003e months since Antoine raised the concern.\n\u003e \n\u003e\u003e passive aggression\n\u003e\u003e escalation\n\u003e\u003e unfair advantage\n\u003e\u003e oppressive, dark-pattern design\n\u003e\u003e strong-arming and shoe-horning\n\u003e \n\u003e Do you really think any of that was helping your cause?\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n\nLinks:\n------\n[1] \nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/bccd03d2/attachment-0001.html\u003e"}