š
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>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-08-02 10:19:21
in reply to nevent1qā¦jg3y
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-08-02 10:19:21Event JSON
{
"id": "93e95efc0af382d67bb8a527a67ad24bfad2886a8690be681662dbdbabc29574",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1690971561,
"kind": 1,
"tags": [
[
"e",
"697bcfa298f3a9d13b8e90fbe9dd354e837278976d35c19e881d424315b35661",
"",
"root"
],
[
"e",
"2186c3a43a67eb3139fce7257b68d6f5b17d5b75b3fb679846952877781e44fc",
"",
"reply"
],
[
"p",
"597ddb53eb981ecf2a6caca109ddcf48de5e99c06614fd2a324b66c1f65dcfa6"
]
],
"content": "š
Original date posted:2023-08-01\nšļø 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.\nš Original message:\nOn Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:\n\u003e Your research is not thorough and reaches an incorrect conclusion.\n\u003e \n\u003e As stated many times - we service payment processors and some merchants\n\u003e directly - Coinspaid services multiple merchants and process a\n\u003e significant amount of BTC they are a well known and active in the space -\n\u003e as I provided back in December 2022 a email from Max the CEO of Coinspaid\n\u003e confirming their use of 0-conf as well as providing there cluster addresses\n\u003e to validate there deposit flows see here again -\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html\n\u003e - if this is not sufficient then please email support at coinspaid.com and ask\n\u003e to be connected to Max or someone from the team who can confirm Conspaid is\n\u003e clients of GAP600. Max also at the time was open to do a call, I can check\n\u003e again now and see if this is still the case and connect you.\n\u003e \n\u003e That on its own is enough of a sample to validate our statistics.\n\nWhy don't you just give me an example of some merchants using Coinspaid, and\nanother example using Coinpayments, who rely on unconfirmed transactions? If\nthose merchants actually exist it should be very easy to give me some names of\nthem.\n\nWithout actual concrete examples for everyone to see for themselves, why should\nwe believe you?\n\n\u003e I have also spoken to Changelly earlier today and they offered to email pro\n\u003e @ changelly.com and they will be able to confirm GAP600 as a service\n\nEmailed; waiting on a reply.\n\n\u003e provider. Also please send me the 1 trx hash you tested and I can see if it\n\u003e was queried to our system and if so offer some info as to why it wasnt\n\u003e approved. Also if you can elaborate how you integrated with Changelly - I\n\u003e can check with them if that area is not integrated with GAP600.\n\nWhy don't you just tell me exactly what service Changelly offers that relies on\nunconfirmed transactions, and what characteristics would meet GAP600's risk\ncriteria? I and others on this mailing list could easily do test transactions\nif you told us what we can actually test. If your service actually works, then\nyou can safely provide that information.\n\nI'm not going to give you any exact tx hashes of transactions I've already\ndone, as I don't want to cause any problems for the owners of the accounts I\nborrowed for testing. Given your lack of honesty so far I have every reason to\nbelieve they might be retalliated against in some way.\n\n\u003e As the architect of such a major change to the status of 0-conf\n\u003e transactions I would think you would welcome the opportunity to speak to\n\u003e business and users who actual activities will be impacted by full RBF\n\u003e becoming dominant.\n\nFunny how you say this, without actually giving any concrete examples of\nbusinesses that will be affected. Who exactly are these businesses? Payment\nprocessors obviously don't count.\n \n\u003e Are you able to provide the same i.e emails and contacts of people at\n\u003e the mining pools who can confirm they have adopted FULL RBF ?\n\nI've already had multiple mining pools complain to me that they and their\nemployees have been harassed over full-rbf, so obviously I'm not going to\nprovide you with any private contact information I have. There's no need to\nexpose them to further harassment.\n\nIf you actually offered an unconfirmed transaction guarantee service, with real\ncustomers getting an actual benefit, you'd be doing test transactions\nfrequently and would already have a very good idea of what pools do full-rbf.\nWhy don't you already have this data?\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment.sig\u003e",
"sig": "a172e5220671865ac87cd141e9d9de6b56dfaa92844e54f98deb101bcaea4d767d122545332ff3cbdec64e63d3dc7b4e76cb5b568dd93d2b5241fc1e055c526b"
}