Daniel Lipshitz [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-12-01 to 2023-02-06
💬 Posted a total of 20 messages
📚 Participated in the following categories: bitcoin-dev, Opt-in full-RBF
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-08-02 16:02:43

- reply

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

2023-08-02 11:35:49

- reply

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

2023-08-02 10:19:21

- reply

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

2023-07-31 16:02:14

- reply

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

2023-06-07 23:17:47

- reply

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

2023-06-07 23:17:44

- reply

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

2023-06-07 23:17:43

- reply

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

2023-06-07 23:17:43

- reply

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

2023-06-07 23:17:42

- reply

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

2023-06-07 23:17:41

- reply

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

2023-06-07 23:17:15

- reply

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

2023-06-07 23:17:14

- reply

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

2023-06-07 23:17:13

- reply

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

2023-06-07 23:17:13

- reply

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

2023-06-07 23:17:12

- reply

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

2023-06-07 23:17:11

- reply

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

2023-06-07 23:17:10

- reply

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