From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6572FC0032 for ; Wed, 2 Aug 2023 10:38:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4077B80C44 for ; Wed, 2 Aug 2023 10:38:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4077B80C44 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com header.a=rsa-sha256 header.s=google header.b=jmzZppir 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDRDTnIPLMkf for ; Wed, 2 Aug 2023 10:38:34 +0000 (UTC) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) by smtp1.osuosl.org (Postfix) with ESMTPS id B1C8580C12 for ; Wed, 2 Aug 2023 10:38:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B1C8580C12 Received: by mail-vk1-xa2b.google.com with SMTP id 71dfb90a1353d-4864a9faf90so524864e0c.0 for ; Wed, 02 Aug 2023 03:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google; t=1690972712; x=1691577512; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0RoWyz95lvIgQQfhBi6MnEdAE0+fAs45XjF6tIe1/Nk=; b=jmzZppire9nVHfy2W39GcG6DKxiUSbzhlxq5DzOcizyswdFTYQi02IDCrjEf4IciVp vyfvI9C1DrW6UbnNBcCARDKY4TG+cgNAQjG7j/Md3HEnW/GTKVeid9z4my4tFe4lU0lt EC9PKIQyJwb5NeCeo8JDWLxX+sF9BjA1DBdfdTJCLWuV3pd4/jO33QG5OSglpt6EZKN5 HY+0B16IKozkB7EaSWqXDwEcEvGLrVvT5Pmtt/UUGd51AXWc2Oiu/ZfVOdY+UGEl9YRn 91yv65Je+i1XNoeSawq62ASoQyLuvegJi3mprkXae39tPSgnP2jF6p6A9UOCzsPeymN5 sKVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690972712; x=1691577512; 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=0RoWyz95lvIgQQfhBi6MnEdAE0+fAs45XjF6tIe1/Nk=; b=TYqZ0CnNF6XWYtzQlRpLduv4G/jhpBlhWzr7qh8lfywH0RtRfOZB94BzXbxE7yHXoV VnRgNbpzBjoe6LRUiBzd0pT6WyW4RdT2w5xPvjUTUD/JZ2fz5+NQph8ayUtf4ZyKpPqN gJvsTO/4WSbs+gXd3HhlCYCn1EQ8JElXqQ0dBIZboQ0f3R6fccQr+law5/26VbGmFXdm LcOGx1+y6r0UgerCsVxOkjZImN3WK/QVys2bhDPakdnC+WPJfGyMl093EdBfPP6/ngyF 7jYE7HS6BQsoAmfJGPwerRsldHss/J/umJqm/OJn8qvuCgFVqmjSdKPzYYiCNkjbAjIg WJmw== X-Gm-Message-State: ABy/qLboblsxwD4p3OwCWVoRJ1kskVkceQmbhtNXIEtILU73sLxnXrhH eDnpOkaZCX8DAYj1AXqFfryalnW/Kt5qqee7l4LwMTBxSnpBlXayJcf/Jw== X-Google-Smtp-Source: APBJJlEFPlQ/H/QD/YUkjX4Iq5NozCoIY2uOnxK+REeAI3VpKHUockx7/S9Wno+wzxyQE/JYBsb/cezwNLS5L5KIJXM= X-Received: by 2002:a1f:ad44:0:b0:47d:57a0:b8ba with SMTP id w65-20020a1fad44000000b0047d57a0b8bamr2110688vke.6.1690972712377; Wed, 02 Aug 2023 03:38:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Lipshitz Date: Wed, 2 Aug 2023 13:38:21 +0300 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="000000000000d8b60a0601ee4317" X-Mailman-Approved-At: Wed, 02 Aug 2023 10:44:51 +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: Wed, 02 Aug 2023 10:38:35 -0000 --000000000000d8b60a0601ee4317 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your assessment of my dishonesty is based on your assumption of how I should be running GAP600, your assumptions are baseless and lack commercial experience and likewise your conclusions are false. I have provided already back in December clear access to clarify opposite our clients corroborated with easily verifiable trxs activity of a major client of ours. This is more than enough to corroborate our statistics. As far as validating real RBF adoption I have offered a clear option here https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440 something like this or similar would offer a clear assessment of adoption. Since you are not able to provide documents or public emails of hashing pools confirming there adoption of Full RBF. ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz On Wed, Aug 2, 2023 at 4:28=E2=80=AFAM Peter Todd wrot= e: > On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote: > > 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 Coinspa= id > > 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/021= 239.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 Conspai= d > 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. > > Why don't you just give me an example of some merchants using Coinspaid, > and > another example using Coinpayments, who rely on unconfirmed transactions? > If > those merchants actually exist it should be very easy to give me some > names of > them. > > Without actual concrete examples for everyone to see for themselves, why > should > we believe you? > > > 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 > > Emailed; waiting on a reply. > > > provider. Also please send me the 1 trx hash you tested and I can see i= f > 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. > > Why don't you just tell me exactly what service Changelly offers that > relies on > unconfirmed transactions, and what characteristics would meet GAP600's ri= sk > criteria? I and others on this mailing list could easily do test > transactions > if you told us what we can actually test. If your service actually works, > then > you can safely provide that information. > > I'm not going to give you any exact tx hashes of transactions I've alread= y > done, as I don't want to cause any problems for the owners of the account= s > I > borrowed for testing. Given your lack of honesty so far I have every > reason to > believe they might be retalliated against in some way. > > > 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 t= o > > business and users who actual activities will be impacted by full RBF > > becoming dominant. > > Funny how you say this, without actually giving any concrete examples of > businesses that will be affected. Who exactly are these businesses? Payme= nt > processors obviously don't count. > > > 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 ? > > I've already had multiple mining pools complain to me that they and their > employees have been harassed over full-rbf, so obviously I'm not going to > provide you with any private contact information I have. There's no need = to > expose them to further harassment. > > If you actually offered an unconfirmed transaction guarantee service, wit= h > real > customers getting an actual benefit, you'd be doing test transactions > frequently and would already have a very good idea of what pools do > full-rbf. > Why don't you already have this data? > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --000000000000d8b60a0601ee4317 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your=C2=A0assessment=C2=A0of my dishonesty is based on you= r assumption of how I should be running GAP600, your assumptions are basele= ss and lack commercial experience and likewise your conclusions are false.<= div>
I have provided already back in December clear access to= clarify opposite our clients corroborated with easily verifiable=C2=A0trxs= activity of a major client=C2=A0of ours. This is more than enough to corro= borate=C2=A0our statistics.=C2=A0

