📅 Original date posted:2022-06-27 📝 Original message:One key difference seems ...

Greg Sanders [ARCHIVE] /

npub1jdl…gh0m

2023-06-07 23:10:36

in reply to nevent1q…z06a

📅 Original date posted:2022-06-27
📝 Original message:One key difference seems to be that properly punishing someone based on
mempool behavior seems much more difficult. As we all know there is no "the
mempool".

On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220627/ce7724b1/attachment.html>;

Author Public Key

npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m

Show more details

Published at

2023-06-07 23:10:36

Kind type

1 Short Text Note

Event JSON

{ "id": "fee114f11d56eee6110373a7e8be55bcbffa094478197a09e92087f5fb4d6202", "pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19", "created_at": 1686179436, "kind": 1, "tags": [ [ "e", "c4c47bc914f0c42e62e9231ba057f951f67ec503b437e68c623daa5b647e2b0e", "", "root" ], [ "e", "b24a7936372195d8cd7c4a67da39b2dc9346b07a9613d609f5144ac598c6f096", "", "reply" ], [ "p", "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa" ] ], "content": "📅 Original date posted:2022-06-27\n📝 Original message:One key difference seems to be that properly punishing someone based on\nmempool behavior seems much more difficult. As we all know there is no \"the\nmempool\".\n\n\n\nOn Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:\n\u003e \u003e Hi Antoine,\n\u003e \u003e\n\u003e \u003e Thanks for sharing the DoS attack example with alternatives.\n\u003e \u003e\n\u003e \u003e \u003e - Caroll broadcasts a double-spend of her own input C, the\n\u003e double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal\n\u003e opt-in RBF\n\u003e \u003e \u003e - Alice broadcasts the multi-party transaction, it is rejected by the\n\u003e network mempools because Alice double-spend is already present\n\u003e \u003e\n\u003e \u003e I think this affects almost all types of coinjoin transaction including\n\u003e coordinator based implementations. I tried a few things and have already\n\u003e reported details for an example DoS attack to one of the team but there is\n\u003e no response yet.\n\u003e \u003e\n\u003e \u003e It was fun playing with RBF, DoS and Coinjoin. Affected projects should\n\u003e share their opinion about full-rbf as it seems it might improve things.\n\u003e \u003e\n\u003e \u003e Example:\n\u003e \u003e\n\u003e \u003e In Wasabi an attacker can broadcast a transaction spending input used in\n\u003e coinjoin after sending signature in the round. This would result in a\n\u003e coinjoin tx which never gets relayed:\n\u003e https://nitter.net/1440000bytes/status/1540727534093905920\n\u003e\n\u003e Note that Wasabi already has a DoS attack vector in that a participant can\n\u003e stop\n\u003e participating after the first phase of the round, with the result that the\n\u003e coinjoin fails. Wasabi mitigates that by punishing participating in future\n\u003e rounds. Double-spends only create additional types of DoS attack that need\n\u003e to\n\u003e be detected and punished as well - they don't create a fundamentally new\n\u003e vulerability.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220627/ce7724b1/attachment.html\u003e", "sig": "614b0f4bb33fd29f8b63ce5dae72c9df187e0399dd067478defe1981189e2018acdbf20de22531df847d102f46cdeaf9a1c18149246b961012bb299ba1391e75" }