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 p...@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
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
