path: root/62/c4dd71248c4e2744b3d8340a7a493945543019

Return-Path: <pete@petertodd.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 705AEC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 12:46:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 38D0641EBE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 12:46:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 38D0641EBE
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=D41NF0Ez
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 5kBJcuP1ny-x
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 12:46:51 +0000 (UTC)
Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com
 [64.147.123.27])
 by smtp4.osuosl.org (Postfix) with ESMTPS id D830841BB0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Aug 2023 12:46:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D830841BB0
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
 by mailnew.west.internal (Postfix) with ESMTP id DBBC62B002B4;
 Thu,  3 Aug 2023 08:46:46 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute5.internal (MEProxy); Thu, 03 Aug 2023 08:46:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:reply-to:sender:subject:subject:to:to
 :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm3; t=1691066806; x=1691074006; bh=N2uHlt18QQnvwA12w1CHrxkRW087
 sdy89pVgyN/+i/c=; b=D41NF0Ez5jUR1rt+QtjYgdzjJ+cCcawHfu6cIHxgER8U
 WIR+6E9OPn/a+Jafstah9UEsBhmer+oK9j4bbL8gNsZF0UqfJIoOyLNBpmRWVSu5
 lqP1bkX8G2XziZCup4TriTvnPdVJsdBu4IuCxoW3fcJ0Av/TsPFpK1FzA/SjNNT+
 u/p3+ghuwB/J696w16G+uPH6BgOSOeXl8pSUGqJF9bfaqvfnbegp21ltnkHPSBQW
 JOhj1rc2o2yUI27BwFDCsjkWGJZj6XJZiWizg8DU/YvwMdjI+2Gh4R7UhCZgaflg
 rIARMarvoXqcMBEaeMGB81thlLrJEnTP0L2KtiEcdg==
X-ME-Sender: <xms:tqHLZGdphnwXtB80Z-5-ABMYiAEOtKX4erPZ77hz0uNHQcvLn7r3cg>
 <xme:tqHLZAOH14x6e1HRR3dYG_F7CkpVyjRBaO2irzlVq3Afo3eiCV8QliLQuJz5lKyuI
 -5mPqvzXC9lRx8wdSs>
X-ME-Received: <xmr:tqHLZHiGNaOw6D5bIxrroovrtxS51M45O1S0Ps1qf-GFdzTarxMEQEII-Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkedvgdehgecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecunddouefvvedqvfhhrhgvrghtshculdeftddtmdenuc
 fjughrpeffhffvvefukfggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgvrhcu
 vfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtthgvrh
 hnpeffjeevjefhhefhleffieeifeehkeeghfeggeefvddujeehhfdvudekvdduudetteen
 ucffohhmrghinhepghhithhhuhgsrdgtohhmpdhophgvnhhtihhmvghsthgrmhhpshdroh
 hrghdpghgrpheitddtrdgtohhmpdhpvghtvghrthhouggurdhorhhgnecuvehluhhsthgv
 rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrth
 houggurdhorhhg
X-ME-Proxy: <xmx:tqHLZD99HeCBd5zm4tkZm7phcYuWc8Bc3hWjcz1p-zuncoFCqc-OHA>
 <xmx:tqHLZCuybD9Zd38NBjG5snpE7P37Ja4YFdsGX6TPexkB73h7H1h4QA>
 <xmx:tqHLZKEa5bN7SemCRWh7orTbf5rg7SEHtNkoysalnTzM7TVOBT-KKQ>
 <xmx:tqHLZGLT_zmvWSqUqlWlkRFOzfGVkiqiwgwcviwYR1aqY5VVPArafvAPbYY>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 3 Aug 2023 08:46:45 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id A48865F823; Thu,  3 Aug 2023 12:46:40 +0000 (UTC)
Date: Thu, 3 Aug 2023 12:46:40 +0000
From: Peter Todd <pete@petertodd.org>
To: Daniel Lipshitz <daniel@gap600.com>
Message-ID: <ZMuhsGj+tsv+xBzW@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="FGWXgiv238iFSVtN"
Content-Disposition: inline
In-Reply-To: <CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail.gmail.com>
 <CACkWPs-jW-bae2oywp-LswFhmWhNAFZEFg7M=rXLi6nMGLUgRw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: Thu, 03 Aug 2023 12:46:54 -0000


--FGWXgiv238iFSVtN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 02, 2023 at 01:38:21PM +0300, Daniel Lipshitz wrote:
> Your assessment of my dishonesty is based on your assumption of how I
> should be running GAP600, your assumptions are baseless and lack commerci=
al
> experience and likewise your conclusions are false.
>=20
> 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.

Claims of "trxs activity" are completely meaningless when you can't demonst=
rate
that a single client of yours actually relies on unconfirmed transaction
acceptance.

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

Repeating your github comment here for purposes of reply:

> A clear and open method to research the adoption of full RBF would look s=
omething like this and could easily be done -
>
> Create 20 trxs (larger numbers better) in between every block and after 3=
0 seconds try replace them.
> Run this test for at least a few hours preferably more than 24 hours or e=
ven a few days.
> See results of how many were replaced.
> Ignore trx results if trx are included in blocks before replace trxs are =
published.
> Have other Bitcoin Core developers independently implement and review the=
 test results

I am baffled at the fact that you claim GAP600 offers a "real-time risk
engine"(1) guaranteeing "instant deposits & payments"(1), yet you are not
already testing full-rbf adoption yourself in this manner. If your business=
 was
in fact real, it'd be essential to keep track of double spend success rates.

> Based on a test like this or something similar it would be reliable to ge=
t to an assessment of the adoption of full RBF.

As you should know, my OpenTimestamps calendars,
https://alice.btc.calendar.opentimestamps.org/ and
https://bob.btc.calendar.opentimestamps.org/, have been creating full-rbf
double spends multiple times a day since last year. Those calendars have
created literally thousands of full-rbf replacements, providing ample test
data.

If your business was real - if you actually have a "real time risk engine" =
that
monitors mempools - you'd already know this. You'd also know about the
successful full-rbf replacements that Alice got mined today:

291e1abf146209839f8910cf9ede6979bb12e6efa6d73f52ca7ae0476eafa6a5 - AntPool
e7ea70c2e366ef035ed0428c704c55e5331211200c6e0298eb85a574812aa010 - Binance =
Pool
aa9e034283cc50a3cb042284833607bc49dea275854004a3757acf776e679a6b - Poolin
ae74600b66ccf9d8ee8d62e5881581b5baff11117e47ea51c3e4d1fee1612504 - AntPool

Those four transactions are each part of a chain of replacements, and every
chain started with a transaction paying well above the minimum relay fee in
present mempool conditions. Tell me, how do you think those full-rbf
replacements get mined?


On Wed, Aug 02, 2023 at 06:29:54PM +0300, Daniel Lipshitz wrote:
> For clarity purposes.
>=20
>    1. Our research is based on monitoring main net transactions and netwo=
rk
>    activity - as too is our risk engine. We do not engage in specific has=
hing
>    pool assessments or research.

So if you are "monitoring main net transactions and network activity", why =
are
you not already aware of the many full-rbf replacements getting mined every
day?

>    2. It is not easily possible or comfortable to engage with our clients
>    to offer up their client names and applications - the competition is f=
ierce
>    and like other industries it is not an acceptable approach to ask.
>    3. The information offered by Coinpaid and posted on this list, provid=
es
>    root addresses which using tools like Chainanlysis, or
>    similar service providers can confirm these addresses are associated w=
ith
>    Coinspaid. This can validate a significant amount of our traffic.

This reminds me of how Craig Wright appears to have picked a bunch of bitco=
in
addresses off of a "rich list" and fraudulently claimed those addresses to =
be
his.

Anyone can create a list of addresses from blockchain data. That is not pro=
of
that any actual merchant relies on unconfirmed transactions. To prove that =
you
need to provide the names of those merchant(s), so others can actually veri=
fy
that they provides things of value in exchange for an unconfirmed transacti=
on.

>    4. Based on the information provided it will be very possible to reach
>    out to Max at Coinpaid - and will be able to confirm GAP600 use with
>    Coinspaid. This is in addition to me posting an email from Max back in=
 Dec
>    2022 to this list confirming all of this information.

Again, Coinspaid is a merchant processor. Unless you or they actually provi=
de
details on real merchants making use of your claimed service, you have not
proven anything of value.

>    5.  It is more than likely that Changelly has not implemented our
>    service across all irts offerings, a large section of their business is
>    servicing partners.

FYI I emailed pro@changelly.com two days ago, asking for confirmation that =
they
use GAP600, and information on how exactly they rely on unconfirmed
transactions. So far I have not gotten a reply.


# References

1) https://www.gap600.com/

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--FGWXgiv238iFSVtN
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmTLoa4ACgkQLly11TVR
Lze9OBAArYGoOKz/bLEGvgTKf0wBv5Fc8LbVlTA0uNA4++tD2G3ID/YtQvt0g4da
1SWehWlWg7cUNKOcN/lhsWdeoptoVxCwyaYiTm3ehpfuP8XzoyriCfrkMO/hrJ4q
nqHO6xPcIHqQmyhiS1vfzPATQZ/dlAmdmNdmsK4KF65LHQiDkJ0lsMuT31ny0a8N
9hy9ktK8FhzsCnvSpwvW8fabqdZBhLqmykUeRRSHChtaBnLJgBhN9WKMYRUbwdc3
0TPqWyljgjKLLA+5d46a+83tI/25rc0mIsEtHWjauzaDEvQI9/BGIIzb4krZFh1x
fxPTBrf6d+HGkzuTBZfcvXwbdbaMzdtaQ/KlgYdwDV76d8enubcFYIS3MOro6kkM
ES8v+Q5sSAzkBMuRKk4lt+1N8Nj1kfruTm1UFs0aLV/zf+u1ekdRTZIppqRnFlJ1
8D7ybn64V+4lkfqt3AQ1LAY8Nx6QwjsYIneJMdi/q9+Wcnnd6ZmVG93py04hPd+Q
iUDp2YUvZ+pMP5TZ7qewzLT0T5ZgSRxjgNcSwG5nq397Y2Dgf6MsflWlB19pS9Im
2jZpvNgmzbuxUF7CIcv3m2vZBfOz3fIC/OS6C9/7JrdPahEHNGd9UBKYuDpBRWua
SF1muBl698O5JwUKf54Yce2DVXIvDkfv+yM+gXkMytAuxlezs5Y=
=/Ab7
-----END PGP SIGNATURE-----

--FGWXgiv238iFSVtN--