Date: Thu, 06 Jul 2023 17:24:47 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Andrew Chow <lists@achow101.com>
Message-ID: <67c37967-ba7d-eabe-01e7-c5a0f9ca7da8@achow101.com>
In-Reply-To: <Ga2AELVMhRn2JlAC1-85LivVhcBhXzsf5ypHXMt_lg9RpwKTxeRxIRr8g8UHUihvxIVNKua6FIGRCjkt4CuNcDtZy2MetpOucpZYoKPW5sw=@protonmail.com>
References: <Ga2AELVMhRn2JlAC1-85LivVhcBhXzsf5ypHXMt_lg9RpwKTxeRxIRr8g8UHUihvxIVNKua6FIGRCjkt4CuNcDtZy2MetpOucpZYoKPW5sw=@protonmail.com>
Feedback-ID: 53660394:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Denial of Service using Package Relay
Precedence: list

On 07/06/2023 12:22 PM, alicexbt via bitcoin-dev wrote:
 > 1) Register input in A
 > 2) Double spend same input with zero fee to your own address
 > 3) Register unconfirmed UTXO from 2 in B

Why would unconfirmed inputs be accepted in a coinjoin? That seems=20
unsafe, regardless of package relay. The sender of the unconfirmed=20
transaction can already replace it thereby pinning or otherwise=20
invalidating the coinjoin, it doesn't need package relay.

Furthermore, the coordinator B shouldn't accept the unconfirmed UTXO=20
from 2 because it doesn't even know about that unconfirmed transaction.=20
It has zero fee, so it's not going to be relayed.

Conceivably a similar attack can already be done by simply registering=20
the same UTXO with multiple coordinators anyways. This doesn't require=20
package relay either.

***

Package relay should help coinjoins since any one of the participants=20
can rebroadcast the coinjoin with a further CPFP if the coinjoin is=20
below the minimum relay fee. Some of the upcoming package RBF proposals=20
should also help by allowing other child transactions in the package to=20
RBF the entire thing, thereby resolving the need to have everyone=20
re-sign the coinjoin in order to RBF.


Andrew