diff options
author | Antoine Riard <antoine.riard@gmail.com> | 2022-12-02 17:35:39 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-12-02 22:35:53 +0000 |
commit | 95d8b7703d5e9c39b8a30c819ea174280bbc1a50 (patch) | |
tree | c33dd8531434e96bb9a27c47adc69708618c8222 | |
parent | b5e95cc315217730b9712057091275b1de82b766 (diff) | |
download | pi-bitcoindev-95d8b7703d5e9c39b8a30c819ea174280bbc1a50.tar.gz pi-bitcoindev-95d8b7703d5e9c39b8a30c819ea174280bbc1a50.zip |
[bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger
-rw-r--r-- | 74/a9bbac58bd7cf4b2cf20de920c9e0993503966 | 197 |
1 files changed, 197 insertions, 0 deletions
diff --git a/74/a9bbac58bd7cf4b2cf20de920c9e0993503966 b/74/a9bbac58bd7cf4b2cf20de920c9e0993503966 new file mode 100644 index 000000000..d330fe649 --- /dev/null +++ b/74/a9bbac58bd7cf4b2cf20de920c9e0993503966 @@ -0,0 +1,197 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 21B06C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Dec 2022 22:35:53 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id E9E5B60E4E + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Dec 2022 22:35:52 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E9E5B60E4E +Authentication-Results: smtp3.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20210112 header.b=Btr9vKsS +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 38AhWFmMB4M0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Dec 2022 22:35:52 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CFC0960B1C +Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com + [IPv6:2607:f8b0:4864:20::12f]) + by smtp3.osuosl.org (Postfix) with ESMTPS id CFC0960B1C + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Dec 2022 22:35:51 +0000 (UTC) +Received: by mail-il1-x12f.google.com with SMTP id y2so882434ily.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 02 Dec 2022 14:35:51 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=to:subject:message-id:date:from:in-reply-to:references:mime-version + :from:to:cc:subject:date:message-id:reply-to; + bh=GnSeO2741N5KztyjbDvdTJSXh+zxowPAzmK4ViImaXI=; + b=Btr9vKsSkSSyVBFA4tw+dB8hG4ZGzR5Ny7ryl3upOCEUuOwjAHAxQr4pAJkrj49upQ + 8MeHlaLcWVhW9PFc/nD3PWp2KarFLrRftVQzIzfkLvW/w4UvU2g8mARsxkzVP1itsq3k + AesoDPf9iEdEkT3xptFMGvs/sYfIaf3OCaDv09NSF8E2Qzt8zE3XJlQvE6BOdDCB6jjp + D1D0Vb1nJ3XqOf/KOaYYzZ30Txylz6Ex7DwXDx19n1+jwMko2yaThd/kTR1D1D6fY5bK + HjFM7mngM4/SE0jYCEFj3KqzBeE725smsS+7207NxrMdnv9bfKozDPytOqFYsjxwEEa2 + P+Lg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=to:subject:message-id:date:from:in-reply-to:references:mime-version + :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; + bh=GnSeO2741N5KztyjbDvdTJSXh+zxowPAzmK4ViImaXI=; + b=sN+2YC2BKF/oojB/S9VNSCZ/UcDm7n7qaHFKP3JozEbbNlYnJDI1pRo5ij5My5iPAh + cIce+OGBfnld4tNP/WF9v1WPQxseUpeAL9KEw432Mdy3ks4cxsQqQtwTxOaSQAalaaBq + mTzE9f/qrrJkCpLErlKOSxPN7uWx/To2Qem98JVACkza7m2cwFqRJ8H2i8FWaUcd0Y4K + BMVqnErdiqzsLBTIk3cjExApcGJ9KmUunsRzji4sEdp6q9LWP5RoRrT41mwyYv2OcfzF + 5NX+x+vYYC8+/7ZOXy8nGoJezt51ubAvxvsY7ABBVGkNepoEREADpFifkNR4iQJaHyfD + PPSQ== +X-Gm-Message-State: ANoB5pl2VyT1YdLkdocaODtskCkd+2WC2ban73X9TSL2BkQwTJua60O0 + wDhX4z2OcNdJa/yHzU2FOpqE9FHw+/whi+N5yepxWaZP +X-Google-Smtp-Source: AA0mqf6DMuk15mFA51pWFfgfHXvuWIuh4bCs9RZ1rRVKIQNfiShkt4yYsQlEkAVOni2XUsxHkncOWUFj8Qo1hRi2QAM= +X-Received: by 2002:a05:6e02:505:b0:303:148c:692c with SMTP id + d5-20020a056e02050500b00303148c692cmr12895262ils.114.1670020550610; Fri, 02 + Dec 2022 14:35:50 -0800 (PST) +MIME-Version: 1.0 +References: <CACkWPs8-rZpGSJSEyLsg9gVAuPpHztXWSZvfGscGJCn05th0DQ@mail.gmail.com> + <CALZpt+GnTE+LMSMHVt-E7Uq0FeuqrSKyr1m9OJa_yKkh6MrgzA@mail.gmail.com> +In-Reply-To: <CALZpt+GnTE+LMSMHVt-E7Uq0FeuqrSKyr1m9OJa_yKkh6MrgzA@mail.gmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Fri, 2 Dec 2022 17:35:39 -0500 +Message-ID: <CALZpt+HFFwY4XECNZj3XLqnaumPeDjrwvnCsRa3vsGQfuXn8wA@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000afd5b705eedff5d1" +X-Mailman-Approved-At: Sat, 03 Dec 2022 00:19:46 +0000 +Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate + danger +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: Fri, 02 Dec 2022 22:35:53 -0000 + +--000000000000afd5b705eedff5d1 +Content-Type: text/plain; charset="UTF-8" + +Hi Daniel, + +From my understanding of GAP600, you're operating a zero-conf risk analysis +business, which is integrated and leveraged by payment processors/liquidity +providers and merchants. A deployment of fullrbf by enough full-node +operators and a subset of the mining hashrate would lower the cost of +double-spend attack by lamda users, therefore increasing the risk exposure +of your users. This increased risk exposure could lead you to alter the +acceptance of incoming zero-conf transactions, AFAICT in a similar +reasoning as exposed by Bitrefill earlier this year [0]. + +About the statistics you're asking for considerations, few further +questions, on those 1.5M transactions per month, a) how many are +Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many +are excluded from zeroconf due to factors like RBF, long-chain of +unconfirmed ancestors or too high-value and c) what has been the average +feerate (assuming a standard size of 200 bytes) ? + +My personal position on fullrbf is still the same as expressed in #26525 +[1]. As a community, I think we still don't have conceptual consensus on +deploying full-rbf, nor to remove it. In the direction of removing the +current option from Bitcoin Core, I think the prerequisite to address are +the qualification of enough economic flows at risk and the presence of a +sizable loss in miners income. Beyond that, I think there is still the open +question if we (we, as the Bitcoin protocol development community, with all +its stakeholders) should restrain user choice in policy settings in the +name of preserving mining income and established use-case stability. + +To recall, the original technical motivation of this option, and the wider +smoother deployment was to address a DoS vector affecting another class of +use-case: multi-party transactions like coinjoin and contracting protocols +like Lightning [2] [3]. All of them expect to generate economic flows and +corresponding mining income. Since then, alternative paths to solve this +DoS vector have been devised, all with their own trade-offs and conceptual +issues [4] [5]. + +Best, +Antoine + +[0] +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html +[1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006 +[2] +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html +[3] +https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html +[4] +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html +[5] +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html + +--000000000000afd5b705eedff5d1 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Daniel,<br><div class=3D"gmail_quote"><div dir=3D"ltr">= +<br>From my understanding of GAP600, you're operating a zero-conf risk = +analysis business, which is integrated and leveraged by payment processors/= +liquidity providers and merchants. A deployment of fullrbf by enough full-n= +ode operators and a subset of the mining hashrate would lower the cost of d= +ouble-spend attack by lamda users, therefore increasing the risk exposure o= +f your users. This increased risk exposure could lead you to alter the acce= +ptance of incoming zero-conf transactions, AFAICT in a similar reasoning as= + exposed by Bitrefill earlier this year [0].<br><br>About the statistics yo= +u're asking for considerations, few further questions, on those 1.5M tr= +ansactions per month, a) how many are Bitcoin-only (as I understand to be m= +ulti-cryptocurrencies), b) how many are excluded from zeroconf due to facto= +rs like RBF, long-chain of unconfirmed ancestors or too high-value and c) w= +hat has been the average feerate (assuming a standard size of 200 bytes) ?<= +br><br>My personal position on fullrbf is still the same as expressed in #2= +6525 [1]. As a community, I think we still don't have conceptual consen= +sus on deploying full-rbf, nor to remove it. In the direction of removing t= +he current option from Bitcoin Core, I think the prerequisite to address ar= +e the qualification of enough economic flows at risk and the presence of a = +sizable loss in miners income. Beyond that, I think there is still the open= + question if we (we, as the Bitcoin protocol development community, with al= +l its stakeholders) should restrain user choice in policy settings in the n= +ame of preserving mining income and established use-case stability.<br><br>= +To recall, the original technical motivation of this option, and the wider = +smoother deployment was to address a DoS vector affecting another class of = +use-case: multi-party transactions like coinjoin and contracting protocols = +like Lightning [2] [3]. All of them expect to generate economic flows and c= +orresponding mining income. Since then, alternative paths to solve this DoS= + vector have been devised, all with their own trade-offs and conceptual iss= +ues [4] [5].<br><br>Best,<br>Antoine<br><br>[0] <a href=3D"https://lists.li= +nuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html" target=3D= +"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Octob= +er/021070.html</a><br>[1] <a href=3D"https://github.com/bitcoin/bitcoin/pul= +l/26525#issuecomment-1319499006" target=3D"_blank">https://github.com/bitco= +in/bitcoin/pull/26525#issuecomment-1319499006</a><br>[2] <a href=3D"https:/= +/lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html" tar= +get=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022= +-June/020557.html</a><br>[3] <a href=3D"https://lists.linuxfoundation.org/p= +ipermail/lightning-dev/2021-May/003033.html" target=3D"_blank">https://list= +s.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html</a><br>[= +4] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-= +October/021135.html" target=3D"_blank">https://lists.linuxfoundation.org/pi= +permail/bitcoin-dev/2022-October/021135.html</a><br>[5] <a href=3D"https://= +lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html" = +target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2= +022-November/021144.html</a><br></div> +</div></div> + +--000000000000afd5b705eedff5d1-- + |