From: Suhas Daftuar <sdaftuar@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Thu, 27 Oct 2022 13:35:28 -0400 [thread overview]
Message-ID: <CAFp6fsHVdyK1xROa8jgq-cZFMrrXX-uZqkoNsS-C0B5AqG4KcA@mail.gmail.com> (raw)
In-Reply-To: <Y1q+MedepB1qUpBP@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]
I have more to say on this broader topic, but since you've brought up this
particular example I think it's worth commenting:
On Thu, Oct 27, 2022 at 1:23 PM 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?
>
I think this is not a real example of a DoS vector that is available
because we support non-rbf signaling transactions. Even in a world where
all transactions are replaceable, person A could double-spend their input
in a way that is annoying for B and C. For instance, the double-spend
could be low-feerate and large, and effectively pin any attempt to replace
it. Or it could be higher feerate and confirm and B/C have to start all
over. Or, A could stall things in the signing phase and B/C have to figure
out when to give up on the channel with A.
So I find this example to be unconvincing. Are there any other examples
where having a non-replacement policy for some transactions causes problems
for protocols people are trying to build?
Thanks,
Suhas
[-- Attachment #2: Type: text/html, Size: 3016 bytes --]
next prev parent reply other threads:[~2022-10-27 17:35 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 [this message]
2022-10-27 17:44 ` Greg Sanders
2022-10-27 19:00 ` Greg Sanders
2022-11-08 9:28 ` AdamISZ
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=CAFp6fsHVdyK1xROa8jgq-cZFMrrXX-uZqkoNsS-C0B5AqG4KcA@mail.gmail.com \
--to=sdaftuar@gmail$(echo .)com \
--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