email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-10 📝 Original message:> I read Antoine's ...
📅 Original date posted:2022-11-10
📝 Original message:> I read Antoine's original post on this and got the general gist, and
> here also, it makes sense, but I'd like to ask: is it necessary that
> (B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
> A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
> replace it
Is it actually true that they cannot replace it? If miners and node
operators collude and have the incentive to run a patched version of
core, is it still technically impossible to replace?
> the idea that they suffer financial loss from
> "ignorant" fee bumping is the part that seems weird to me.
Even if they waste resources trying to fee-bump, I agree that this does
not appear to be a catastrophe.There doesn't seem to be any technical
reason why improvements can't be made to allow B and C to have a better
view.
Cheers,
-Yancy
On 2022-11-08 10:28, AdamISZ via bitcoin-dev wrote:
> Hi aj and list,
> (questions inline)
>
> ------- Original Message -------
> On Thursday, October 27th, 2022 at 18:21, Anthony Towns via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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?
> <snip>
> I read Antoine's original post on this and got the general gist, and
> here also, it makes sense, but I'd like to ask: is it necessary that
> (B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
> A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
> replace it, but the idea that they suffer financial loss from
> "ignorant" fee bumping is the part that seems weird to me. Clearly
> TX_2 gets gossiped to other mempools; and understood that it does not
> replace the TX_1 (the 3-input) in B's mempool, say, but why should
> they not even hear about it? Is it just a matter of engineering, or is
> there some deeper problem with that.
>
> About this general flavour of attack, it's never been a *big* concern
> in Joinmarket imo (though, we did until recently have a bug that made
> this happen *by accident*, i.e. people double spending an input out of
> a negotiated join, albeit it was rare; but it's ofc definitely
> *possible* to 'grief' like this, given the ordering of events; maker
> sends signature, maker broadcasts double spend - 95% of the time they
> will be first). Interactive protocols are yucky and I think there'll
> always be griefing possibilities; designing around multiple-rounds of
> negotiation amongst not always-on participants is even more yucky, so
> just having a 'taker is in charge of network fee; if it's slow or gets
> double spent out causing time delay then just wait', combined with
> 'there really isn't any economic incentive for an attacker' (i.e.
> ignoring griefing) might sound crappy but it's probably just being
> realistic.
>
> Of course, off-chain contracting has more sophisticated considerations
> than this.
>
> Cheers,
> AdamISZ/waxwing
>
> _______________________________________________
> 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/20221110/ae20762b/attachment.html>;
📝 Original message:> I read Antoine's original post on this and got the general gist, and
> here also, it makes sense, but I'd like to ask: is it necessary that
> (B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
> A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
> replace it
Is it actually true that they cannot replace it? If miners and node
operators collude and have the incentive to run a patched version of
core, is it still technically impossible to replace?
> the idea that they suffer financial loss from
> "ignorant" fee bumping is the part that seems weird to me.
Even if they waste resources trying to fee-bump, I agree that this does
not appear to be a catastrophe.There doesn't seem to be any technical
reason why improvements can't be made to allow B and C to have a better
view.
Cheers,
-Yancy
On 2022-11-08 10:28, AdamISZ via bitcoin-dev wrote:
> Hi aj and list,
> (questions inline)
>
> ------- Original Message -------
> On Thursday, October 27th, 2022 at 18:21, Anthony Towns via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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?
> <snip>
> I read Antoine's original post on this and got the general gist, and
> here also, it makes sense, but I'd like to ask: is it necessary that
> (B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
> A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
> replace it, but the idea that they suffer financial loss from
> "ignorant" fee bumping is the part that seems weird to me. Clearly
> TX_2 gets gossiped to other mempools; and understood that it does not
> replace the TX_1 (the 3-input) in B's mempool, say, but why should
> they not even hear about it? Is it just a matter of engineering, or is
> there some deeper problem with that.
>
> About this general flavour of attack, it's never been a *big* concern
> in Joinmarket imo (though, we did until recently have a bug that made
> this happen *by accident*, i.e. people double spending an input out of
> a negotiated join, albeit it was rare; but it's ofc definitely
> *possible* to 'grief' like this, given the ordering of events; maker
> sends signature, maker broadcasts double spend - 95% of the time they
> will be first). Interactive protocols are yucky and I think there'll
> always be griefing possibilities; designing around multiple-rounds of
> negotiation amongst not always-on participants is even more yucky, so
> just having a 'taker is in charge of network fee; if it's slow or gets
> double spent out causing time delay then just wait', combined with
> 'there really isn't any economic incentive for an attacker' (i.e.
> ignoring griefing) might sound crappy but it's probably just being
> realistic.
>
> Of course, off-chain contracting has more sophisticated considerations
> than this.
>
> Cheers,
> AdamISZ/waxwing
>
> _______________________________________________
> 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/20221110/ae20762b/attachment.html>;