Nostr notes by Daniel Lipshitz [ARCHIVE]

📅 Original date posted:2023-08-02 🗒️ Summary of this ...

2023-08-02T16:02:43Z

In reply to nevent1q…a6vd
_________________________

📅 Original date posted:2023-08-02
🗒️ Summary of this message: GAP600's research is based on monitoring transactions and network activity. They do not assess specific hashing pools or engage with clients for their names and applications. Coinpaid's root addresses can be validated using tools like Chainanlysis. It is possible to reach out to Max at Coinpaid to confirm GAP600's use. Changelly may not have implemented GAP600's service across all its offerings.
📝 Original message:
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.
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.
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.
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.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Wed, Aug 2, 2023 at 1:38 PM Daniel Lipshitz <daniel at gap600.com> 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.
>
> 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.
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
> Phone: +44 113 4900 117
> Skype: daniellipshitz123
> Twitter: @daniellipshitz
>
>
> On Wed, Aug 2, 2023 at 4:28 AM Peter Todd <pete at petertodd.org> wrote:
>
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/06762493/attachment.html>;

📅 Original date posted:2023-08-02 🗒️ Summary of this ...

2023-08-02T11:35:49Z

In reply to nevent1q…ltec
_________________________

📅 Original date posted:2023-08-02
🗒️ Summary of this message: The sender disputes the recipient's assessment of their dishonesty, stating that it is based on baseless assumptions and lacks commercial experience. They provide evidence to support their claims and challenge the recipient to provide concrete examples.
📝 Original message:
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.

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.
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Wed, Aug 2, 2023 at 4:28 AM Peter Todd <pete at petertodd.org> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/d6019818/attachment.html>;

📅 Original date posted:2023-08-01 🗒️ Summary of this ...

2023-08-02T10:19:21Z

In reply to nevent1q…ykd5
_________________________

📅 Original date posted:2023-08-01
🗒️ Summary of this message: The author claims that the research is not thorough and reaches an incorrect conclusion. They provide evidence of Coinspaid's use of 0-conf and offer to connect with the CEO for confirmation. They also mention speaking to Changelly for confirmation of GAP600 as a service provider. The author questions the need for full RBF and requests contacts of mining pools that have adopted it.
📝 Original message:
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.

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
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.

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.

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 ?

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Tue, Aug 1, 2023 at 6:04 PM Peter Todd <pete at petertodd.org> wrote:

> On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev
> wrote:
> > This would unnecessarily and extremely negatively impact merchants and
> > users who choose to accept 0-conf while using mitigation tools like
> GAP600.
> > This negative impact could be avoided by simply adding first seen safe
> rule
> > - ie a trx can be replaced but needs to include the original outputs.
> >
> > At GAP600 we continue to see strong use of our service for BTC we have
> seen
> > circa 350k unique trx hash per month (over the last 3 months) requested
> to
> > our platform. Our clients include - Coinpayments, Coinspaid and
> Changelly.
>
> I checked, and Coinpayments and Coinspaid are both merchant processors. I
> could
> not find any example of actual merchants using their platform accepting
> unconfirmed payments. I also could not find any documentation on their
> websites
> indicating unconfirmed transaction acceptance.
>
> As for Changelly, their website says right on the front that "With an
> average
> transaction speed of 5–40 minutes, we ensure you can swiftly take
> advantage of
> market opportunities." Obivously, 5 minutes is not an unconfirmed payment.
>
> Additionally, I verified myself by doing test transactions with BIP125
> disabled
> and an adequate fee: unconfirmed payments are not accepted by Changelly. As
> their exchange flow clearly says "Once BTC is confirmed in the blockchain,
> we’ll start exchanging it to <coin>."
>
> You need to provide an genuine example of an actual merchant who accepts
> unconfirmed transactions as payment, and actually relies on first-seen
> behavior.
>
> > We have not seen any impact of full RBF on double spend rates for our
> trxs
>
> Based on the above findings, this appears to be because you don't actually
> have
> any clients who rely on unconfirmed payments.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/5ea58940/attachment-0001.html>;

📅 Original date posted:2023-07-31 🗒️ Summary of this ...

2023-07-31T16:02:14Z

In reply to nevent1q…34cv
_________________________

📅 Original date posted:2023-07-31
🗒️ Summary of this message: The implementation of full Replace-by-Fee (RBF) could negatively impact merchants and users who rely on 0-conf transactions. GAP600 has seen strong usage of their service and believes the adoption of RBF will change their business.
📝 Original message:
This would unnecessarily and extremely negatively impact merchants and
users who choose to accept 0-conf while using mitigation tools like GAP600.
This negative impact could be avoided by simply adding first seen safe rule
- ie a trx can be replaced but needs to include the original outputs.

At GAP600 we continue to see strong use of our service for BTC we have seen
circa 350k unique trx hash per month (over the last 3 months) requested to
our platform. Our clients include - Coinpayments, Coinspaid and Changelly.
Given the period of Mempool being full we have seen an increase in the fee
required in order to be approved by our platform for trx. This is not an
insignificant use case and one which can be easily maintained as is.

We have provided further statistics in the past and direct feedback from
Coinspaid CEO with in the mailing list see here -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html

We have not seen any impact of full RBF on double spend rates for our trxs
which seems to put in large question the stated figure of 40% adoption by
miners at such a rate of adoption we would expect to see a large increase
in double spends. We expect once this setting becomes default this will
greatly change the adoption of this service.
GAP600 model targets not to get it wrong and as such we are very sensitive
to any double spend which we get wrong in predicting as we reimburse our
clients. GAP600 is not a payment processor; rather services payment
processors, merchants and non custodial liquidity providers which service
non-custodial wallets.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230731/af47128d/attachment.html>;

📅 Original date posted:2023-02-06 🗒️ Summary of this ...

2023-06-07T23:19:23Z

In reply to nevent1q…k067
_________________________

📅 Original date posted:2023-02-06
🗒️ Summary of this message: A company claims that it does not have any KYC/AML information or telephone number on who is sending its clients Bitcoin for deposit, and that more than 90% of its clients use different AML transaction analysis service providers for transactions deposited on their platforms.
📝 Original message:On Sat, Feb 4, 2023 at 6:28 PM Peter Todd <pete at petertodd.org> wrote:

> On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote:
> > We have standard commercial information about the payment processors, non
> > custodial liquidity providers and merchants which become our clients - we
> > do not have any kyc/aml information or telephone number on who is sending
> > our clients the bitcoin for deposit. For us these are just bitcoin Trx
> > which our clients choose to benefit from 0-conf deposit recognition. Our
> > service is provided via API with the only information our clients share
> > with us, regarding a specific bitcoin transaction, being public bitcoin
> > information like trx hash and output address.
>
> You know who your clients are, and thus every request for information on a
> transaction is reasonably likely to be a deposit associated with the
> client who
> requested it. Learning what addresses are associated with what entity is a
> significant benefit to Chainalysis operations, and there's every reason to
> expect that the data you learn will either be sold or leaked to Chainalysis
> companies.
>

I would estimate based on general discussions with clients and open
research more than 90% of our clients use different AML trx analysis
service providers for trx deposited on their platforms -
completely irrelevant to us or 0-conf. So if these clients were to stop
recognising 0-conf this would have no impact on these AML service providers
access to the data. We service payment processors and liquidity providers
and have little or no insight into which wallets or merchants our clients
service.

Further to this many of the cluster addresses of our clients and just like
other service providers in the bitcoin space are publicly known - just as
Max had no issue sharing the cluster of his deposit address in his email
which I posted to the list.

>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230206/ad228af5/attachment.html>;

📅 Original date posted:2023-01-17 🗒️ Summary of this ...

2023-06-07T23:18:37Z

In reply to nevent1q…y8yr
_________________________

📅 Original date posted:2023-01-17
🗒️ Summary of this message: 0-conf on Bitcoin is a significant use case, but it comes with risks. Full RBF may not change the risk profile, and observation of fee paid, history of doing business, and transaction size are needed. GAP600 provides 0-conf enabling service for merchants, payment processors, and non-custodial liquidity providers without AML/KYC.
📝 Original message:> > 0-conf on Bitcoin with its understood risks is a significant use case
>
> and that use case doesn't change, at all, with full rbf. the risk
> profile will, likely, remain the same. observation of the fee paid,
> history of doing business with the customer, transaction size are all
> needed.
>

Currently 0-conf recognition is done without any KYC on the payor, this
includes activities like, gaming, non-custodial trading and applications.
In general OptinRBF is not possible to offer 0-conf since as soon as it is
recognised it can be double spent. Full RBF would make all trxs just like
OptinRBF. FullRBF but with FSS implemented will still enable 0-conf
acceptance.

>
> On Mon, Jan 16, 2023 at 1:50 PM Daniel Lipshitz via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Some further clarity on our unique trx hashes queried to our platform,
>> our initial and followup numbers on unique trx hashes queried were not
>> accurate - apologies. Bitcoin addresses queried and Usd value and unique
>> were accurate. This is as a result of our platform viewing each queried
>> bitcoin address as a transaction from our point of view.
>>
>> November 2022
>> Total queried unique bitcoin address- circa 1.5m trxs
>> Unique Bitcoin trx hashes queried- circa 500k
>> USD value - circa 220m
>> December 2022
>> Total queried unique bitcoin address- circa 1.7m trxs
>> Unique Bitcoin trx hashes queried - circa 500k
>> USD value - circa 200m
>>
>> There are further merchants and service providers who enable 0-conf on
>> Bitcoin who are not working via our platform - I do not know their numbers
>> but believe they are significant. 0-conf on Bitcoin with its understood
>> risks is a significant use case.
>>
>> For third party clarification please see
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
>> and
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html
>> ________________________________
>>
>> Daniel Lipshitz
>> GAP600| www.gap600.com
>>
>>
>>
>>
>> On Sat, Jan 14, 2023 at 10:15 PM Daniel Lipshitz <daniel at gap600.com>
>> wrote:
>>
>>>
>>>
>>>
>>> On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete at petertodd.org> wrote:
>>>
>>>> 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.
>>>>
>>>> We have standard commercial information about the payment processors,
>>> non custodial liquidity providers and merchants which become our clients -
>>> we do not have any kyc/aml information or telephone number on who is
>>> sending our clients the bitcoin for deposit. For us these are just bitcoin
>>> Trx which our clients choose to benefit from 0-conf deposit recognition.
>>> Our service is provided via API with the only information our clients share
>>> with us, regarding a specific bitcoin transaction, being public bitcoin
>>> information like trx hash and output address.
>>>
>>> > 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.
>>>>
>>>
>>> As already posted here
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html
>>> Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see
>>> link, is available to discuss further and may choose to share further
>>> information on the merchants they support.
>>>
>>>>
>>>> > 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
>>>
>>>
>>> I also note that there is ongoing debate as to the need for full RBF see
>>> here
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html
>>> .
>>>
>>> This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF
>>> and common sense - offering enough coverage to mitigate.
>>>
>>> 0-conf although may not be liked by some actors in Bitcoin, is engaged
>>> with free choice and understanding of the risks. 0-conf is a long standing
>>> and significant use case which should not be ignored. 0-conf demise should
>>> be viewed as being a major and unnecessary cost to FullRBF as currently
>>> implemented.
>>>
>>>> --
>>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>>
>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230117/d31b7aba/attachment-0001.html>;

📅 Original date posted:2023-01-16 🗒️ Summary of this ...

2023-06-07T23:18:36Z

In reply to nevent1q…wf83
_________________________

📅 Original date posted:2023-01-16
🗒️ Summary of this message: GAP600 apologizes for inaccurate initial and follow-up numbers on unique trx hashes queried, but clarifies accurate USD value and unique bitcoin addresses queried. They enable 0-conf on Bitcoin for clients via API and do not require AML/KYC information. They estimate significant numbers of merchants and service providers who enable 0-conf on Bitcoin outside of their platform.
📝 Original message:Some further clarity on our unique trx hashes queried to our platform, our
initial and followup numbers on unique trx hashes queried were not accurate
- apologies. Bitcoin addresses queried and Usd value and unique were
accurate. This is as a result of our platform viewing each queried bitcoin
address as a transaction from our point of view.

November 2022
Total queried unique bitcoin address- circa 1.5m trxs
Unique Bitcoin trx hashes queried- circa 500k
USD value - circa 220m
December 2022
Total queried unique bitcoin address- circa 1.7m trxs
Unique Bitcoin trx hashes queried - circa 500k
USD value - circa 200m

There are further merchants and service providers who enable 0-conf on
Bitcoin who are not working via our platform - I do not know their numbers
but believe they are significant. 0-conf on Bitcoin with its understood
risks is a significant use case.

For third party clarification please see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html
________________________________

Daniel Lipshitz
GAP600| www.gap600.com

On Sat, Jan 14, 2023 at 10:15 PM Daniel Lipshitz <daniel at gap600.com> wrote:

>
>
>
> On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete at petertodd.org> wrote:
>
>> 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.
>>
>> We have standard commercial information about the payment processors, non
> custodial liquidity providers and merchants which become our clients - we
> do not have any kyc/aml information or telephone number on who is sending
> our clients the bitcoin for deposit. For us these are just bitcoin Trx
> which our clients choose to benefit from 0-conf deposit recognition. Our
> service is provided via API with the only information our clients share
> with us, regarding a specific bitcoin transaction, being public bitcoin
> information like trx hash and output address.
>
> > 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.
>>
>
> As already posted here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html
> Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see
> link, is available to discuss further and may choose to share further
> information on the merchants they support.
>
>>
>> > 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
>
>
> I also note that there is ongoing debate as to the need for full RBF see
> here
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html
> .
>
> This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF and
> common sense - offering enough coverage to mitigate.
>
> 0-conf although may not be liked by some actors in Bitcoin, is engaged
> with free choice and understanding of the risks. 0-conf is a long standing
> and significant use case which should not be ignored. 0-conf demise should
> be viewed as being a major and unnecessary cost to FullRBF as currently
> implemented.
>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230116/f3948317/attachment.html>;

