[bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2761 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2878 bytes --]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4186 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]

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@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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 6019 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 5070 bytes --]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6746 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 6937 bytes --]

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@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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 9920 bytes --]

[bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 2602 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3399 bytes --]

Re: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]

On Fri, Dec 02, 2022 at 05:35:39PM -0500, Antoine Riard via bitcoin-dev wrote:
> 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].

<snip>

> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html

To be clear, these alternative paths all negatively impact privacy as they're
creating yet more ways for bad actors such as Chainalysis to deanonymize
transactions. We have a fundamental political tradeoff between the few
centralized services trying to accept unconfirmed txs, and the huge number of
users - everyone else - who desires privacy.

A big part of the promise of taproot was that we'd be able to eventually
greatly improve the anonymity set of all transactions by making multi-party
transactions indistinguishable from any other transaction. That's a huge part
of why the community fought for taproot adoption.

Your proposal [5] that multi-party protocols use a different nVersion to signal
full-rbf in their txouts negates that anonymity set for the obvious reason that
single-party wallets are discouraged from using it by the fact that a few
services like Bitrefill complain about RBF transactions. Indeed, since
nVersion=3 transactions are non-standard, we additionally have the problem that
many more wallets won't even see such payments until a confirmation, or in some
cases due to bugs, never.


Worse, this trade-offs is fundamental: it is impossible to design such a
protocol without harming privacy. Why? Let's assume such a protocol was
possible. To be compatible with how unconfirmed txs are accepted today the
protocol would have to have the following two simultaneous properties:

1) Zeroconf services would need to be able to inspect the tx data and determine
   whether or not the txout had opted into full-rbf.
2) Chainalysis services would need to be unable to inspect the tx data and
   determine whether or not the txout had opted into full-rbf.

This is an obvious contradiction, and the only alternative of commit-reveal
schemes is ridiculous and would *itself* create yet another privacy impact. We
do not need any further technical debate on this issue: this is a political
tradeoff between a few centralized services and all other users that needs to
be decied by the community. No different than the blocksize wars.


The v3 proposal Suhas mentions in [4] has similar privacy issues: again we're
forcing a class of multiparty protocols to create transactions that are clearly
identified as being multiparty. In this case the privacy impact isn't as stark,
because the common case of cooperative actions in Lightning can use v2
transactions. But this is still a privacy impact that could be avoided by
better mempool design. Eg as I showed in:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021175.html

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2488 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2136 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2983 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 4190 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5991 bytes --]

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 6438 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 10671 bytes --]

[bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[angus]

[-- Attachment #1.1.1: Type: text/plain, Size: 2883 bytes --]

Core adding full RBF is a change of node policy that may be highly inconvenient for zero-conf users, but there has always been and will always be a risk of a double-spend for anyone that treats zero-confirmation transactions as settled. It's literally in the name - this transaction has zero confirmations and no guarantee it'll make it into a block, and so has not yet settled.


The perception seems to be that Core adding the full RBF option is increasing the risk to zero-conf users, but I'm not convinced that that is the case - someone wanting to double-spend attack you isn't going to be bothered to do so over a few thousand sats (unless they can do it thousands of times), and losing a few thousand sats to a double-spend isn't the biggest deal.


It's always been the risk of getting double-spent out of hundreds or thousands of bitcoins that's worth seriously worrying about, which is much more the kind of attack a determined attacker is able to carry out. Such a determined attacker is much more likely to attempt and succeed at a sybil attack, or directly colluding with a miner. So your zero-conf risk increases non-linearly as the amount of bitcoin being transacted grows. (caveat: this paragraph is opinion).


There does, however, seem to be a legitimate business for providing insurance/risk management for people that are willing to accept the zero-conf risk - it is pretty similar to accepting credit cards with a chargeback risk or any payment card with a capture risk, though there's no-one to mediate a dispute. On-chain is final.

But what doesn't make any sense is trying to avoid Bitcoin Core and nodes from adopting a full RBF policy to try to protect this use case. As has been pointed out by may others before, full RBF is aligned with miner (and user) economic incentives and is a node policy, not consensus, so you can't even tell which nodes are doing it nor can you prevent them from doing so. Second, Bitcoin core 24 with the full RBF option is already out in the wild at around 5%+ of running nodes and growing, so it's too late to kill it.


So my point is that relying on node policy as part of your protection for zero-conf transaction acceptance is fragile, and should not be relied upon. The protocol rules have always tacitly allowed double-spending before a confirmation, and it has always been clear that there's no consensus on which transactions have occurred until they have in a block and have at-least one confirmation.

The long-term 'what to do about it' is to use Lightning if you want fast payments with risk-free instant settlement, or as above, accept the zero-conf risk and cover yourself with an insurance premium (e.g. a margin on transactions that goes into an insurance fund, and limiting max transaction amount so you're not exposed to uncoverable losses if you do get double-spend attacked)




Angus

[-- Attachment #1.1.2.1: Type: text/html, Size: 5800 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]