diff options
| author | David A. Harding <dave@dtrt.org> | 2023-01-10 10:14:47 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-01-10 20:14:50 +0000 |
| commit | c6bac3781bb4244264cf5fc6d705d4a49a404f9a (patch) | |
| tree | 8e3cf839b5ae18a4555fecc5a670f2a05df4617d | |
| parent | 7c9f1b659f196acf0a1106eccfe309fcf2ad24f9 (diff) | |
| download | pi-bitcoindev-c6bac3781bb4244264cf5fc6d705d4a49a404f9a.tar.gz pi-bitcoindev-c6bac3781bb4244264cf5fc6d705d4a49a404f9a.zip | |
Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive
| -rw-r--r-- | dc/15ae5a2131327532b947933c5aa9c834816f1a | 114 |
1 files changed, 114 insertions, 0 deletions
diff --git a/dc/15ae5a2131327532b947933c5aa9c834816f1a b/dc/15ae5a2131327532b947933c5aa9c834816f1a new file mode 100644 index 000000000..2c8aa09e7 --- /dev/null +++ b/dc/15ae5a2131327532b947933c5aa9c834816f1a @@ -0,0 +1,114 @@ +Return-Path: <dave@dtrt.org> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id B51C6C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 10 Jan 2023 20:14:50 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 90BF760D73 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 10 Jan 2023 20:14:50 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 90BF760D73 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.902 +X-Spam-Level: +X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 3jMJ7Efw5NHv + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 10 Jan 2023 20:14:50 +0000 (UTC) +X-Greylist: delayed 10:12:11 by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F39F860AF2 +Received: from smtpauth.rollernet.us (smtpauth.rollernet.us + [IPv6:2607:fe70:0:3::d]) + by smtp3.osuosl.org (Postfix) with ESMTPS id F39F860AF2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 10 Jan 2023 20:14:49 +0000 (UTC) +Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) + by smtpauth.rollernet.us (Postfix) with ESMTP id C68662800040; + Tue, 10 Jan 2023 12:14:47 -0800 (PST) +Received: from webmail.rollernet.us (webmail.rollernet.us + [IPv6:2607:fe70:0:14::a]) + (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) + (Client did not present a certificate) + by smtpauth.rollernet.us (Postfix) with ESMTPSA; + Tue, 10 Jan 2023 12:14:47 -0800 (PST) +MIME-Version: 1.0 +Date: Tue, 10 Jan 2023 10:14:47 -1000 +From: "David A. Harding" <dave@dtrt.org> +To: Peter Todd <pete@petertodd.org> +In-Reply-To: <Y704non5DD5mtxs1@petertodd.org> +References: <Y7ySzDjzx5eDjOH9@petertodd.org> + <aaaeda2950e61127a3218c523927a0d8@dtrt.org> <Y70mNHsX4JcKYZyi@petertodd.org> + <6089e1f0140684435bf5e87b0c13d561@dtrt.org> <Y704non5DD5mtxs1@petertodd.org> +User-Agent: Roundcube Webmail/1.4.10 +Message-ID: <6cebd312ca960e634729cc574c2e97b0@dtrt.org> +X-Sender: dave@dtrt.org +Content-Type: text/plain; charset=US-ASCII; + format=flowed +Content-Transfer-Encoding: 7bit +X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy: + http://www.rollernet.us/policy +X-Rollernet-Submit: Submit ID 6b33.63bdc737.4ee4b.0 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty + Protocols Significantly More Expensive +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 10 Jan 2023 20:14:50 -0000 + +On 2023-01-10 00:06, Peter Todd wrote: +> Remember, we'd like decentralized coinjoin implementations like +> Joinmarket to +> work. How does a decentralized coinjoin implement "conflict +> monitoring"? + +1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core + with -debug=mempoolrej will tell you when it rejects a transaction + for conflicting with a transaction already in the mempool, e.g.: + + 2022-11-01T02:53:17Z +867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from +peer=58 was not accepted: txn-mempool-conflict + + I think it would be easy to extend this facility to list the inputs + which conflicted. So if Alice sees a conflict created by Mallory, + she can create a new coinjoin transaction without Mallory. This + method has the advantage of being fast and attributing fault, + although it does require Alice's node be online at the time Mallory's + conflict is propagated. + +2. Simply assume a conflict exists for otherwise unexplainable failures. + For example, if Alice sees several new blocks whose bottom feerates + are well below the feerates of an unconfirmed coinjoin transaction + that Alice helped create and broadcast, she can assume it's a + conflict that is preventing preventing confirmation of the coinjoin. + She can find an entirely different set of collaborators and create a + non-conflicting transaction without ever needing to know which inputs + from the original transaction conflicted. This method has the + disadvantage of being slow (on the order of hours) and not +attributing + fault, although it doesn't require Alice has any information beyond +copies + of recent blocks. + +I didn't list these methods or others before because the specific method +used to +detect conflicts doesn't matter to the realization that software which +uses conflict detection and evasion to defeat the $17.00 attack also +defeats the $0.05 attack without any need for full-RBF. + +-Dave + |