📅 Original date posted:2023-01-14 🗒️ Summary of this ...

2023-06-07T23:18:35Z

In reply to nevent1q…2qe2
_________________________

📅 Original date posted:2023-01-14
🗒️ Summary of this message: GAP600 enables merchants to accept 0-conf transactions via API without AML/KYC. Privacy concerns arise as they collect data on real-world entities paying for their service. They claim to have a significant presence in transactions but do not disclose their clients. Full-RBF implementation is suggested to stop data collection.
📝 Original message:On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete at petertodd.org> wrote:

> 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.
>
> We have standard commercial information about the payment processors, non
custodial liquidity providers and merchants which become our clients - we
do not have any kyc/aml information or telephone number on who is sending
our clients the bitcoin for deposit. For us these are just bitcoin Trx
which our clients choose to benefit from 0-conf deposit recognition. Our
service is provided via API with the only information our clients share
with us, regarding a specific bitcoin transaction, being public bitcoin
information like trx hash and output address.

> 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.
>

As already posted here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html
Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see
link, is available to discuss further and may choose to share further
information on the merchants they support.

>
> > 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

I also note that there is ongoing debate as to the need for full RBF see
here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html
.

This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF and
common sense - offering enough coverage to mitigate.

0-conf although may not be liked by some actors in Bitcoin, is engaged with
free choice and understanding of the risks. 0-conf is a long standing and
significant use case which should not be ignored. 0-conf demise should be
viewed as being a major and unnecessary cost to FullRBF as currently
implemented.

> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230114/70440238/attachment-0001.html>;

📅 Original date posted:2022-12-14 📝 Original message:A ...

2023-06-07T23:17:47Z

In reply to nevent1q…w8c0
_________________________

📅 Original date posted:2022-12-14
📝 Original message:A 0-conf double spend caused by FSS-RBF would be harmless since the
original output (address and amounts) remain in the double spending trx.

So all a merchant would need to do is monitor block inclusion for the
relevant output. Addition of some wallet logic would resolve it easily.

Technically the only difference is that a FSS-RBF requires an additional
input trx to be included in the second trx.

Not clear to me, why the limitation of adding an additional input hinders
the added value of FullRBF and how significant that hinderance is.

On Tue, 13 Dec 2022 at 11:59 John Carvalho <john at synonym.to> wrote:

> Why wasn't this solution put in place back then? Are there problems with
> the design?
>
> While I still think there are unhealthy side-effects of Full-RBF (like
> more doublespending at unknowing merchants, after years of FSS protection)
> I think discussion of this FSS-RBF feature is worth considering.
>
> --
> John Carvalho
> CEO, Synonym.to <http://synonym.to/>;
>
>
> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel at gap600.com> wrote:
>
>> Thank you for bringing that to my attention, apologies for not being
>> aware of it.
>>
>> First-seen-safe replace-by-fee as detailed here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>> by Peter Todd seems to be a very suitable option and route
>> which balances FullRBF while retaining the significant 0-conf use case.
>>
>> This would seem like a good way forward.
>>
>>
>>
>> ________________________________
>>
>>
>>
>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch at woobling.org>
>> wrote:
>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>>
>> --
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221214/aa2e6d65/attachment-0001.html>;

📅 Original date posted:2022-12-18 📝 Original message:GAP600 ...

2023-06-07T23:17:46Z

In reply to nevent1q…9clt
_________________________

📅 Original date posted:2022-12-18
📝 Original message: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 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.

I see from the Wallet of Satoshis website that they are a custodial wallet
provider.

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.

The case of creating multiple wallets with the same seeds seems to be an
edge case - and to do that and then recreate accidental double spends as a
result sounds like an extreme edge case which I would not think should be a
protocol consideration.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Fri, Dec 16, 2022 at 11:14 PM Peter Todd <pete at petertodd.org> wrote:

> On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote:
> > > With multi-party transactions such as coinjoins and multi-party
> lightning
> > > channels, we want full-rbf behavior because it avoids accidental
> > > double-spends
> > > holding up progress in these protocols.
> >
> > what is meant by accidental double spends ? And do you have any data as
> to
> > how often these occur and would cause harm?
>
> A double-spend of an input to a multiparty transaction that isn't maximally
> trying to exploit transaction pinning. For example, Wasabi has found many
> cases
> of users imported the same seed into different wallets. This is quite hard
> to
> avoid in decentralized wallets.
>
> > Second, for intentional DoS attacks, it
> > > makes those attacks much more expensive by forcing the attacker to use
> > > tx-pinning.
> >
> > how are these Dos attacks mitigated today if Full RBF is not in place ?
>
> They aren't. During congested mempool conditions an attacker could cause
> significant delays to multi-party transactions without full-rbf.
> Fortunately,
> the mempool regularly empties right now. But that has not been true in the
> past, we can not guarantee that, and for Bitcoin to remain secure without
> inflation or demmurage in the future, we have to operate under
> full-mempools
> with significant backlogs of transactions.
>
> > > Thus we have a political tradeoff between a handful of centralized
> services
> > > such as yours that benefit from the first-seen status quo, and the much
> > > larger
> > > group of users that use Lightning and coinjoins.
> >
> > How many users are currently using Lightning and coinjoins today ?
>
> Wallet of Satoshi, one of many Lightning wallets, claims to be performing
> 12,500 transactions/day:
> https://twitter.com/kerooke/status/1603812141966016520
>
> Bitcoin as a whole currently does about 300,000 transactions per day(1).
> So that
> one single Lightning wallet represents roughly 4% of the total payment
> volume
> of Bitcoin. Wallet of Satoshi, BlueWallet, and SBW all have 100K+
> downloads on
> the Google Play store. So a reasonable guess is they're equally popular.
> Which
> means they collectively represent 12% of the total number of transactions
> on
> Bitcoin. You claimed GAP600 was queried for 900,000 unique tx hashes per
> month(2), or about 10% of total transactions.
>
>
> I don't have statistics for number of coinjoin transactions per day, or the
> blockspace used. But Wasabi have published (reproducable) data showing that
> currently about 750BTC/day are entering Wasabi 2.0 coinjoins:
> https://mobile.twitter.com/wasabiwallet/status/1603366008437325828
>
> You claimed GAP600 was responsible for USD $220 million of transaction
> volume(2), significantly less than the ~$400 million / month that Wasabi
> coinjoins alone represent. And of course, Wasabi is just one of three main
> coinjoin implementations.
>
> > > We've already been through
> > > such a political tradeoff before with the blocksize debate - again, the
> > > centralized payment providers lost the debate.
> >
> > I don’t think this has anything to do with block size debate or
> > decentralisation just looking to protect a significant use case that has
> > been in place - GAP600 is by no means the only service provider is this
> > place there are many merchants who do 0-conf on there own.
>
> You claimed that GAP600 handled about 10% of all transactions. Obviously,
> if
> that is true, that indicates a very high degree of centralization. It is
> extremely undesirable for Bitcoin for one single entity with, as I
> understand
> it, AML/KYC to handle 10% of all transactions. Probably an even higher
> percentage when you take into account that only a minority of transactions
> are
> merchant payment-type transactions where unconfirmed transactions would
> have
> any relevance at all.
>
> You claim that there are "many merchants" who do 0-conf on their own. Can
> you
> list more examples of those merchants? Surely if there are "many" of them,
> you
> could easily give us four or five more examples so this list can evaluate
> what
> kinds of security guarantees they're actually relying on.
>
> 1) https://ycharts.com/indicators/bitcoin_transactions_per_day
> 2)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221218/134b4266/attachment-0001.html>;

📅 Original date posted:2022-12-13 📝 Original message:On ...

2023-06-07T23:17:44Z

In reply to nevent1q…uqc5
_________________________

📅 Original date posted:2022-12-13
📝 Original message:On Tue, 13 Dec 2022 at 23:41 Peter Todd <pete at petertodd.org> wrote:

> On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> > I dont think there was anything technical with the implementation and as
> > far as I can tell this is well developed and ready.
>
> There are lots of problems with my first-seen-safe proposal. The only
> reason I
> proposed it in 2015 was as a political compromise.
>
> > The reasons I can find for not being adopted are listed here -
> > https://bitcoincore.org/en/faq/optin_rbf/ under - Why not
> First-seen-safe
> > Replace-by-fee
> >
> > Those reasons do not seem pertinent here - given OptinRBF already exists
> > as an option and the added benefit of continuing to be able to support
> > 0-conf.
>
> First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was
> merged into Bitcoin Core: multi-party transactions.
>
> With multi-party transactions such as coinjoins and multi-party lightning
> channels, we want full-rbf behavior because it avoids accidental
> double-spends
> holding up progress in these protocols.

what is meant by accidental double spends ? And do you have any data as to
how often these occur and would cause harm?

Second, for intentional DoS attacks, it
> makes those attacks much more expensive by forcing the attacker to use
> tx-pinning.

how are these Dos attacks mitigated today if Full RBF is not in place ?

>
>
> Nothing less than full-rbf without restritions on outputs works for this
> use-case. The only compromise possible is Antoine Riard's spent-nVersion
> signalling proposal¹, which has a significant, negative, privacy impact².
> It
> also increases costs and time in many cases, as you often have to create
> new
> outputs to flag full-rbf.
>
> Thus we have a political tradeoff between a handful of centralized services
> such as yours that benefit from the first-seen status quo, and the much
> larger
> group of users that use Lightning and coinjoins.

How many users are currently using Lightning and coinjoins today ?

> We've already been through
> such a political tradeoff before with the blocksize debate - again, the
> centralized payment providers lost the debate.

I don’t think this has anything to do with block size debate or
decentralisation just looking to protect a significant use case that has
been in place - GAP600 is by no means the only service provider is this
place there are many merchants who do 0-conf on there own.

>
>
>
> Anyway, my advice to you is to either change your business model to make
> use of
> scalable instant payment tech such as Lightning. Or give up on Bitcoin and
> expand your business with other chians, such as BSV³. The fact is some
> hashing
> power is already beginning to run with full-rbf⁴, and I fully expect that
> % to
> increase over time.
>
> 1)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
> 2)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html
> 3) https://www.gap600.com/bitcoin/gap600-supports-bsv/
> 4)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/5169f876/attachment.html>;

📅 Original date posted:2022-12-13 📝 Original message:This ...

2023-06-07T23:17:43Z

In reply to nevent1q…5upn
_________________________

📅 Original date posted:2022-12-13
📝 Original message:This would not effect optinrbf only fullRBF

On Tue, 13 Dec 2022 at 16:00 Lucas Ontivero <lucasontivero at gmail.com> wrote:

> Some wallets like Electrum would be affected by that because they use RBF
> to batch transactions so, outputs cannot be exactly the same as before.
>
> On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I dont think there was anything technical with the implementation and as
>> far as I can tell this is well developed and ready.
>>
>> The reasons I can find for not being adopted are listed here -
>> https://bitcoincore.org/en/faq/optin_rbf/ under - Why not
>> First-seen-safe Replace-by-fee
>>
>> Those reasons do not seem pertinent here - given OptinRBF already exists
>> as an option and the added benefit of continuing to be able to support
>> 0-conf.
>>
>> ________________________________
>>
>> Daniel Lipshitz
>> GAP600| www.gap600.com
>> Phone: +44 113 4900 117
>> Skype: daniellipshitz123
>> Twitter: @daniellipshitz
>>
>>
>> On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john at synonym.to> wrote:
>>
>>> Why wasn't this solution put in place back then? Are there problems with
>>> the design?
>>>
>>> While I still think there are unhealthy side-effects of Full-RBF (like
>>> more doublespending at unknowing merchants, after years of FSS protection)
>>> I think discussion of this FSS-RBF feature is worth considering.
>>>
>>> --
>>> John Carvalho
>>> CEO, Synonym.to <http://synonym.to/>;
>>>
>>>
>>> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel at gap600.com>
>>> wrote:
>>>
>>>> Thank you for bringing that to my attention, apologies for not being
>>>> aware of it.
>>>>
>>>> First-seen-safe replace-by-fee as detailed here
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>>> by Peter Todd seems to be a very suitable option and route
>>>> which balances FullRBF while retaining the significant 0-conf use case.
>>>>
>>>> This would seem like a good way forward.
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>>
>>>>
>>>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch at woobling.org>
>>>> wrote:
>>>>
>>>>>
>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>>>>
>>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/2d2e901c/attachment.html>;

📅 Original date posted:2022-12-13 📝 Original message:I dont ...

2023-06-07T23:17:43Z

In reply to nevent1q…3fff
_________________________

📅 Original date posted:2022-12-13
📝 Original message:I dont think there was anything technical with the implementation and as
far as I can tell this is well developed and ready.

The reasons I can find for not being adopted are listed here -
https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe
Replace-by-fee

Those reasons do not seem pertinent here - given OptinRBF already exists
as an option and the added benefit of continuing to be able to support
0-conf.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john at synonym.to> wrote:

> Why wasn't this solution put in place back then? Are there problems with
> the design?
>
> While I still think there are unhealthy side-effects of Full-RBF (like
> more doublespending at unknowing merchants, after years of FSS protection)
> I think discussion of this FSS-RBF feature is worth considering.
>
> --
> John Carvalho
> CEO, Synonym.to <http://synonym.to/>;
>
>
> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel at gap600.com> wrote:
>
>> Thank you for bringing that to my attention, apologies for not being
>> aware of it.
>>
>> First-seen-safe replace-by-fee as detailed here
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>> by Peter Todd seems to be a very suitable option and route
>> which balances FullRBF while retaining the significant 0-conf use case.
>>
>> This would seem like a good way forward.
>>
>>
>>
>> ________________________________
>>
>>
>>
>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch at woobling.org>
>> wrote:
>>
>>>
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/6f6bc8d1/attachment-0001.html>;

📅 Original date posted:2022-12-13 📝 Original message:Thank ...

2023-06-07T23:17:42Z

In reply to nevent1q…jz66
_________________________

📅 Original date posted:2022-12-13
📝 Original message:Thank you for bringing that to my attention, apologies for not being aware
of it.

First-seen-safe replace-by-fee as detailed here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
by Peter Todd seems to be a very suitable option and route which balances
FullRBF while retaining the significant 0-conf use case.

This would seem like a good way forward.

________________________________

On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch at woobling.org>
wrote:

>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/c757eb76/attachment-0001.html>;

📅 Original date posted:2022-12-11 📝 Original message:Intro ...

2023-06-07T23:17:41Z

In reply to nevent1q…rygg
_________________________

📅 Original date posted:2022-12-11
📝 Original message:Intro
Currently there is a significant use case of 0-Conf acceptance of
transactions. Merchants and service providers are fully aware of the risks
related to 0-conf. Full RBF if it would be significantly enabled would most
likely make 0-conf not possible and significantly limit this current use
case. A primary motivation for full RBF is to enable an increase of fee of
trxs and enable faster acceptance in Block should it be required.

Motivation
To enable full RBF adoption without this impeding the 0-conf use case. This
can be done by enabling the primary use of case full RBF i.e increase the
fee, while keeping the outputs of TRX1 to be included within TRX2.

Method
TRX1 is the trx first published and held in Mempool, TRX2 is the trx which
comes to replace TRX1.

In order for a TRX2 to replace TRX1 in the Mempool it will require the
following

- 1. Outputs (addresses and amounts) are the same TRX1 and TRX2

Or

- 2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional
Outputs to TRX1

Both cases would require the addition of at least one Input in order to
increase the fee.

In such a case 0-conf acceptance of TRX1 will result in a harmless double
spend since TRX1 will not be included in the valid UTXO set; however
the address beneficiaries of TRX1 will still be credited by TRX2.

This rule would enable the increasing of network fees post publication of
trx without the loss of 0-conf use case.

Drawbacks
Does require access to another Input inorder to take advantage of Full RBF.

Summary
Access to OptinRBF and FullRBF(with above limitation) would give actors
full access to increasing fees as an option. The 0-conf whose risks are
very much understood in the market can continue to exist as is, with the
0-conf ongoing choices being continuing to be available to actors.
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221211/8df6a99e/attachment.html>;

📅 Original date posted:2022-12-03 📝 Original message:See ...

2023-06-07T23:17:16Z

In reply to nevent1q…x0y7
_________________________

📅 Original date posted:2022-12-03
📝 Original message:See below feedback from CEO of Coinspaid Re - Bitcoin Zero conf market value
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

---------- Forwarded message ---------
From: Max Krupyshev <max at coinspaid.com>
Date: Sat, Dec 3, 2022 at 3:52 PM
Subject: Zero conf advantages for business
To: Daniel Lipshitz <daniel at gap600.com>

Hi Daniel,

Hope you are doing fine. I know you are in discussions with Bitcoin Core
team or RBF updates.
With current email, wanted to confirm that we are running quite a big
Bitcoin payment operation with over 300k incoming transactions, with 700+
inputs a month. Which is a fair percentage of overall BTC chain capacity
and we do enjoy zero conf flows that you offer. Our clients do like to give
instant experience to their end customers, I would not want to disappoint
them with news that “waiting for confirmations” is on a table again, after
all these years of smooth experience.

2 main production clusters are rotating around:
3JodN7GmkHdPgKj9G7HCkn9NDLhrcWCjVN
3QKCocNhzAgtgFLsD5qUZcG6e4TkfRf421

Kind regards,
Max Krupyshev
Founder & Leader
coinspaid.com // cryptoprocessing.com
Berlin, Germany
telegram: mkrupyshev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221203/fb742b43/attachment-0001.html>;

📅 Original date posted:2022-12-03 📝 Original message:Just a ...

2023-06-07T23:17:15Z

In reply to nevent1q…yryk
_________________________

📅 Original date posted:2022-12-03
📝 Original message:Just a further follow up here please see below feedback from Max CEO of
Coinspaid - I asked him to send me a mail.

Peter - I can understand why some of our statistics seems off, some of our
clients when they have multiple outputs going to their cluster will query
each trx hash with a separate output address as for them they need each trx
or output deposit covered/guaranteed so we would count that trx hash each
time it is queried with a different output address as a trxs - this would
mean that value of our total processed is possibly a more
reflective indicator. Apologies for this inclarity we are not used to
communicating our statistics at all - its just not our nature.

I would think looking at Nov 2022 Stats - 900k unique trx hashes queried,
with 1.5m trxs on our count since trx hashes are queried with different
output addresses. The actual value is USD 220M benefiting from zero conf
acceptance.

See Maxes email below - I will also forward the email as is to the list

Hi Daniel,

Hope you are doing fine. I know you are in discussions with Bitcoin Core
team or RBF updates.
With current email, wanted to confirm that we are running quite a big
Bitcoin payment operation with over 300k incoming transactions, with 700+
inputs a month. Which is a fair percentage of overall BTC chain capacity
and we do enjoy zero conf flows that you offer. Our clients do like to give
instant experience to their end customers, I would not want to disappoint
them with news that “waiting for confirmations” is on a table again, after
all these years of smooth experience.

2 main production clusters are rotating around:
3JodN7GmkHdPgKj9G7HCkn9NDLhrcWCjVN
3QKCocNhzAgtgFLsD5qUZcG6e4TkfRf421

Kind regards,
Max Krupyshev
Founder & Leader
coinspaid.com // cryptoprocessing.com
Berlin, Germany
telegram: mkrupyshev
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Sat, Dec 3, 2022 at 3:17 PM Daniel Lipshitz <daniel at gap600.com> wrote:

> The statistics that I have stated are based on trxs that rely on our tool.
> They are not overstated, this is a reflection of the 0conf market on BTC.
>
> They are trxs which our clients query via the API and which I clients pay
> subscription for.
>
> There is no point for clients to send us trxs they don’t want or need our
> response from. We are a B2b provider so we are not sure how and who the end
> users and applications are.
>
> Coinify definitely doesn’t send us all their traffic, as I would think
> some of our other clients.
>
> Here is some external confirmation a bit old though but still-
> https://blog.coinpayments.net/news-features/gap600
> You can also see our video of Coinspaid using our service on our site -
> all our Marcom is a bit old.
>
> We service primarily payment processors and liquidity providers and not
> end merchants so I can’t say how and to who end clients implement it.
>
> If AML/KYC was enough to prevent double spends all exchanges would offer
> 0conf.
>
> I don’t know the split with our clients as it’s non of our business but
> definitely a significant amount of end users are not Kyced for the trxs.
>
> Best would be to try and talk to some of our major clients - ie
> Coinpayments, Coinspaid and Coinify.
>
>
>
> On Sat, 3 Dec 2022 at 14:12 Peter Todd <pete at petertodd.org> wrote:
>
>> On Sat, Dec 03, 2022 at 01:01:16PM +0200, Daniel Lipshitz wrote:
>> > Shapeshift used to be clients in fact one of our first when we started
>> in
>> > 2016.
>> >
>> > They no longer use our service but from time to time use us for fee
>> > recommendations. So we actually should remove their logo as a current
>> > client.
>>
>> Yes you should. When did ShapeShift stop using your service? Did they
>> explain
>> why?
>>
>> > If you wish to test it out try find a merchant using Coinpayments or
>> > Coinspaid.
>> >
>> > Also some of our non custodial liquidity providers offer service no
>> > custodial wallets. I am not sure which.
>>
>> I see that you also advertise that Gap600 is "Trusted by" Coindirect and
>> Coinify, both AML/KYC crypto exchanges. Obviously, with full AML/KYC
>> double-spends are not much of a concern. And it's not even clear that
>> either accepts zeroconf anyway, as I'll explain later.
>>
>> On this list you claimed that:
>>
>> > 1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>> > 15M transactions
>> > 2. These transactions have a cumulative value of 2.3B USD value.
>> > 3. We currently are seeing circa 1.5M transactions queired per month.
>>
>> What's the value and number of transactions that *actually* rely on your
>> unconfirmed transaction tools? The only category that would apply for is
>> goods
>> provided immediately and irrovocably, without AML/KYC. Because it sounds
>> like
>> these figures may be significantly overstated.
>>
>>
>> Re: CoinsPaid, what you say here makes it also sound like it relies on
>> AML/KYC:
>>
>> > CoinsPaid applies a special software tool across its solutions to
>> conduct
>> > stringent KYC procedures and a risk-based approach to CDD that verify
>> user
>> > identities to mitigate fraud, money laundering and other activities
>> linked to
>> > criminality and terrorism.
>> https://www.gap600.com/uncategorized/coinspaid/
>>
>> Re: Coindirect, the documentation I can find appears to say that
>> confirmations
>> are required before you can use coins deposited into Coindirect:
>>
>> > Digital currency transactions must be confirmed on the relevant network
>> block
>> > before they are considered valid. Only once confirmed, will you be able
>> to
>> > use the coins deposited in your Coindirect wallet.
>>
>> https://help.coindirect.com/hc/en-us/articles/115002441974-How-quickly-can-I-use-coins-deposited-into-my-Coindirect-wallet-
>>
>> This is repeated here as well:
>> https://help.coindirect.com/hc/en-us/articles/4409120006546--Deposits-
>>
>> Re: Coinify, the API docs don't give any indication of risk scoring or any
>> other Gap600 integration:
>>
>> https://merchant.coinify.com/docs/api/#payment-object
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> --
> ________________________________
> Daniel Lipshitz
> GAP600
> www.Gap600.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221203/4ce7fd06/attachment-0001.html>;

📅 Original date posted:2022-12-03 📝 Original message:The ...

2023-06-07T23:17:14Z

In reply to nevent1q…77fj
_________________________

📅 Original date posted:2022-12-03
📝 Original message:The statistics that I have stated are based on trxs that rely on our tool.
They are not overstated, this is a reflection of the 0conf market on BTC.

They are trxs which our clients query via the API and which I clients pay
subscription for.

There is no point for clients to send us trxs they don’t want or need our
response from. We are a B2b provider so we are not sure how and who the end
users and applications are.

Coinify definitely doesn’t send us all their traffic, as I would think some
of our other clients.

Here is some external confirmation a bit old though but still-
https://blog.coinpayments.net/news-features/gap600
You can also see our video of Coinspaid using our service on our site - all
our Marcom is a bit old.

We service primarily payment processors and liquidity providers and not end
merchants so I can’t say how and to who end clients implement it.

If AML/KYC was enough to prevent double spends all exchanges would offer
0conf.

I don’t know the split with our clients as it’s non of our business but
definitely a significant amount of end users are not Kyced for the trxs.

Best would be to try and talk to some of our major clients - ie
Coinpayments, Coinspaid and Coinify.

On Sat, 3 Dec 2022 at 14:12 Peter Todd <pete at petertodd.org> wrote:

> On Sat, Dec 03, 2022 at 01:01:16PM +0200, Daniel Lipshitz wrote:
> > Shapeshift used to be clients in fact one of our first when we started in
> > 2016.
> >
> > They no longer use our service but from time to time use us for fee
> > recommendations. So we actually should remove their logo as a current
> > client.
>
> Yes you should. When did ShapeShift stop using your service? Did they
> explain
> why?
>
> > If you wish to test it out try find a merchant using Coinpayments or
> > Coinspaid.
> >
> > Also some of our non custodial liquidity providers offer service no
> > custodial wallets. I am not sure which.
>
> I see that you also advertise that Gap600 is "Trusted by" Coindirect and
> Coinify, both AML/KYC crypto exchanges. Obviously, with full AML/KYC
> double-spends are not much of a concern. And it's not even clear that
> either accepts zeroconf anyway, as I'll explain later.
>
> On this list you claimed that:
>
> > 1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
> > 15M transactions
> > 2. These transactions have a cumulative value of 2.3B USD value.
> > 3. We currently are seeing circa 1.5M transactions queired per month.
>
> What's the value and number of transactions that *actually* rely on your
> unconfirmed transaction tools? The only category that would apply for is
> goods
> provided immediately and irrovocably, without AML/KYC. Because it sounds
> like
> these figures may be significantly overstated.
>
>
> Re: CoinsPaid, what you say here makes it also sound like it relies on
> AML/KYC:
>
> > CoinsPaid applies a special software tool across its solutions to conduct
> > stringent KYC procedures and a risk-based approach to CDD that verify
> user
> > identities to mitigate fraud, money laundering and other activities
> linked to
> > criminality and terrorism.
> https://www.gap600.com/uncategorized/coinspaid/
>
> Re: Coindirect, the documentation I can find appears to say that
> confirmations
> are required before you can use coins deposited into Coindirect:
>
> > Digital currency transactions must be confirmed on the relevant network
> block
> > before they are considered valid. Only once confirmed, will you be able
> to
> > use the coins deposited in your Coindirect wallet.
>
> https://help.coindirect.com/hc/en-us/articles/115002441974-How-quickly-can-I-use-coins-deposited-into-my-Coindirect-wallet-
>
> This is repeated here as well:
> https://help.coindirect.com/hc/en-us/articles/4409120006546--Deposits-
>
> Re: Coinify, the API docs don't give any indication of risk scoring or any
> other Gap600 integration:
>
> https://merchant.coinify.com/docs/api/#payment-object
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221203/138ef429/attachment-0001.html>;

📅 Original date posted:2022-12-03 📝 Original message:Can ...

2023-06-07T23:17:13Z

In reply to nevent1q…t66u
_________________________

📅 Original date posted:2022-12-03
📝 Original message:Can also set you up with a trial account - interface is via API - just let
me know which email you wish for me to use and I will send over an
activation link which is active for 24 hours.

Happy to do it for other members list as well.

On Sat, 3 Dec 2022 at 13:01 Daniel Lipshitz <daniel at gap600.com> wrote:

> Shapeshift used to be clients in fact one of our first when we started in
> 2016.
>
> They no longer use our service but from time to time use us for fee
> recommendations. So we actually should remove their logo as a current
> client.
>
> If you wish to test it out try find a merchant using Coinpayments or
> Coinspaid.
>
> Also some of our non custodial liquidity providers offer service no
> custodial wallets. I am not sure which.
>
> On Sat, 3 Dec 2022 at 10:50 Peter Todd <pete at petertodd.org> wrote:
>
>> On Fri, Dec 02, 2022 at 09:06:26AM +0200, Daniel Lipshitz wrote:
>> > Yes I can see how that is not clear, apologies.
>> >
>> > Just BTC.
>> > From Jan1 2022 up till end of November 2022 GAP600 has processed circa
>> 15M
>> > trxs. With a value of 2.3B USD.
>> > In 2021 we did - circa 12.5M.
>> > In 2020 we did circa 6.5M.
>> >
>> > We have been in production since 2016 and working on the project since
>> > 2014/2015.
>>
>> Thanks.
>>
>> I note on your website that you claim ShapeShift is one of your clients.
>> I just
>> checked and ShapeShift appears to wait for a confirmation before allowing
>> a
>> trade when funded with a high-fee, non-opt-in-rbf transaction.
>>
>> What exactly is the service that you are providing for ShapeShift?
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> --
> ________________________________
> Daniel Lipshitz
> GAP600
> www.Gap600.com
>
>
> --
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221203/13468447/attachment.html>;

📅 Original date posted:2022-12-03 📝 Original ...

2023-06-07T23:17:13Z

In reply to nevent1q…4yzc
_________________________

📅 Original date posted:2022-12-03
📝 Original message:Shapeshift used to be clients in fact one of our first when we started in
2016.

They no longer use our service but from time to time use us for fee
recommendations. So we actually should remove their logo as a current
client.

If you wish to test it out try find a merchant using Coinpayments or
Coinspaid.

Also some of our non custodial liquidity providers offer service no
custodial wallets. I am not sure which.

On Sat, 3 Dec 2022 at 10:50 Peter Todd <pete at petertodd.org> wrote:

> On Fri, Dec 02, 2022 at 09:06:26AM +0200, Daniel Lipshitz wrote:
> > Yes I can see how that is not clear, apologies.
> >
> > Just BTC.
> > From Jan1 2022 up till end of November 2022 GAP600 has processed circa
> 15M
> > trxs. With a value of 2.3B USD.
> > In 2021 we did - circa 12.5M.
> > In 2020 we did circa 6.5M.
> >
> > We have been in production since 2016 and working on the project since
> > 2014/2015.
>
> Thanks.
>
> I note on your website that you claim ShapeShift is one of your clients. I
> just
> checked and ShapeShift appears to wait for a confirmation before allowing a
> trade when funded with a high-fee, non-opt-in-rbf transaction.
>
> What exactly is the service that you are providing for ShapeShift?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221203/6397770d/attachment.html>;

📅 Original date posted:2022-12-02 📝 Original message:Yes I ...

2023-06-07T23:17:12Z

In reply to nevent1q…c8xp
_________________________

📅 Original date posted:2022-12-02
📝 Original message:Yes I can see how that is not clear, apologies.

Just BTC.
>From Jan1 2022 up till end of November 2022 GAP600 has processed circa 15M
trxs. With a value of 2.3B USD.
In 2021 we did - circa 12.5M.
In 2020 we did circa 6.5M.

We have been in production since 2016 and working on the project since
2014/2015.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Fri, Dec 2, 2022 at 6:30 AM Peter Todd <pete at petertodd.org> wrote:

> On Thu, Dec 01, 2022 at 02:27:16PM +0200, Daniel Lipshitz via bitcoin-dev
> wrote:
> > Statistics for consideration as a sample of the zero conf use case -
> >
> >
> > 1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
> > 15M transactions
> > 2. These transactions have a cumulative value of 2.3B USD value.
> > 3. We currently are seeing circa 1.5M transactions queired per month.
>
> I'm curious, what are the time frames involved in those figures? Eg 15M txs
> over how long?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221202/f7c57455/attachment-0001.html>;

📅 Original date posted:2022-12-02 📝 Original message:HI ...

2023-06-07T23:17:11Z

In reply to nevent1q…fmtd
_________________________

📅 Original date posted:2022-12-02
📝 Original message:HI Antoine

Thank you for all the references - I agree with Sergej
statement "opportunity makes the thief"

The 1.5M trxs are all BTC which our clients query, I dont have specifics
for those trxs i.e. reasons for not being confirmed. However we target to
achieve +90% confirmation of trxs for our clients. Fee rates the
transactions generally follow standard fee/rate policy similar to all
industry recommendations, we recommend higher priority fee rate but approve
trxs well below that level. I would say we havent seen a trx with medium
fee rate be double spend - this is excluding race attacks or as you
mentioned ancestral unconfirmed attacks.

Opt in RBF is used in many ways to try to do double spends - i.e with
ancestral attacks inputs which are not confirmed, and also publishing the
RBF first and then the straight trxs later. In general double spends excl
Optin RBF does not occur alot at all - but the presence of a potential risk
causes everyone to wait back for confirmations.

Looking at a sample of latest 4.3M trxs, I can see crica 11k trxs which
seem to be double spent vast majority of these will be RBF, also on trx
that are high risk and we dont confirm the attacker has no incentive to
follow through with the second trxs.

I see quite a bit of reference to the benefit to miners for RBF - I would
think this cash flow benefit is not significant but I would suggest getting
input from a miner themselves.

Best
Daniel

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Fri, Dec 2, 2022 at 3:52 AM Antoine Riard <antoine.riard at gmail.com>
wrote:

> Hi Daniel,
>
> From my understanding of GAP600, you're operating a zero-conf risk
> analysis business, which is integrated and leveraged by payment
> processors/liquidity providers and merchants. A deployment of fullrbf by
> enough full-node operators and a subset of the mining hashrate would lower
> the cost of double-spend attack by lamda users, therefore increasing the
> risk exposure of your users. This increased risk exposure could lead you to
> alter the acceptance of incoming zero-conf transactions, AFAICT in a
> similar reasoning as exposed by Bitrefill earlier this year [0].
>
> About the statistics you're asking for considerations, few further
> questions, on those 1.5M transactions per month, a) how many are
> Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
> are excluded from zeroconf due to factors like RBF, long-chain of
> unconfirmed ancestors or too high-value and c) what has been the average
> feerate (assuming a standard size of 200 bytes) ?
>
> My personal position on fullrbf is still the same as expressed in #26525
> [1]. As a community, I think we still don't have conceptual consensus on
> deploying full-rbf, neither to remove it. In the direction of removing the
> current option from Bitcoin Core, I think the prerequisite to address are
> the qualification of enough economic flows at risk and the presence of a
> sizable loss in miners income. Beyond that, I think there is still the open
> question if we (we, as the Bitcoin protocol development community, with all
> its stakeholders) should restrain user choice in policy settings in the
> name of preserving mining income and established use-case stability.
>
> To recall, the original technical motivation of this option, and the wider
> smoother deployment was to address a DoS vector affecting another class of
> use-case: multi-party transactions like coinjoin and contracting protocols
> like Lightning [2] [3]. All of them expect to generate economic flows and
> corresponding mining income. Since then, alternative paths to solve this
> DoS vector have been devised, all with their own trade-offs and conceptual
> issues [4] [5].
>
> Best,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html
> [1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
>
> Le jeu. 1 déc. 2022 à 07:32, Daniel Lipshitz via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> HI All
>>
>> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
>> crypto transactions, BTC is a primary part of our business. Our guarantee
>> enables our customers to recognise zero-conf deposits. We reimburse our
>> clients value of the trx should we get it wrong and a transaction we
>> confirmed gets double spent.
>>
>> Should full RBF become default enabled and significantly adopted this
>> would have a major impact on the capacity to accept zerof confs on mainnet.
>> With the end result being this use case will be forced to move to a
>> different chain, with lightning being just another option.
>>
>> I wanted to share some statistics about how significant this use case is.
>> GAP600 clients are primarily payment processors and non custodial
>> liquidity providers; you can see some of our clients on our site
>> www.gap600.com. There are also merchants who have developed their own
>> tools so GAP600 statistics are only a subset of the full use case.
>>
>> I do not know of any wallet, exchange or custodian who accepts zero conf
>> without having some sort of solution in place. The market seems to be fully
>> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
>> gives a clear free choice for actors.
>>
>> Statistics for consideration as a sample of the zero conf use case -
>>
>>
>> 1. As of end of Nov 2022 - GAP600 has processed i.e responded to
>> circa 15M transactions
>> 2. These transactions have a cumulative value of 2.3B USD value.
>> 3. We currently are seeing circa 1.5M transactions queired per month.
>>
>>
>> It's a sizable amount of trxs on mainet and we are by no means the full
>> market of platforms accepting zero-conf. I realise there are other
>> considerations which BTC has, I would urge you to take into account the
>> major risk being placed on this significant market share when deciding to
>> make this feature default enabled and encouraging full adoption.
>>
>> Thank you for your consideration
>> Daniel
>> ________________________________
>>
>> Daniel Lipshitz
>> GAP600| www.gap600.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221202/9b026be3/attachment-0001.html>;

📅 Original date posted:2022-12-02 📝 Original message:If ...

2023-06-07T23:17:10Z

In reply to nevent1q…gpp5
_________________________

📅 Original date posted:2022-12-02
📝 Original message:If fullRBF would become default and this would become dominant, zero-conf
acceptance would become extremely difficult and would impact significantly
this market share because its not the everyday users who would actually
worry about it however the attackers would be all over it.

As it is today the network has brief periods of stress when trxs are
delayed but in general clears regularly and from time to time there is
stress. Today actors' wallets and merchants etc already have the option of
RBF.
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

On Fri, Dec 2, 2022 at 12:04 AM Erik Aronesty <erik at q32.com> wrote:

> There has never been any enforcement of miner preferences. The
> convention is changing quickly, since miners are squeezed for cash and want
> to capture every nickel, plus there are bounties for full rbf being posted
> every day.
>
> I would suggest considering to continue doing business, as usual, as if
> full rbf is present.
>
> This means:
>
> - managing risk
> - waiting for confirmations if the risk is too high
> - using lightning if possible
>
> No other coin or chain offers a safer way to do business than lightning
> over bitcoin.
>
>
>
>
> On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshitz via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> HI All
>>
>> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
>> crypto transactions, BTC is a primary part of our business. Our guarantee
>> enables our customers to recognise zero-conf deposits. We reimburse our
>> clients value of the trx should we get it wrong and a transaction we
>> confirmed gets double spent.
>>
>> Should full RBF become default enabled and significantly adopted this
>> would have a major impact on the capacity to accept zerof confs on mainnet.
>> With the end result being this use case will be forced to move to a
>> different chain, with lightning being just another option.
>>
>> I wanted to share some statistics about how significant this use case is.
>> GAP600 clients are primarily payment processors and non custodial
>> liquidity providers; you can see some of our clients on our site
>> www.gap600.com. There are also merchants who have developed their own
>> tools so GAP600 statistics are only a subset of the full use case.
>>
>> I do not know of any wallet, exchange or custodian who accepts zero conf
>> without having some sort of solution in place. The market seems to be fully
>> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
>> gives a clear free choice for actors.
>>
>> Statistics for consideration as a sample of the zero conf use case -
>>
>>
>> 1. As of end of Nov 2022 - GAP600 has processed i.e responded to
>> circa 15M transactions
>> 2. These transactions have a cumulative value of 2.3B USD value.
>> 3. We currently are seeing circa 1.5M transactions queired per month.
>>
>>
>> It's a sizable amount of trxs on mainet and we are by no means the full
>> market of platforms accepting zero-conf. I realise there are other
>> considerations which BTC has, I would urge you to take into account the
>> major risk being placed on this significant market share when deciding to
>> make this feature default enabled and encouraging full adoption.
>>
>> Thank you for your consideration
>> Daniel
>> ________________________________
>>
>> Daniel Lipshitz
>> GAP600| www.gap600.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221202/ed67276b/attachment-0001.html>;

📅 Original date posted:2022-12-01 📝 Original message:HI All ...

2023-06-07T23:17:09Z

In reply to nevent1q…mypf
_________________________

📅 Original date posted:2022-12-01
📝 Original message:HI All

I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
crypto transactions, BTC is a primary part of our business. Our guarantee
enables our customers to recognise zero-conf deposits. We reimburse our
clients value of the trx should we get it wrong and a transaction we
confirmed gets double spent.

Should full RBF become default enabled and significantly adopted this would
have a major impact on the capacity to accept zerof confs on mainnet. With
the end result being this use case will be forced to move to a different
chain, with lightning being just another option.

I wanted to share some statistics about how significant this use case is.
GAP600 clients are primarily payment processors and non custodial
liquidity providers; you can see some of our clients on our site
www.gap600.com. There are also merchants who have developed their own tools
so GAP600 statistics are only a subset of the full use case.

I do not know of any wallet, exchange or custodian who accepts zero conf
without having some sort of solution in place. The market seems to be fully
aware of the risks of zero-conf. The opt-RBF seems to be a solution which
gives a clear free choice for actors.

Statistics for consideration as a sample of the zero conf use case -

1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
15M transactions
2. These transactions have a cumulative value of 2.3B USD value.
3. We currently are seeing circa 1.5M transactions queired per month.

It's a sizable amount of trxs on mainet and we are by no means the full
market of platforms accepting zero-conf. I realise there are other
considerations which BTC has, I would urge you to take into account the
major risk being placed on this significant market share when deciding to
make this feature default enabled and encouraging full adoption.

Thank you for your consideration
Daniel
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221201/cfe5b3d1/attachment.html>;