Re: [bitcoin-dev] On mempool policy consistency

From: email@yancy•lol
To: Anthony Towns <aj@erisian•com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Thu, 03 Nov 2022 22:06:52 +0100	[thread overview]
Message-ID: <16eb6a50691ccc661310051de6b8e2c0@yancy.lol> (raw)

[-- Attachment #1: Type: text/plain, Size: 6033 bytes --]

AJ/Antoine et al

> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> solve that problem if they have only opt-in RBF available?

Assuming Alice is a well funded advisory, with enough resources to spam 
the network so that enough nodes see her malicious transaction first, 
how does full-rbf solve this vs. opt-in rbf?

Cheers,
-Yancy

On 2022-10-27 19:21, Anthony Towns via bitcoin-dev wrote:

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

Links:
------
[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

[-- Attachment #2: Type: text/html, Size: 8609 bytes --]