email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-03 📝 Original message:AJ/Antoine et al > What ...
📅 Original date posted:2022-11-03
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/bccd03d2/attachment-0001.html>;
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/bccd03d2/attachment-0001.html>;