diff options
| author | Daniel Lipshitz <daniel@gap600.com> | 2022-12-02 08:59:01 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-12-02 06:59:15 +0000 |
| commit | 29e6a556f1981549979a28bc256210d715f63b3c (patch) | |
| tree | 33bcab53ac927089c21936fb393612e041d3959a | |
| parent | c0f44611c76ec92b5f9d2a82fee86b99552701f1 (diff) | |
| download | pi-bitcoindev-29e6a556f1981549979a28bc256210d715f63b3c.tar.gz pi-bitcoindev-29e6a556f1981549979a28bc256210d715f63b3c.zip | |
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
| -rw-r--r-- | 30/715b0dc09f3631252acdb1b7c778aac5d65e49 | 413 |
1 files changed, 413 insertions, 0 deletions
diff --git a/30/715b0dc09f3631252acdb1b7c778aac5d65e49 b/30/715b0dc09f3631252acdb1b7c778aac5d65e49 new file mode 100644 index 000000000..79b207feb --- /dev/null +++ b/30/715b0dc09f3631252acdb1b7c778aac5d65e49 @@ -0,0 +1,413 @@ +Return-Path: <daniel@gap600.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 38AFBC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Dec 2022 06:59:13 +0000 (UTC) +Received: by mail-vs1-xe29.google.com with SMTP id t10so3637661vsa.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <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: Daniel Lipshitz <daniel@gap600.com> +Date: Fri, 2 Dec 2022 08:59:01 +0200 +Message-ID: <CACkWPs_fgjkF8wJxUVex=R4sS-B6R+UgtqVQU0T-8vzpHjWT2Q@mail.gmail.com> +To: Antoine Riard <antoine.riard@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000fd147805eed2dfa5" +X-Mailman-Approved-At: Sat, 03 Dec 2022 00:19:46 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <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 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 <antoine.riard@gmail.com> +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 + +<div dir=3D"ltr">HI=C2=A0Antoine<div><br></div><div>Thank you for all the r= +eferences - I agree with Sergej statement=C2=A0"opportunity makes the = +thief"</div><div><br></div><div>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.</div><di= +v><br></div><div>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.</= +div><div><br></div><div>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.</div><div><br></div><di= +v>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.</div><div><span style=3D"font-size:12= +.8px"><br></span></div><div><span style=3D"font-size:12.8px">Best</span></d= +iv><div><span style=3D"font-size:12.8px">Daniel</span></div><br class=3D"gm= +ail-Apple-interchange-newline"><div><div dir=3D"ltr" class=3D"gmail_signatu= +re" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt= +r"><div style=3D"font-size:12.8px">________________________________</div><d= +iv style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px"><fo= +nt face=3D"tahoma, sans-serif">Daniel Lipshitz</font></div><div style=3D"fo= +nt-size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sans-serif">GAP600|= +=C2=A0<a href=3D"http://www.gap600.com/" target=3D"_blank">www.gap600.com</= +a></font></div><div style=3D"font-size:12.8px;color:rgb(0,0,0)"><font face= +=3D"tahoma, sans-serif">Phone:=C2=A0</font><span style=3D"font-family:tahom= +a,sans-serif;font-size:12.8px">+44 113 4900 117</span></div><div style=3D"f= +ont-size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sans-serif">Skype: = +daniellipshitz123</font></div><div style=3D"font-size:12.8px;color:rgb(0,0,= +0)"><font face=3D"tahoma, sans-serif">Twitter: @daniellipshitz</font></div>= +</div></div></div></div></div><br></div><br><div class=3D"gmail_quote"><div= + dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 2, 2022 at 3:52 AM Antoine Ri= +ard <<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.com<= +/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= +px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><= +div dir=3D"ltr">Hi Daniel,<br><br>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><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) ?<br><br>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.<br><br>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].<br><br>Best,<br>Antoine<br><= +br>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2= +022-October/021070.html" target=3D"_blank">https://lists.linuxfoundation.or= +g/pipermail/bitcoin-dev/2022-October/021070.html</a><br>[1] <a href=3D"http= +s://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006" target= +=3D"_blank">https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319= +499006</a><br>[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bi= +tcoin-dev/2022-June/020557.html" target=3D"_blank">https://lists.linuxfound= +ation.org/pipermail/bitcoin-dev/2022-June/020557.html</a><br>[3] <a href=3D= +"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.= +html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightni= +ng-dev/2021-May/003033.html</a><br>[4] <a href=3D"https://lists.linuxfounda= +tion.org/pipermail/bitcoin-dev/2022-October/021135.html" target=3D"_blank">= +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135= +.html</a><br>[5] <a href=3D"https://lists.linuxfoundation.org/pipermail/bit= +coin-dev/2022-November/021144.html" target=3D"_blank">https://lists.linuxfo= +undation.org/pipermail/bitcoin-dev/2022-November/021144.html</a><br></div><= +br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2= +=A0jeu. 1 d=C3=A9c. 2022 =C3=A0=C2=A007:32, Daniel Lipshitz via bitcoin-dev= + <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> a =C3=A9crit=C2=A0:<br><= +/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= +rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">HI = +All<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I wa= +nted to share some statistics about how significant this use case is.=C2=A0= +</div><div>GAP600 clients are primarily payment processors and non custodia= +l liquidity=C2=A0providers; you can see some of our clients on our site <a = +href=3D"http://www.gap600.com" target=3D"_blank">www.gap600.com</a>. There = +are also merchants who have developed their own tools so GAP600 statistics = +are only a subset of the full use case.=C2=A0</div><div><br></div><div>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.</div><div><br></div><div>Statistics fo= +r consideration as a sample of the zero conf use case -=C2=A0</div><div><br= +></div><div><ol><li>As of end of Nov 2022 - GAP600 has processed i.e respon= +ded to circa 15M transactions</li><li>These transactions have a cumulative = +value of 2.3B USD value.=C2=A0</li><li>We currently are seeing circa 1.5M t= +ransactions queired per month.=C2=A0</li></ol></div><div><br></div><div>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.</d= +iv><div><br></div><div>Thank you for your consideration</div><div>Daniel</d= +iv><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"fo= +nt-size:12.8px">________________________________</div><div style=3D"font-si= +ze:12.8px"><br></div><div style=3D"font-size:12.8px"><font face=3D"tahoma, = +sans-serif">Daniel Lipshitz</font></div><div style=3D"font-size:12.8px;colo= +r:rgb(0,0,0)"><font face=3D"tahoma, sans-serif">GAP600|=C2=A0<a href=3D"htt= +p://www.gap600.com/" target=3D"_blank">www.gap600.com</a></font></div><div = +style=3D"font-size:12.8px;color:rgb(0,0,0)"><br></div></div></div></div></d= +iv></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div> + +--000000000000fd147805eed2dfa5-- + |