📅 Original date posted:2023-08-01
🗒️ Summary of this message: Daniel Lipshitz argues that the research is flawed and reaches an incorrect conclusion. He provides evidence of Coinspaid's use of 0-conf and offers to connect with Max, the CEO, for confirmation. He also mentions Changelly's offer to confirm GAP600 as a service provider. However, the request for concrete examples of merchants relying on unconfirmed transactions remains unanswered.
📝 Original message:
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 Coinspaid
> 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/021239.html
> - if this is not sufficient then please email support at coinspaid.com and ask
> to be connected to Max or someone from the team who can confirm Conspaid 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 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 relies on
unconfirmed transactions, and what characteristics would meet GAP600's risk
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 already
done, as I don't want to cause any problems for the owners of the accounts 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
> 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
> 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, 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-rbf.
Why don't you already have this data?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment.sig>