Feedback-ID: i525146e8:Fastmail
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
Precedence: list


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