From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2FF04C0032 for ; Tue, 1 Aug 2023 22:27:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id EAD5F60BFF for ; Tue, 1 Aug 2023 22:27:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EAD5F60BFF 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=PmHuw954 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 3SHNEeDgyn4Y for ; Tue, 1 Aug 2023 22:27:37 +0000 (UTC) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) by smtp3.osuosl.org (Postfix) with ESMTPS id 93A5960DFE for ; Tue, 1 Aug 2023 22:27:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 93A5960DFE Received: by mail-vk1-xa34.google.com with SMTP id 71dfb90a1353d-48642c1607bso2468467e0c.0 for ; Tue, 01 Aug 2023 15:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google; t=1690928856; x=1691533656; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GADwq+PoZrK3WQyReK+F2bHhwaWolrJ77yqKzxhG44w=; b=PmHuw954PkNrbx/v9P0WBvT8xYDQOKc0mipoGpijoSwEOyoMkhQ77evD5I2wTKs4t4 wYAOePaMLw9DaH0Pqhg5cUh0gUsbwLNS8CpA6BdY11tidQFF+FfehtACKCPC4Ue/g0c2 vrPyA2eN4nqBHLCbAIoopuRuX0zYFWxGByUPCrK3fU1JE9qnppCFSyKzzvn7g3RamFcC yzNJLmTV8tCNZCZNjnTmktlAztgLPzW4tVOaECK4fTeidD9hcqI9u9e0lVmvGxmjBxUB +2VoxAEXw4eBTqy2bYhDliondbRGTUDZVydScX1iNulkk1u6kVMDIKEVK3Fc38WVlS/J qLfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690928856; x=1691533656; 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=GADwq+PoZrK3WQyReK+F2bHhwaWolrJ77yqKzxhG44w=; b=QFj0tEhkb5uDgf4NDp5TO7KLswjENhCNnIBGy3gKUXtttwEUTgksA74S0yh6F/JL9x B11pE7tQPCRYD452LCtv82tVbj0RKwDU6ZtWtzVhCdmcl6gtWRoz8rG6X62ptyaO+oYL AJ6tmWWSx3tvcHX2raFuNjj5rzimCtAxqr5sk6+wFOWkWz9f5dagKVOVcDdLsJy+rK/9 gic/LKIyJf36ElyHs5xzIN7ozypqvnmRZNfYOOw+LCmdNnKLLar54O4zdrBPRcFEifv1 IWYkRZ18pwwD/HGUk1FHDas2izgoWR2YnrO1n6lanmoms/gCuvJ6kiCvqEPORyG4YXIB CFFQ== X-Gm-Message-State: ABy/qLbJU6TdgWvdBuEaBGKXNSSKkgo39sy4JRMIU1voxmNvLYEPQlzK NXwQr+ZgwL+7u2zNULeEff1jv1WA1NJqYwT1XTzOiw== X-Google-Smtp-Source: APBJJlGStwZXfIIlx4TGql2JE5v8Pa7AvVqLXfOyOOowo89y7rxuB8Y+zJHNqTcWS3YcppnpQCkQpNXXOho5usXygK8= X-Received: by 2002:a1f:4394:0:b0:485:ac24:df1 with SMTP id q142-20020a1f4394000000b00485ac240df1mr3647947vka.12.1690928855973; Tue, 01 Aug 2023 15:27:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Lipshitz Date: Wed, 2 Aug 2023 01:27:24 +0300 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="000000000000cd17710601e40d1c" X-Mailman-Approved-At: Tue, 01 Aug 2023 22:59:38 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 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: Tue, 01 Aug 2023 22:27:39 -0000 --000000000000cd17710601e40d1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your research is not thorough and reaches an incorrect conclusion. As stated many times - we service payment processors and some merchants directly - Coinspaid services multiple merchants and process a significant amount of BTC they are a well known and active in the space - as I provided back in December 2022 a email from Max the CEO of Coinspaid confirming their use of 0-conf as well as providing there cluster addresses to validate there deposit flows see here again - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/02123= 9.html - if this is not sufficient then please email support@coinspaid.com and ask to be connected to Max or someone from the team who can confirm Conspaid is clients of GAP600. Max also at the time was open to do a call, I can check again now and see if this is still the case and connect you. That on its own is enough of a sample to validate our statistics. I have also spoken to Changelly earlier today and they offered to email pro @ changelly.com and they will be able to confirm GAP600 as a service provider. Also please send me the 1 trx hash you tested and I can see if it was queried to our system and if so offer some info as to why it wasnt approved. Also if you can elaborate how you integrated with Changelly - I can check with them if that area is not integrated with GAP600. As the architect of such a major change to the status of 0-conf transactions I would think you would welcome the opportunity to speak to business and users who actual activities will be impacted by full RBF becoming dominant. Are you able to provide the same i.e emails and contacts of people at the mining pools who can confirm they have adopted FULL RBF ? ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz On Tue, Aug 1, 2023 at 6:04=E2=80=AFPM Peter Todd wrot= e: > On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev > wrote: > > This would unnecessarily and extremely negatively impact merchants and > > users who choose to accept 0-conf while using mitigation tools like > GAP600. > > This negative impact could be avoided by simply adding first seen safe > rule > > - ie a trx can be replaced but needs to include the original outputs. > > > > At GAP600 we continue to see strong use of our service for BTC we have > seen > > circa 350k unique trx hash per month (over the last 3 months) requested > to > > our platform. Our clients include - Coinpayments, Coinspaid and > Changelly. > > I checked, and Coinpayments and Coinspaid are both merchant processors. I > could > not find any example of actual merchants using their platform accepting > unconfirmed payments. I also could not find any documentation on their > websites > indicating unconfirmed transaction acceptance. > > As for Changelly, their website says right on the front that "With an > average > transaction speed of 5=E2=80=9340 minutes, we ensure you can swiftly take > advantage of > market opportunities." Obivously, 5 minutes is not an unconfirmed payment= . > > Additionally, I verified myself by doing test transactions with BIP125 > disabled > and an adequate fee: unconfirmed payments are not accepted by Changelly. = As > their exchange flow clearly says "Once BTC is confirmed in the blockchain= , > we=E2=80=99ll start exchanging it to ." > > You need to provide an genuine example of an actual merchant who accepts > unconfirmed transactions as payment, and actually relies on first-seen > behavior. > > > We have not seen any impact of full RBF on double spend rates for our > trxs > > Based on the above findings, this appears to be because you don't actuall= y > have > any clients who rely on unconfirmed payments. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --000000000000cd17710601e40d1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your research is not thorough=C2=A0and reaches an inc= orrect conclusion.

As stated many times - we service pa= yment processors and some merchants directly=C2=A0 - Coinspaid services mul= tiple merchants and process a significant=C2=A0amount of BTC they are a wel= l known and active in the space - as I provided back in December 2022 a ema= il from Max the CEO of Coinspaid confirming their use of 0-conf as well as = providing there cluster addresses to validate there deposit flows see here = again -=C2=A0https://lists.linuxfoundation.org/pipermail= /bitcoin-dev/2022-December/021239.html - if this is not sufficient=C2= =A0then please email support@coins= paid.com and ask to be connected to Max or someone from the team who ca= n confirm Conspaid is clients of GAP600. Max also at the time was open to d= o a call, I can check again now and see if this is still the case and conne= ct you.

That on its own is enough of a sample to validat= e our statistics.

I have=C2=A0also spoken=C2=A0to = Changelly earlier today and they offered to email p= ro @ changelly.com and they wil= l be able to confirm GAP600 as a service provider. Also please send me the = 1 trx hash you tested and I can see if it was queried to our system and if = so offer some info as to why it wasnt approved. Also if you can elaborate= =C2=A0how you integrated with Changelly - I can check with them if that are= a is not integrated with GAP600.=C2=A0

As the arch= itect of such a major change to the status of 0-conf transactions=C2=A0I wo= uld think you would welcome the opportunity=C2=A0to speak to business and u= sers who actual activities will be impacted by full RBF becoming dominant.<= /div>

Are you able to provide the same i.e emails and co= ntacts of people at the=C2=A0mining=C2=A0pools who can confirm they have ad= opted FULL RBF ?

____________= ____________________

Daniel Lipshitz<= /font>
GAP600|=C2=A0www.gap600.com
Phone:=C2=A0+44 113 4900 117<= /span>
Skype: daniellipshitz123
Twitter: @= daniellipshitz

On Tue, = Aug 1, 2023 at 6:04=E2=80=AFPM Peter Todd <pete@petertodd.org> wrote:
On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel= Lipshitz via bitcoin-dev wrote:
> This would unnecessarily and extremely negatively impact merchants and=
> users who choose to accept 0-conf while using mitigation tools like GA= P600.
> This negative impact could be avoided by simply adding first seen safe= rule
> - ie a trx can be replaced but needs to include the original outputs.<= br> >
> At GAP600 we continue to see strong use of our service for BTC we have= seen
> circa 350k unique trx hash per month (over the last 3 months) requeste= d to
> our platform. Our clients include - Coinpayments, Coinspaid and Change= lly.

I checked, and Coinpayments and Coinspaid are both merchant processors. I c= ould
not find any example of actual merchants using their platform accepting
unconfirmed payments. I also could not find any documentation on their webs= ites
indicating unconfirmed transaction acceptance.

As for Changelly, their website says right on the front that "With an = average
transaction speed of 5=E2=80=9340 minutes, we ensure you can swiftly take a= dvantage of
market opportunities." Obivously, 5 minutes is not an unconfirmed paym= ent.

Additionally, I verified myself by doing test transactions with BIP125 disa= bled
and an adequate fee: unconfirmed payments are not accepted by Changelly. As=
their exchange flow clearly says "Once BTC is confirmed in the blockch= ain,
we=E2=80=99ll start exchanging it to <coin>."

You need to provide an genuine example of an actual merchant who accepts unconfirmed transactions as payment, and actually relies on first-seen
behavior.

> We have not seen any impact of full RBF on double spend rates for our = trxs

Based on the above findings, this appears to be because you don't actua= lly have
any clients who rely on unconfirmed payments.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--000000000000cd17710601e40d1c--