<unnamed>

Public Key

npub1t97ak5ltnq0v72nv4jssnhw0fr09axwqvc20623jfdnvrajae7nqufg2yy

Profile Code

nprofile1qqs9jlwm204es8k09fk2eggfmh853hj7n8qxv98a9geykekp7ewulfspz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qzrthwden5te0dehhxtnvdakqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc7yly08

Publishing to

relay.nostr.net

nos.lol

relay.damus.io

Last Notes

2023-08-02 12:19:21 CEST

- 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-06-08 01:17:41 CEST

- 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-08 01:17:12 CEST

- 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-08 01:17:10 CEST

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

2023-06-08 01:17:09 CEST

- reply

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