From: Peter Todd <pete@petertodd•org>
To: Daniel Lipshitz <daniel@gap600•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pull-req to enable Full-RBF by default
Date: Thu, 3 Aug 2023 12:46:40 +0000 [thread overview]
Message-ID: <ZMuhsGj+tsv+xBzW@petertodd.org> (raw)
In-Reply-To: <CACkWPs_jKUCBPhvj3mGYQu6erLE5qKxXorXAtJpuGCKSaSjVwQ@mail.gmail.com> <CACkWPs-jW-bae2oywp-LswFhmWhNAFZEFg7M=rXLi6nMGLUgRw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5615 bytes --]
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 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.
Claims of "trxs activity" are completely meaningless when you can't demonstrate
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 something like this and could easily be done -
>
> Create 20 trxs (larger numbers better) in between every block and after 30 seconds try replace them.
> Run this test for at least a few hours preferably more than 24 hours or even 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 get 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.
>
> 1. Our research is based on monitoring main net transactions and network
> activity - as too is our risk engine. We do not engage in specific hashing
> 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 fierce
> and like other industries it is not an acceptable approach to ask.
> 3. The information offered by Coinpaid and posted on this list, provides
> root addresses which using tools like Chainanlysis, or
> similar service providers can confirm these addresses are associated with
> Coinspaid. This can validate a significant amount of our traffic.
This reminds me of how Craig Wright appears to have picked a bunch of bitcoin
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 proof
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 verify
that they provides things of value in exchange for an unconfirmed transaction.
> 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 provide
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/
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-08-03 12:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.126799.1690753843.956.bitcoin-dev@lists.linuxfoundation.org>
2023-07-31 4:12 ` [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn) Hugo L
2023-08-02 5:58 ` Keagan McClelland
2023-07-31 10:26 ` [bitcoin-dev] Pull-req to enable Full-RBF by default Daniel Lipshitz
2023-08-01 15:04 ` Peter Todd
2023-08-01 22:27 ` Daniel Lipshitz
2023-08-02 1:28 ` Peter Todd
2023-08-02 10:38 ` Daniel Lipshitz
2023-08-02 15:29 ` Daniel Lipshitz
2023-08-03 12:46 ` Peter Todd [this message]
2023-08-16 10:25 ` [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now Peter Todd
2023-08-16 14:02 ` Peter Todd
2023-07-30 15:44 [bitcoin-dev] Pull-req to enable Full-RBF by default Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZMuhsGj+tsv+xBzW@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=daniel@gap600$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox