summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAntoine Riard <antoine.riard@gmail.com>2022-12-02 17:35:39 -0500
committerbitcoindev <bitcoindev@gnusha.org>2022-12-02 22:35:53 +0000
commit95d8b7703d5e9c39b8a30c819ea174280bbc1a50 (patch)
treec33dd8531434e96bb9a27c47adc69708618c8222
parentb5e95cc315217730b9712057091275b1de82b766 (diff)
downloadpi-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/a9bbac58bd7cf4b2cf20de920c9e0993503966197
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&#39;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&#39;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&#39;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--
+