Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 38AFBC002D for ; Fri, 2 Dec 2022 06:59:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 04E2F600D4 for ; Fri, 2 Dec 2022 06:59:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 04E2F600D4 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com header.a=rsa-sha256 header.s=google header.b=aFK85msa X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 J97vVtnOeEMK for ; Fri, 2 Dec 2022 06:59:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 525E5606A0 Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) by smtp3.osuosl.org (Postfix) with ESMTPS id 525E5606A0 for ; Fri, 2 Dec 2022 06:59:13 +0000 (UTC) Received: by mail-vs1-xe29.google.com with SMTP id t10so3637661vsa.5 for ; Thu, 01 Dec 2022 22:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dYQ60eIGCDanTXnb6O7BrgrE1FAQxtgsQcgRqkiqoBo=; b=aFK85msafEbskOpdwOF3fsb+4eEvHb7iGB5fkwe2lWRqRYOHRP/sVE66A/wykVCLW+ Bet5xmsoVVgBe0Ziie5pUZ5KMSRXe7qZBMlYIjJLVRQMB8IJzw6pXTrid2UhrJTLeVJs 3DkeIjjvdC8IZpuLsZS7+UDIFERrYAaewRLxw2YoscnxloNJFeVc6Kpf01XzSLlFvwqh tsxzHwxnFgs2YVQKbb/YzI540cyZRf+JNPZPJDgNAlOMF56hy+USQd2CuNWau5tO3dn0 jM0QmnmON8nx6Apq6zkfl+7Q1GHqnJZLmTjZymawJmGqElu4EHlc6MDVoVH0G0QYA3x3 nApQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=dYQ60eIGCDanTXnb6O7BrgrE1FAQxtgsQcgRqkiqoBo=; b=4LOEQnu2kZUkw+lYCU5KynmdvPhs3XQnVDIhysQVooO88QyLDsBn3JCOwIUoiIdrd0 +FWP9M9TMtSZ0NKlRC/MOLfd8xhqcAtQPbRxrEnRyaox1xPy5NUfXVN1ESTDPFu7PWl0 jnxryimTa1Z8/khycTLk/ZJBlYSEsUikTHZsoefb+iTiQmQoCxiEL1nZUJTzDg4vsq5J vPqhr+ureemJ3p0Yz4DkQsSAFIHXYQdrgXinjBSNXXLYkugAgJd1uUJBZiuMZE2O97bd KTBOeTs7zO695MlQrPUZqMWYCVcNUEw+npmBON2dz1bLf/f9ZzDFr+opbtGufUlAHGkj hrfg== X-Gm-Message-State: ANoB5pmh55v8suWcfZ/9n1WPzKQwUU3xa+tN7L+H+Pcj+/t/DMSGVAvm ecIrYQds/ta2uXsCxg+8jDcmnPDpQaCohrfV+0c0bmSOVEF+t9IH X-Google-Smtp-Source: AA0mqf7eiixKQoVLnubvwsnNKlyPL35W2r3UEIYl95usU6DB7VTdEPvBpZ2CGAMn05YwxZG4+yuLftknrbbJJh37fck= X-Received: by 2002:a67:6504:0:b0:3b0:b7dd:4d0a with SMTP id z4-20020a676504000000b003b0b7dd4d0amr10218210vsb.17.1669964351995; Thu, 01 Dec 2022 22:59:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Lipshitz Date: Fri, 2 Dec 2022 08:59:01 +0200 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="000000000000fd147805eed2dfa5" X-Mailman-Approved-At: Sat, 03 Dec 2022 00:19:46 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [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 06:59:15 -0000 --000000000000fd147805eed2dfa5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Antoine Thank you for all the references - I agree with Sergej statement "opportunity makes the thief" The 1.5M trxs are all BTC which our clients query, I dont have specifics for those trxs i.e. reasons for not being confirmed. However we target to achieve +90% confirmation of trxs for our clients. Fee rates the transactions generally follow standard fee/rate policy similar to all industry recommendations, we recommend higher priority fee rate but approve trxs well below that level. I would say we havent seen a trx with medium fee rate be double spend - this is excluding race attacks or as you mentioned ancestral unconfirmed attacks. Opt in RBF is used in many ways to try to do double spends - i.e with ancestral attacks inputs which are not confirmed, and also publishing the RBF first and then the straight trxs later. In general double spends excl Optin RBF does not occur alot at all - but the presence of a potential risk causes everyone to wait back for confirmations. Looking at a sample of latest 4.3M trxs, I can see crica 11k trxs which seem to be double spent vast majority of these will be RBF, also on trx that are high risk and we dont confirm the attacker has no incentive to follow through with the second trxs. I see quite a bit of reference to the benefit to miners for RBF - I would think this cash flow benefit is not significant but I would suggest getting input from a miner themselves. Best Daniel ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz On Fri, Dec 2, 2022 at 3:52 AM Antoine Riard wrote: > 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 lowe= r > 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, neither to remove it. In the direction of removing th= e > 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 op= en > question if we (we, as the Bitcoin protocol development community, with a= ll > 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 wide= r > smoother deployment was to address a DoS vector affecting another class o= f > use-case: multi-party transactions like coinjoin and contracting protocol= s > 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 conceptua= l > issues [4] [5]. > > Best, > Antoine > > [0] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/0210= 70.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/0211= 35.html > [5] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021= 144.html > > Le jeu. 1 d=C3=A9c. 2022 =C3=A0 07:32, Daniel Lipshitz via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > >> HI All >> >> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other >> crypto transactions, BTC is a primary part of our business. Our guarant= ee >> enables our customers to recognise zero-conf deposits. We reimburse our >> clients value of the trx should we get it wrong and a transaction we >> confirmed gets double spent. >> >> Should full RBF become default enabled and significantly adopted this >> would have a major impact on the capacity to accept zerof confs on mainn= et. >> With the end result being this use case will be forced to move to a >> different chain, with lightning being just another option. >> >> I wanted to share some statistics about how significant this use case is= . >> GAP600 clients are primarily payment processors and non custodial >> liquidity providers; you can see some of our clients on our site >> www.gap600.com. There are also merchants who have developed their own >> tools so GAP600 statistics are only a subset of the full use case. >> >> I do not know of any wallet, exchange or custodian who accepts zero conf >> without having some sort of solution in place. The market seems to be fu= lly >> aware of the risks of zero-conf. The opt-RBF seems to be a solution whic= h >> gives a clear free choice for actors. >> >> Statistics for consideration as a sample of the zero conf use case - >> >> >> 1. As of end of Nov 2022 - GAP600 has processed i.e responded to >> circa 15M transactions >> 2. These transactions have a cumulative value of 2.3B USD value. >> 3. We currently are seeing circa 1.5M transactions queired per month. >> >> >> It's a sizable amount of trxs on mainet and we are by no means the full >> market of platforms accepting zero-conf. I realise there are other >> considerations which BTC has, I would urge you to take into account the >> major risk being placed on this significant market share when deciding t= o >> make this feature default enabled and encouraging full adoption. >> >> Thank you for your consideration >> Daniel >> ________________________________ >> >> Daniel Lipshitz >> GAP600| www.gap600.com >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000fd147805eed2dfa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI=C2=A0Antoine

Thank you for all the r= eferences - I agree with Sergej statement=C2=A0"opportunity makes the = thief"

The 1.5M trxs are all BTC which our cl= ients query, I dont have specifics for those trxs i.e. reasons for not bein= g confirmed. However we target to achieve +90% confirmation of trxs for our= clients. Fee rates the transactions generally follow standard fee/rate pol= icy similar to all industry recommendations, we recommend higher priority f= ee rate but approve trxs well below that level. I would say we havent=C2=A0= seen a trx with medium fee rate be double spend - this is excluding=C2=A0ra= ce attacks or as you mentioned ancestral=C2=A0unconfirmed attacks.

Opt in RBF is used in many ways to try to do double spends= - i.e with ancestral=C2=A0attacks inputs which are not confirmed, and also= publishing the RBF first and then the straight trxs later. In general doub= le spends excl Optin=C2=A0RBF does not occur alot at all - but the presence= of a potential risk causes=C2=A0everyone to wait back for confirmations.

Looking at a sample of latest 4.3M trxs, I can see = crica 11k trxs which seem to be double spent vast majority of these will be= RBF, also on trx that are high risk and we dont confirm the attacker has n= o incentive to follow through with the second trxs.

I see quite a bit of reference to the benefit to miners for RBF - I would= think this cash flow benefit is not significant=C2=A0but I would suggest g= etting input from a miner themselves.

Best
Daniel



On Fri, Dec 2, 2022 at 3:52 AM Antoine Ri= ard <antoine.riard@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">Hi Daniel,

From my understanding of GAP600, you'= re operating a zero-conf risk analysis business, which is integrated and le= veraged by payment processors/liquidity providers and merchants. A deployme= nt of fullrbf by enough full-node operators and a subset of the mining hash= rate would lower the cost of double-spend attack by lamda users, therefore = increasing the risk exposure of your users. This increased risk exposure co= uld lead you to alter the acceptance of incoming zero-conf transactions, AF= AICT in a similar reasoning as exposed by Bitrefill earlier this year [0].<= br>
About the statistics you're asking for considerations, few furth= er 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 exclu= ded from zeroconf due to factors like RBF, long-chain of unconfirmed ancest= ors 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 sti= ll the same as expressed in #26525 [1]. As a community, I think we still do= n't have conceptual consensus on deploying full-rbf, neither to remove = it. In the direction of removing the current option from Bitcoin Core, I th= ink the prerequisite to address are the qualification of enough economic fl= ows at risk and the presence of a sizable loss in miners income. Beyond tha= t, I think there is still the open question if we (we, as the Bitcoin proto= col development community, with all its stakeholders) should restrain user = choice in policy settings in the name of preserving mining income and estab= lished use-case stability.

To recall, the original technical motivat= ion of this option, and the wider smoother deployment was to address a DoS = vector affecting another class of use-case: multi-party transactions like c= oinjoin and contracting protocols like Lightning [2] [3]. All of them expec= t to generate economic flows and corresponding mining income. Since then, a= lternative paths to solve this DoS vector have been devised, all with their= own trade-offs and conceptual issues [4] [5].

Best,
Antoine
<= br>[0] https://lists.linuxfoundation.or= g/pipermail/bitcoin-dev/2022-October/021070.html
[1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319= 499006
[2] https://lists.linuxfound= ation.org/pipermail/bitcoin-dev/2022-June/020557.html
[3] https://lists.linuxfoundation.org/pipermail/lightni= ng-dev/2021-May/003033.html
[4] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135= .html
[5] https://lists.linuxfo= undation.org/pipermail/bitcoin-dev/2022-November/021144.html
<= br>
Le=C2= =A0jeu. 1 d=C3=A9c. 2022 =C3=A0=C2=A007:32, Daniel Lipshitz via bitcoin-dev= <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
<= /div>
HI = All

I am the CEO of GAP600. We guarantee zero confirmed = Bitcoin and other crypto=C2=A0 transactions, BTC is a primary part of our b= usiness. Our guarantee enables our customers to recognise zero-conf deposit= s. We reimburse our clients value of the trx should we get it wrong and a t= ransaction we confirmed gets double spent.

Should = full RBF become default enabled and significantly adopted this would have a= major impact on the capacity to accept zerof confs on mainnet. With the en= d result being this use case will be forced to move to a different chain, w= ith lightning being just another=C2=A0option.

I wa= nted to share some statistics about how significant this use case is.=C2=A0=
GAP600 clients are primarily payment processors and non custodia= l liquidity=C2=A0providers; you can see some of our clients on our site www.gap600.com. There = are also merchants who have developed their own tools so GAP600 statistics = are only a subset of the full use case.=C2=A0

I do= not know of any wallet, exchange or custodian who accepts zero conf withou= t having some sort of solution=C2=A0in place. The market seems to be fully = aware of the risks of zero-conf. The opt-RBF seems to be a solution which g= ives a clear free choice for actors.

Statistics fo= r consideration as a sample of the zero conf use case -=C2=A0
  1. As of end of Nov 2022 - GAP600 has processed i.e respon= ded to circa 15M transactions
  2. These transactions have a cumulative = value of 2.3B USD value.=C2=A0
  3. We currently are seeing circa 1.5M t= ransactions queired per month.=C2=A0

It&= #39;s a sizable amount of trxs on mainet and we are by no means the full ma= rket of platforms accepting zero-conf.=C2=A0=C2=A0I realise there are other= considerations which BTC has,=C2=A0 I would urge you to take into account = the major risk being placed on this significant market share when deciding = to make this feature default enabled and encouraging=C2=A0full adoption.

Thank you for your consideration
Daniel
________________________________

Daniel Lipshitz
GAP600|=C2=A0www.gap600.com

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000fd147805eed2dfa5--