* [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
@ 2022-12-01 12:27 Daniel Lipshitz
2022-12-01 22:03 ` Erik Aronesty
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Daniel Lipshitz @ 2022-12-01 12:27 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-01 12:27 [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Daniel Lipshitz @ 2022-12-01 22:03 ` Erik Aronesty 2022-12-02 6:34 ` Daniel Lipshitz 2022-12-02 1:52 ` Antoine Riard 2022-12-02 4:30 ` [bitcoin-dev] " Peter Todd 2 siblings, 1 reply; 16+ messages in thread From: Erik Aronesty @ 2022-12-01 22:03 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-01 22:03 ` Erik Aronesty @ 2022-12-02 6:34 ` Daniel Lipshitz 0 siblings, 0 replies; 16+ messages in thread From: Daniel Lipshitz @ 2022-12-02 6:34 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-01 12:27 [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Daniel Lipshitz 2022-12-01 22:03 ` Erik Aronesty @ 2022-12-02 1:52 ` Antoine Riard 2022-12-02 6:59 ` Daniel Lipshitz 2022-12-02 22:35 ` [bitcoin-dev] Fwd: " Antoine Riard 2022-12-02 4:30 ` [bitcoin-dev] " Peter Todd 2 siblings, 2 replies; 16+ messages in thread From: Antoine Riard @ 2022-12-02 1:52 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-02 1:52 ` Antoine Riard @ 2022-12-02 6:59 ` Daniel Lipshitz 2022-12-02 22:35 ` [bitcoin-dev] Fwd: " Antoine Riard 1 sibling, 0 replies; 16+ messages in thread From: Daniel Lipshitz @ 2022-12-02 6:59 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-02 1:52 ` Antoine Riard 2022-12-02 6:59 ` Daniel Lipshitz @ 2022-12-02 22:35 ` Antoine Riard 2022-12-06 5:03 ` Peter Todd 1 sibling, 1 reply; 16+ messages in thread From: Antoine Riard @ 2022-12-02 22:35 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-02 22:35 ` [bitcoin-dev] Fwd: " Antoine Riard @ 2022-12-06 5:03 ` Peter Todd 0 siblings, 0 replies; 16+ messages in thread From: Peter Todd @ 2022-12-06 5:03 UTC (permalink / raw) To: Antoine Riard, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-01 12:27 [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Daniel Lipshitz 2022-12-01 22:03 ` Erik Aronesty 2022-12-02 1:52 ` Antoine Riard @ 2022-12-02 4:30 ` Peter Todd 2022-12-02 7:06 ` Daniel Lipshitz 2 siblings, 1 reply; 16+ messages in thread From: Peter Todd @ 2022-12-02 4:30 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-02 4:30 ` [bitcoin-dev] " Peter Todd @ 2022-12-02 7:06 ` Daniel Lipshitz 2022-12-03 8:50 ` Peter Todd 0 siblings, 1 reply; 16+ messages in thread From: Daniel Lipshitz @ 2022-12-02 7:06 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-02 7:06 ` Daniel Lipshitz @ 2022-12-03 8:50 ` Peter Todd 2022-12-03 11:01 ` Daniel Lipshitz 0 siblings, 1 reply; 16+ messages in thread From: Peter Todd @ 2022-12-03 8:50 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-03 8:50 ` Peter Todd @ 2022-12-03 11:01 ` Daniel Lipshitz 2022-12-03 11:51 ` Daniel Lipshitz 2022-12-03 12:12 ` Peter Todd 0 siblings, 2 replies; 16+ messages in thread From: Daniel Lipshitz @ 2022-12-03 11:01 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-03 11:01 ` Daniel Lipshitz @ 2022-12-03 11:51 ` Daniel Lipshitz 2022-12-03 12:12 ` Peter Todd 1 sibling, 0 replies; 16+ messages in thread From: Daniel Lipshitz @ 2022-12-03 11:51 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-03 11:01 ` Daniel Lipshitz 2022-12-03 11:51 ` Daniel Lipshitz @ 2022-12-03 12:12 ` Peter Todd 2022-12-03 13:17 ` Daniel Lipshitz 1 sibling, 1 reply; 16+ messages in thread From: Peter Todd @ 2022-12-03 12:12 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-03 12:12 ` Peter Todd @ 2022-12-03 13:17 ` Daniel Lipshitz 2022-12-03 14:03 ` Daniel Lipshitz 0 siblings, 1 reply; 16+ messages in thread From: Daniel Lipshitz @ 2022-12-03 13:17 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-03 13:17 ` Daniel Lipshitz @ 2022-12-03 14:03 ` Daniel Lipshitz 2022-12-05 12:21 ` angus 0 siblings, 1 reply; 16+ messages in thread From: Daniel Lipshitz @ 2022-12-03 14:03 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger 2022-12-03 14:03 ` Daniel Lipshitz @ 2022-12-05 12:21 ` angus 0 siblings, 0 replies; 16+ messages in thread From: angus @ 2022-12-05 12:21 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-12-06 5:04 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-01 12:27 [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger Daniel Lipshitz 2022-12-01 22:03 ` Erik Aronesty 2022-12-02 6:34 ` Daniel Lipshitz 2022-12-02 1:52 ` Antoine Riard 2022-12-02 6:59 ` Daniel Lipshitz 2022-12-02 22:35 ` [bitcoin-dev] Fwd: " Antoine Riard 2022-12-06 5:03 ` Peter Todd 2022-12-02 4:30 ` [bitcoin-dev] " Peter Todd 2022-12-02 7:06 ` Daniel Lipshitz 2022-12-03 8:50 ` Peter Todd 2022-12-03 11:01 ` Daniel Lipshitz 2022-12-03 11:51 ` Daniel Lipshitz 2022-12-03 12:12 ` Peter Todd 2022-12-03 13:17 ` Daniel Lipshitz 2022-12-03 14:03 ` Daniel Lipshitz 2022-12-05 12:21 ` angus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox