alicexbt [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-05 📝 Original message:Hi Peter, > Note that ...
📅 Original date posted:2022-07-05
📝 Original message:Hi Peter,
> Note that Wasabi already has a DoS attack vector in that a participant can stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast.
Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users?
/dev/fd0
Sent with Proton Mail secure email.
------- Original Message -------
On Monday, June 27th, 2022 at 12:43 AM, Peter Todd <pete at petertodd.org> wrote:
> On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
>
> > Hi Antoine,
> >
> > Thanks for sharing the DoS attack example with alternatives.
> >
> > > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does not signal opt-in RBF
> > > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
> >
> > I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.
> >
> > It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.
> >
> > Example:
> >
> > In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920
>
>
> Note that Wasabi already has a DoS attack vector in that a participant can stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
📝 Original message:Hi Peter,
> Note that Wasabi already has a DoS attack vector in that a participant can stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast.
Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users?
/dev/fd0
Sent with Proton Mail secure email.
------- Original Message -------
On Monday, June 27th, 2022 at 12:43 AM, Peter Todd <pete at petertodd.org> wrote:
> On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
>
> > Hi Antoine,
> >
> > Thanks for sharing the DoS attack example with alternatives.
> >
> > > - Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does not signal opt-in RBF
> > > - Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice double-spend is already present
> >
> > I think this affects almost all types of coinjoin transaction including coordinator based implementations. I tried a few things and have already reported details for an example DoS attack to one of the team but there is no response yet.
> >
> > It was fun playing with RBF, DoS and Coinjoin. Affected projects should share their opinion about full-rbf as it seems it might improve things.
> >
> > Example:
> >
> > In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920
>
>
> Note that Wasabi already has a DoS attack vector in that a participant can stop
> participating after the first phase of the round, with the result that the
> coinjoin fails. Wasabi mitigates that by punishing participating in future
> rounds. Double-spends only create additional types of DoS attack that need to
> be detected and punished as well - they don't create a fundamentally new
> vulerability.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org