As far as valida= ting real RBF adoption I have offered a clear option here=C2=A0https= ://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440 someth= ing like this or similar would offer a clear assessment=C2=A0of adoption. S= ince you are not able to provide documents=C2=A0or public emails of hashing= pools confirming there adoption of Full RBF.
________= ________________________

Daniel Lipsh= itz
GAP600|=C2=A0www.gap600.com
Phone:=C2=A0+44 113 4900 1= 17
Skype: daniellipshitz123
Twitte= r: @daniellipshitz


On W= ed, Aug 2, 2023 at 4:28=E2=80=AFAM Peter Todd <pete@petertodd.org> wrote:
On Wed, Aug 02, 2023 at 01:27:24AM +0300, = Daniel Lipshitz wrote:
> Your research is not thorough and reaches an incorrect conclusion.
>
> As stated many times - we service payment processors and some merchant= s
> directly=C2=A0 - Coinspaid services multiple merchants and process a > significant amount of BTC they are a well known and active in the spac= e -
> as I provided back in December 2022 a email from Max the CEO of Coinsp= aid
> confirming their use of 0-conf as well as providing there cluster addr= esses
> to validate there deposit flows see here again -
> https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.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 Conspa= id is
> clients of GAP600. Max also at the time was open to do a call, I can c= heck
> 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.

Why don't you just give me an example of some merchants using Coinspaid= , and
another example using Coinpayments, who rely on unconfirmed transactions? I= f
those merchants actually exist it should be very easy to give me some names= of
them.

Without actual concrete examples for everyone to see for themselves, why sh= ould
we believe you?

> I have also spoken to Changelly earlier today and they offered to emai= l pro
> @ changelly.com and they will be able to confirm GAP600 as a service
Emailed; waiting on a reply.

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

Why don't you just tell me exactly what service Changelly offers that r= elies on
unconfirmed transactions, and what characteristics would meet GAP600's = risk
criteria? I and others on this mailing list could easily do test transactio= ns
if you told us what we can actually test. If your service actually works, t= hen
you can safely provide that information.

I'm not going to give you any exact tx hashes of transactions I've = already
done, as I don't want to cause any problems for the owners of the accou= nts I
borrowed for testing. Given your lack of honesty so far I have every reason= to
believe they might be retalliated against in some way.

> 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<= br> > becoming dominant.

Funny how you say this, without actually giving any concrete examples of businesses that will be affected. Who exactly are these businesses? Payment=
processors obviously don't count.

> Are you able to provide the same i.e emails and contacts of people at<= br> > the mining pools who can confirm they have adopted FULL RBF ?

I've already had multiple mining pools complain to me that they and the= ir
employees have been harassed over full-rbf, so obviously I'm not going = to
provide you with any private contact information I have. There's no nee= d to
expose them to further harassment.

If you actually offered an unconfirmed transaction guarantee service, with = real
customers getting an actual benefit, you'd be doing test transactions frequently and would already have a very good idea of what pools do full-rb= f.
Why don't you already have this data?

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