Peter Todd [ARCHIVE] on Nostr: š Original date posted:2023-01-13 šļø Summary of this message: GAP600 is a ...
š
Original date posted:2023-01-13
šļø Summary of this message: GAP600 is a service that enables clients to accept 0-conf transactions, accessed via API, and not based on AML/KYC, but it raises privacy concerns. Full-RBF should be implemented to stop the collection of data.
š Original message:On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
> GAP600 is not a trxs processor or liquidity provider we service merchants,
> payment processors & non-custodial liquidity providers - our service is
> purely the 0-conf enabling our clients to accept 0-conf. Clients access our
> service via API - sending us the Trx hash & output address. Our service is
> not based on AML/KYC it is purely an analysis of the Bitcoin network.
I checked and to sign up for your service, you ask for the name, phone number,
email, and company name.
That is an example of AML/KYC. By learning the tx hash and output address, you
learn which addresses are associated with what real world entity is paying for
your service. You learning that information for what you claim is ~10% of all
transactions is a significant privacy concern. On that basiss alone, I would
argue that full-rbf should be implemented specifically to destroy your business
and stop the collection of that data.
> I am not at liberty to share names of other services which have developed
> their own 0-conf service - they include a payment processor on a gambling
> platform which services multiple gambling operators, a standalone gaming
> payment processor, and a payment processor recently I have come across. We
> also do not have a significant presence in Asia - so I don't have
> visibility there.
No, I asked you for information on what companies are actually using *your*
service. You claim to be involved with a huge % of all transactions. If that is
in fact true, obviously it shouldn't be hard to provide some examples of
merchants using GAP600 to accept unconfirmed txs.
> I don't see it being necessarily an either/or approach here. The risk
> looking to be mitigated with FullRBF seems to be able to be mitigated with
> FullRBF but with a swop limitation of at least the Inputs of Trx1 being in
> Trx2 - no flagging required. Added to this all these trxs always have the
> OptinRBF so if these platforms need to be able to recreate completely their
> trxs they have that option as well. The option to Swop out or bump up trxs
> seems to be well covered under those two options.
You are not correct. One of the most important use-cases for full-rbf is
multi-party transactions; adding that limitation to full-rbf negates that
usecase. See my post on why full-rbf makes DoS attacks on multiparty protocols
significantly more expensive:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html
--
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/20230113/bcc6cae8/attachment.sig>;
šļø Summary of this message: GAP600 is a service that enables clients to accept 0-conf transactions, accessed via API, and not based on AML/KYC, but it raises privacy concerns. Full-RBF should be implemented to stop the collection of data.
š Original message:On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
> GAP600 is not a trxs processor or liquidity provider we service merchants,
> payment processors & non-custodial liquidity providers - our service is
> purely the 0-conf enabling our clients to accept 0-conf. Clients access our
> service via API - sending us the Trx hash & output address. Our service is
> not based on AML/KYC it is purely an analysis of the Bitcoin network.
I checked and to sign up for your service, you ask for the name, phone number,
email, and company name.
That is an example of AML/KYC. By learning the tx hash and output address, you
learn which addresses are associated with what real world entity is paying for
your service. You learning that information for what you claim is ~10% of all
transactions is a significant privacy concern. On that basiss alone, I would
argue that full-rbf should be implemented specifically to destroy your business
and stop the collection of that data.
> I am not at liberty to share names of other services which have developed
> their own 0-conf service - they include a payment processor on a gambling
> platform which services multiple gambling operators, a standalone gaming
> payment processor, and a payment processor recently I have come across. We
> also do not have a significant presence in Asia - so I don't have
> visibility there.
No, I asked you for information on what companies are actually using *your*
service. You claim to be involved with a huge % of all transactions. If that is
in fact true, obviously it shouldn't be hard to provide some examples of
merchants using GAP600 to accept unconfirmed txs.
> I don't see it being necessarily an either/or approach here. The risk
> looking to be mitigated with FullRBF seems to be able to be mitigated with
> FullRBF but with a swop limitation of at least the Inputs of Trx1 being in
> Trx2 - no flagging required. Added to this all these trxs always have the
> OptinRBF so if these platforms need to be able to recreate completely their
> trxs they have that option as well. The option to Swop out or bump up trxs
> seems to be well covered under those two options.
You are not correct. One of the most important use-cases for full-rbf is
multi-party transactions; adding that limitation to full-rbf negates that
usecase. See my post on why full-rbf makes DoS attacks on multiparty protocols
significantly more expensive:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html
--
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/20230113/bcc6cae8/attachment.sig>;