Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 21B06C0032 for ; 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 ; 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 ; 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 ; Fri, 2 Dec 2022 22:35:51 +0000 (UTC) Received: by mail-il1-x12f.google.com with SMTP id y2so882434ily.5 for ; 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: In-Reply-To: From: Antoine Riard Date: Fri, 2 Dec 2022 17:35:39 -0500 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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-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].

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>
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.

= 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].

Best,
Antoine

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Octob= er/021070.html
[1] https://github.com/bitco= in/bitcoin/pull/26525#issuecomment-1319499006
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022= -June/020557.html
[3] https://list= s.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[= 4] https://lists.linuxfoundation.org/pi= permail/bitcoin-dev/2022-October/021135.html
[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2= 022-November/021144.html
--000000000000afd5b705eedff5d1--