From: AdamISZ <AdamISZ@protonmail•com>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Tue, 08 Nov 2022 09:28:44 +0000 [thread overview]
Message-ID: <jzS-a7kpDwvAhO4TJiTgtpsP95Zi8BRvIgUqjOs3hEVI_Uu-ey1LfCnN2D8wkG21yfVPGIujbiDXCfFAyfW56gPtvd8p3SrsOmOE22IWAuA=@protonmail.com> (raw)
In-Reply-To: <Y1q+MedepB1qUpBP@erisian.com.au>
Hi aj and list,
(questions inline)
------- Original Message -------
On Thursday, October 27th, 2022 at 18:21, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Is that true? Antoine claims [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
next prev parent reply other threads:[~2022-11-08 9:29 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
2022-10-27 9:56 ` John Carvalho
2022-10-27 17:21 ` Anthony Towns
2022-10-27 17:35 ` Suhas Daftuar
2022-10-27 17:44 ` Greg Sanders
2022-10-27 19:00 ` Greg Sanders
2022-11-08 9:28 ` AdamISZ [this message]
2022-11-10 14:38 ` email
2022-11-03 21:06 email
2022-11-07 14:32 ` Peter Todd
2022-11-07 14:47 ` Erik Aronesty
2022-11-08 14:54 ` email
2022-11-09 12:05 ` email
-- strict thread matches above, loose matches on Subject: below --
2022-10-26 23:52 Anthony Towns
2022-10-27 12:36 ` Gloria Zhao
2022-10-27 15:37 ` Anthony Towns
2022-10-27 18:17 ` Luke Dashjr
2022-10-27 13:49 ` Greg Sanders
2022-10-27 15:00 ` Peter Todd
2022-10-27 20:29 ` Antoine Riard
2022-10-30 2:24 ` Anthony Towns
2022-10-29 7:45 ` David A. Harding
2022-10-30 1:02 ` Anthony Towns
2022-10-30 2:40 ` Anthony Towns
2022-10-30 11:06 ` email
2022-10-31 13:02 ` Suhas Daftuar
2022-10-31 16:25 ` Greg Sanders
2022-10-31 17:21 ` email
2022-10-31 17:51 ` Peter Todd
2022-11-04 10:28 ` email
2022-11-02 3:07 ` Anthony Towns
2022-11-02 13:32 ` Greg Sanders
2022-11-02 19:50 ` Antoine Riard
2022-11-05 2:35 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='jzS-a7kpDwvAhO4TJiTgtpsP95Zi8BRvIgUqjOs3hEVI_Uu-ey1LfCnN2D8wkG21yfVPGIujbiDXCfFAyfW56gPtvd8p3SrsOmOE22IWAuA=@protonmail.com' \
--to=adamisz@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox