* [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case @ 2022-12-11 20:24 Daniel Lipshitz 2022-12-13 4:20 ` Yuval Kogman 0 siblings, 1 reply; 20+ messages in thread From: Daniel Lipshitz @ 2022-12-11 20:24 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1962 bytes --] Intro Currently there is a significant use case of 0-Conf acceptance of transactions. Merchants and service providers are fully aware of the risks related to 0-conf. Full RBF if it would be significantly enabled would most likely make 0-conf not possible and significantly limit this current use case. A primary motivation for full RBF is to enable an increase of fee of trxs and enable faster acceptance in Block should it be required. Motivation To enable full RBF adoption without this impeding the 0-conf use case. This can be done by enabling the primary use of case full RBF i.e increase the fee, while keeping the outputs of TRX1 to be included within TRX2. Method TRX1 is the trx first published and held in Mempool, TRX2 is the trx which comes to replace TRX1. In order for a TRX2 to replace TRX1 in the Mempool it will require the following - 1. Outputs (addresses and amounts) are the same TRX1 and TRX2 Or - 2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional Outputs to TRX1 Both cases would require the addition of at least one Input in order to increase the fee. In such a case 0-conf acceptance of TRX1 will result in a harmless double spend since TRX1 will not be included in the valid UTXO set; however the address beneficiaries of TRX1 will still be credited by TRX2. This rule would enable the increasing of network fees post publication of trx without the loss of 0-conf use case. Drawbacks Does require access to another Input inorder to take advantage of Full RBF. Summary Access to OptinRBF and FullRBF(with above limitation) would give actors full access to increasing fees as an option. The 0-conf whose risks are very much understood in the market can continue to exist as is, with the 0-conf ongoing choices being continuing to be available to actors. ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz [-- Attachment #2: Type: text/html, Size: 3511 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-11 20:24 [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case Daniel Lipshitz @ 2022-12-13 4:20 ` Yuval Kogman 2022-12-13 8:08 ` Daniel Lipshitz 0 siblings, 1 reply; 20+ messages in thread From: Yuval Kogman @ 2022-12-13 4:20 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 4:20 ` Yuval Kogman @ 2022-12-13 8:08 ` Daniel Lipshitz 2022-12-13 9:59 ` John Carvalho 0 siblings, 1 reply; 20+ messages in thread From: Daniel Lipshitz @ 2022-12-13 8:08 UTC (permalink / raw) To: Yuval Kogman; +Cc: Bitcoin Protocol Discussion, john [-- Attachment #1: Type: text/plain, Size: 585 bytes --] Thank you for bringing that to my attention, apologies for not being aware of it. First-seen-safe replace-by-fee as detailed here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html by Peter Todd seems to be a very suitable option and route which balances FullRBF while retaining the significant 0-conf use case. This would seem like a good way forward. ________________________________ On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> wrote: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html > [-- Attachment #2: Type: text/html, Size: 1567 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 8:08 ` Daniel Lipshitz @ 2022-12-13 9:59 ` John Carvalho 2022-12-13 11:33 ` Daniel Lipshitz 2022-12-14 8:12 ` Daniel Lipshitz 0 siblings, 2 replies; 20+ messages in thread From: John Carvalho @ 2022-12-13 9:59 UTC (permalink / raw) To: Daniel Lipshitz, bitcoin-dev, Peter Todd [-- Attachment #1: Type: text/plain, Size: 1049 bytes --] Why wasn't this solution put in place back then? Are there problems with the design? While I still think there are unhealthy side-effects of Full-RBF (like more doublespending at unknowing merchants, after years of FSS protection) I think discussion of this FSS-RBF feature is worth considering. -- John Carvalho CEO, Synonym.to <http://synonym.to/> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> wrote: > Thank you for bringing that to my attention, apologies for not being aware > of it. > > First-seen-safe replace-by-fee as detailed here > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html > by Peter Todd seems to be a very suitable option and route > which balances FullRBF while retaining the significant 0-conf use case. > > This would seem like a good way forward. > > > > ________________________________ > > > > On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> > wrote: > >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >> > [-- Attachment #2: Type: text/html, Size: 2618 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 9:59 ` John Carvalho @ 2022-12-13 11:33 ` Daniel Lipshitz 2022-12-13 14:00 ` Lucas Ontivero 2022-12-13 21:41 ` Peter Todd 2022-12-14 8:12 ` Daniel Lipshitz 1 sibling, 2 replies; 20+ messages in thread From: Daniel Lipshitz @ 2022-12-13 11:33 UTC (permalink / raw) To: John Carvalho; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1750 bytes --] I dont think there was anything technical with the implementation and as far as I can tell this is well developed and ready. The reasons I can find for not being adopted are listed here - https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe Replace-by-fee Those reasons do not seem pertinent here - given OptinRBF already exists as an option and the added benefit of continuing to be able to support 0-conf. ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john@synonym.to> wrote: > Why wasn't this solution put in place back then? Are there problems with > the design? > > While I still think there are unhealthy side-effects of Full-RBF (like > more doublespending at unknowing merchants, after years of FSS protection) > I think discussion of this FSS-RBF feature is worth considering. > > -- > John Carvalho > CEO, Synonym.to <http://synonym.to/> > > > On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> wrote: > >> Thank you for bringing that to my attention, apologies for not being >> aware of it. >> >> First-seen-safe replace-by-fee as detailed here >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >> by Peter Todd seems to be a very suitable option and route >> which balances FullRBF while retaining the significant 0-conf use case. >> >> This would seem like a good way forward. >> >> >> >> ________________________________ >> >> >> >> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> >> wrote: >> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>> >> [-- Attachment #2: Type: text/html, Size: 4423 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 11:33 ` Daniel Lipshitz @ 2022-12-13 14:00 ` Lucas Ontivero 2022-12-13 14:08 ` Daniel Lipshitz 2022-12-13 21:41 ` Peter Todd 1 sibling, 1 reply; 20+ messages in thread From: Lucas Ontivero @ 2022-12-13 14:00 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion; +Cc: John Carvalho [-- Attachment #1: Type: text/plain, Size: 2270 bytes --] Some wallets like Electrum would be affected by that because they use RBF to batch transactions so, outputs cannot be exactly the same as before. On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I dont think there was anything technical with the implementation and as > far as I can tell this is well developed and ready. > > The reasons I can find for not being adopted are listed here - > https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe > Replace-by-fee > > Those reasons do not seem pertinent here - given OptinRBF already exists > as an option and the added benefit of continuing to be able to support > 0-conf. > > ________________________________ > > Daniel Lipshitz > GAP600| www.gap600.com > Phone: +44 113 4900 117 > Skype: daniellipshitz123 > Twitter: @daniellipshitz > > > On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john@synonym.to> wrote: > >> Why wasn't this solution put in place back then? Are there problems with >> the design? >> >> While I still think there are unhealthy side-effects of Full-RBF (like >> more doublespending at unknowing merchants, after years of FSS protection) >> I think discussion of this FSS-RBF feature is worth considering. >> >> -- >> John Carvalho >> CEO, Synonym.to <http://synonym.to/> >> >> >> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> >> wrote: >> >>> Thank you for bringing that to my attention, apologies for not being >>> aware of it. >>> >>> First-seen-safe replace-by-fee as detailed here >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>> by Peter Todd seems to be a very suitable option and route >>> which balances FullRBF while retaining the significant 0-conf use case. >>> >>> This would seem like a good way forward. >>> >>> >>> >>> ________________________________ >>> >>> >>> >>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> >>> wrote: >>> >>>> >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>>> >>> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5360 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 14:00 ` Lucas Ontivero @ 2022-12-13 14:08 ` Daniel Lipshitz 0 siblings, 0 replies; 20+ messages in thread From: Daniel Lipshitz @ 2022-12-13 14:08 UTC (permalink / raw) To: Lucas Ontivero; +Cc: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 2543 bytes --] This would not effect optinrbf only fullRBF On Tue, 13 Dec 2022 at 16:00 Lucas Ontivero <lucasontivero@gmail.com> wrote: > Some wallets like Electrum would be affected by that because they use RBF > to batch transactions so, outputs cannot be exactly the same as before. > > On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I dont think there was anything technical with the implementation and as >> far as I can tell this is well developed and ready. >> >> The reasons I can find for not being adopted are listed here - >> https://bitcoincore.org/en/faq/optin_rbf/ under - Why not >> First-seen-safe Replace-by-fee >> >> Those reasons do not seem pertinent here - given OptinRBF already exists >> as an option and the added benefit of continuing to be able to support >> 0-conf. >> >> ________________________________ >> >> Daniel Lipshitz >> GAP600| www.gap600.com >> Phone: +44 113 4900 117 >> Skype: daniellipshitz123 >> Twitter: @daniellipshitz >> >> >> On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john@synonym.to> wrote: >> >>> Why wasn't this solution put in place back then? Are there problems with >>> the design? >>> >>> While I still think there are unhealthy side-effects of Full-RBF (like >>> more doublespending at unknowing merchants, after years of FSS protection) >>> I think discussion of this FSS-RBF feature is worth considering. >>> >>> -- >>> John Carvalho >>> CEO, Synonym.to <http://synonym.to/> >>> >>> >>> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> >>> wrote: >>> >>>> Thank you for bringing that to my attention, apologies for not being >>>> aware of it. >>>> >>>> First-seen-safe replace-by-fee as detailed here >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>>> by Peter Todd seems to be a very suitable option and route >>>> which balances FullRBF while retaining the significant 0-conf use case. >>>> >>>> This would seem like a good way forward. >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> >>>> >>>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> >>>> wrote: >>>> >>>>> >>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>>>> >>>> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > -- ________________________________ Daniel Lipshitz GAP600 www.Gap600.com [-- Attachment #2: Type: text/html, Size: 6381 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 11:33 ` Daniel Lipshitz 2022-12-13 14:00 ` Lucas Ontivero @ 2022-12-13 21:41 ` Peter Todd 2022-12-13 21:58 ` Daniel Lipshitz 1 sibling, 1 reply; 20+ messages in thread From: Peter Todd @ 2022-12-13 21:41 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 2523 bytes --] On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote: > I dont think there was anything technical with the implementation and as > far as I can tell this is well developed and ready. There are lots of problems with my first-seen-safe proposal. The only reason I proposed it in 2015 was as a political compromise. > The reasons I can find for not being adopted are listed here - > https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe > Replace-by-fee > > Those reasons do not seem pertinent here - given OptinRBF already exists > as an option and the added benefit of continuing to be able to support > 0-conf. First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was merged into Bitcoin Core: multi-party transactions. With multi-party transactions such as coinjoins and multi-party lightning channels, we want full-rbf behavior because it avoids accidental double-spends holding up progress in these protocols. Second, for intentional DoS attacks, it makes those attacks much more expensive by forcing the attacker to use tx-pinning. Nothing less than full-rbf without restritions on outputs works for this use-case. The only compromise possible is Antoine Riard's spent-nVersion signalling proposal¹, which has a significant, negative, privacy impact². It also increases costs and time in many cases, as you often have to create new outputs to flag full-rbf. Thus we have a political tradeoff between a handful of centralized services such as yours that benefit from the first-seen status quo, and the much larger group of users that use Lightning and coinjoins. We've already been through such a political tradeoff before with the blocksize debate - again, the centralized payment providers lost the debate. Anyway, my advice to you is to either change your business model to make use of scalable instant payment tech such as Lightning. Or give up on Bitcoin and expand your business with other chians, such as BSV³. The fact is some hashing power is already beginning to run with full-rbf⁴, and I fully expect that % to increase over time. 1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html 2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html 3) https://www.gap600.com/bitcoin/gap600-supports-bsv/ 4) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 21:41 ` Peter Todd @ 2022-12-13 21:58 ` Daniel Lipshitz 2022-12-16 21:14 ` Peter Todd 0 siblings, 1 reply; 20+ messages in thread From: Daniel Lipshitz @ 2022-12-13 21:58 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 3363 bytes --] On Tue, 13 Dec 2022 at 23:41 Peter Todd <pete@petertodd.org> wrote: > On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote: > > I dont think there was anything technical with the implementation and as > > far as I can tell this is well developed and ready. > > There are lots of problems with my first-seen-safe proposal. The only > reason I > proposed it in 2015 was as a political compromise. > > > The reasons I can find for not being adopted are listed here - > > https://bitcoincore.org/en/faq/optin_rbf/ under - Why not > First-seen-safe > > Replace-by-fee > > > > Those reasons do not seem pertinent here - given OptinRBF already exists > > as an option and the added benefit of continuing to be able to support > > 0-conf. > > First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was > merged into Bitcoin Core: multi-party transactions. > > With multi-party transactions such as coinjoins and multi-party lightning > channels, we want full-rbf behavior because it avoids accidental > double-spends > holding up progress in these protocols. what is meant by accidental double spends ? And do you have any data as to how often these occur and would cause harm? Second, for intentional DoS attacks, it > makes those attacks much more expensive by forcing the attacker to use > tx-pinning. how are these Dos attacks mitigated today if Full RBF is not in place ? > > > Nothing less than full-rbf without restritions on outputs works for this > use-case. The only compromise possible is Antoine Riard's spent-nVersion > signalling proposal¹, which has a significant, negative, privacy impact². > It > also increases costs and time in many cases, as you often have to create > new > outputs to flag full-rbf. > > Thus we have a political tradeoff between a handful of centralized services > such as yours that benefit from the first-seen status quo, and the much > larger > group of users that use Lightning and coinjoins. How many users are currently using Lightning and coinjoins today ? > We've already been through > such a political tradeoff before with the blocksize debate - again, the > centralized payment providers lost the debate. I don’t think this has anything to do with block size debate or decentralisation just looking to protect a significant use case that has been in place - GAP600 is by no means the only service provider is this place there are many merchants who do 0-conf on there own. > > > > Anyway, my advice to you is to either change your business model to make > use of > scalable instant payment tech such as Lightning. Or give up on Bitcoin and > expand your business with other chians, such as BSV³. The fact is some > hashing > power is already beginning to run with full-rbf⁴, and I fully expect that > % to > increase over time. > > 1) > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html > 2) > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html > 3) https://www.gap600.com/bitcoin/gap600-supports-bsv/ > 4) > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- ________________________________ Daniel Lipshitz GAP600 www.Gap600.com [-- Attachment #2: Type: text/html, Size: 5475 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 21:58 ` Daniel Lipshitz @ 2022-12-16 21:14 ` Peter Todd 2022-12-18 8:06 ` Daniel Lipshitz 0 siblings, 1 reply; 20+ messages in thread From: Peter Todd @ 2022-12-16 21:14 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 4289 bytes --] On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote: > > With multi-party transactions such as coinjoins and multi-party lightning > > channels, we want full-rbf behavior because it avoids accidental > > double-spends > > holding up progress in these protocols. > > what is meant by accidental double spends ? And do you have any data as to > how often these occur and would cause harm? A double-spend of an input to a multiparty transaction that isn't maximally trying to exploit transaction pinning. For example, Wasabi has found many cases of users imported the same seed into different wallets. This is quite hard to avoid in decentralized wallets. > Second, for intentional DoS attacks, it > > makes those attacks much more expensive by forcing the attacker to use > > tx-pinning. > > how are these Dos attacks mitigated today if Full RBF is not in place ? They aren't. During congested mempool conditions an attacker could cause significant delays to multi-party transactions without full-rbf. Fortunately, the mempool regularly empties right now. But that has not been true in the past, we can not guarantee that, and for Bitcoin to remain secure without inflation or demmurage in the future, we have to operate under full-mempools with significant backlogs of transactions. > > Thus we have a political tradeoff between a handful of centralized services > > such as yours that benefit from the first-seen status quo, and the much > > larger > > group of users that use Lightning and coinjoins. > > How many users are currently using Lightning and coinjoins today ? Wallet of Satoshi, one of many Lightning wallets, claims to be performing 12,500 transactions/day: https://twitter.com/kerooke/status/1603812141966016520 Bitcoin as a whole currently does about 300,000 transactions per day(1). So that one single Lightning wallet represents roughly 4% of the total payment volume of Bitcoin. Wallet of Satoshi, BlueWallet, and SBW all have 100K+ downloads on the Google Play store. So a reasonable guess is they're equally popular. Which means they collectively represent 12% of the total number of transactions on Bitcoin. You claimed GAP600 was queried for 900,000 unique tx hashes per month(2), or about 10% of total transactions. I don't have statistics for number of coinjoin transactions per day, or the blockspace used. But Wasabi have published (reproducable) data showing that currently about 750BTC/day are entering Wasabi 2.0 coinjoins: https://mobile.twitter.com/wasabiwallet/status/1603366008437325828 You claimed GAP600 was responsible for USD $220 million of transaction volume(2), significantly less than the ~$400 million / month that Wasabi coinjoins alone represent. And of course, Wasabi is just one of three main coinjoin implementations. > > We've already been through > > such a political tradeoff before with the blocksize debate - again, the > > centralized payment providers lost the debate. > > I don’t think this has anything to do with block size debate or > decentralisation just looking to protect a significant use case that has > been in place - GAP600 is by no means the only service provider is this > place there are many merchants who do 0-conf on there own. You claimed that GAP600 handled about 10% of all transactions. Obviously, if that is true, that indicates a very high degree of centralization. It is extremely undesirable for Bitcoin for one single entity with, as I understand it, AML/KYC to handle 10% of all transactions. Probably an even higher percentage when you take into account that only a minority of transactions are merchant payment-type transactions where unconfirmed transactions would have any relevance at all. You claim that there are "many merchants" who do 0-conf on their own. Can you list more examples of those merchants? Surely if there are "many" of them, you could easily give us four or five more examples so this list can evaluate what kinds of security guarantees they're actually relying on. 1) https://ycharts.com/indicators/bitcoin_transactions_per_day 2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-16 21:14 ` Peter Todd @ 2022-12-18 8:06 ` Daniel Lipshitz 2023-01-13 23:53 ` Peter Todd 0 siblings, 1 reply; 20+ messages in thread From: Daniel Lipshitz @ 2022-12-18 8:06 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 6345 bytes --] GAP600 is not a trxs processor or liquidity provider we service merchants, payment processors & non-custodial liquidity providers - our service is purely the 0-conf enabling our clients to accept 0-conf. Clients access our service via API - sending us the Trx hash & output address. Our service is not based on AML/KYC it is purely an analysis of the Bitcoin network. I am not at liberty to share names of other services which have developed their own 0-conf service - they include a payment processor on a gambling platform which services multiple gambling operators, a standalone gaming payment processor, and a payment processor recently I have come across. We also do not have a significant presence in Asia - so I don't have visibility there. I see from the Wallet of Satoshis website that they are a custodial wallet provider. I don't see it being necessarily an either/or approach here. The risk looking to be mitigated with FullRBF seems to be able to be mitigated with FullRBF but with a swop limitation of at least the Inputs of Trx1 being in Trx2 - no flagging required. Added to this all these trxs always have the OptinRBF so if these platforms need to be able to recreate completely their trxs they have that option as well. The option to Swop out or bump up trxs seems to be well covered under those two options. The case of creating multiple wallets with the same seeds seems to be an edge case - and to do that and then recreate accidental double spends as a result sounds like an extreme edge case which I would not think should be a protocol consideration. ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz On Fri, Dec 16, 2022 at 11:14 PM Peter Todd <pete@petertodd.org> wrote: > On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote: > > > With multi-party transactions such as coinjoins and multi-party > lightning > > > channels, we want full-rbf behavior because it avoids accidental > > > double-spends > > > holding up progress in these protocols. > > > > what is meant by accidental double spends ? And do you have any data as > to > > how often these occur and would cause harm? > > A double-spend of an input to a multiparty transaction that isn't maximally > trying to exploit transaction pinning. For example, Wasabi has found many > cases > of users imported the same seed into different wallets. This is quite hard > to > avoid in decentralized wallets. > > > Second, for intentional DoS attacks, it > > > makes those attacks much more expensive by forcing the attacker to use > > > tx-pinning. > > > > how are these Dos attacks mitigated today if Full RBF is not in place ? > > They aren't. During congested mempool conditions an attacker could cause > significant delays to multi-party transactions without full-rbf. > Fortunately, > the mempool regularly empties right now. But that has not been true in the > past, we can not guarantee that, and for Bitcoin to remain secure without > inflation or demmurage in the future, we have to operate under > full-mempools > with significant backlogs of transactions. > > > > Thus we have a political tradeoff between a handful of centralized > services > > > such as yours that benefit from the first-seen status quo, and the much > > > larger > > > group of users that use Lightning and coinjoins. > > > > How many users are currently using Lightning and coinjoins today ? > > Wallet of Satoshi, one of many Lightning wallets, claims to be performing > 12,500 transactions/day: > https://twitter.com/kerooke/status/1603812141966016520 > > Bitcoin as a whole currently does about 300,000 transactions per day(1). > So that > one single Lightning wallet represents roughly 4% of the total payment > volume > of Bitcoin. Wallet of Satoshi, BlueWallet, and SBW all have 100K+ > downloads on > the Google Play store. So a reasonable guess is they're equally popular. > Which > means they collectively represent 12% of the total number of transactions > on > Bitcoin. You claimed GAP600 was queried for 900,000 unique tx hashes per > month(2), or about 10% of total transactions. > > > I don't have statistics for number of coinjoin transactions per day, or the > blockspace used. But Wasabi have published (reproducable) data showing that > currently about 750BTC/day are entering Wasabi 2.0 coinjoins: > https://mobile.twitter.com/wasabiwallet/status/1603366008437325828 > > You claimed GAP600 was responsible for USD $220 million of transaction > volume(2), significantly less than the ~$400 million / month that Wasabi > coinjoins alone represent. And of course, Wasabi is just one of three main > coinjoin implementations. > > > > We've already been through > > > such a political tradeoff before with the blocksize debate - again, the > > > centralized payment providers lost the debate. > > > > I don’t think this has anything to do with block size debate or > > decentralisation just looking to protect a significant use case that has > > been in place - GAP600 is by no means the only service provider is this > > place there are many merchants who do 0-conf on there own. > > You claimed that GAP600 handled about 10% of all transactions. Obviously, > if > that is true, that indicates a very high degree of centralization. It is > extremely undesirable for Bitcoin for one single entity with, as I > understand > it, AML/KYC to handle 10% of all transactions. Probably an even higher > percentage when you take into account that only a minority of transactions > are > merchant payment-type transactions where unconfirmed transactions would > have > any relevance at all. > > You claim that there are "many merchants" who do 0-conf on their own. Can > you > list more examples of those merchants? Surely if there are "many" of them, > you > could easily give us four or five more examples so this list can evaluate > what > kinds of security guarantees they're actually relying on. > > 1) https://ycharts.com/indicators/bitcoin_transactions_per_day > 2) > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > [-- Attachment #2: Type: text/html, Size: 8385 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-18 8:06 ` Daniel Lipshitz @ 2023-01-13 23:53 ` Peter Todd 2023-01-14 20:15 ` Daniel Lipshitz 0 siblings, 1 reply; 20+ messages in thread From: Peter Todd @ 2023-01-13 23:53 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 2602 bytes --] On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote: > GAP600 is not a trxs processor or liquidity provider we service merchants, > payment processors & non-custodial liquidity providers - our service is > purely the 0-conf enabling our clients to accept 0-conf. Clients access our > service via API - sending us the Trx hash & output address. Our service is > not based on AML/KYC it is purely an analysis of the Bitcoin network. I checked and to sign up for your service, you ask for the name, phone number, email, and company name. That is an example of AML/KYC. By learning the tx hash and output address, you learn which addresses are associated with what real world entity is paying for your service. You learning that information for what you claim is ~10% of all transactions is a significant privacy concern. On that basiss alone, I would argue that full-rbf should be implemented specifically to destroy your business and stop the collection of that data. > I am not at liberty to share names of other services which have developed > their own 0-conf service - they include a payment processor on a gambling > platform which services multiple gambling operators, a standalone gaming > payment processor, and a payment processor recently I have come across. We > also do not have a significant presence in Asia - so I don't have > visibility there. No, I asked you for information on what companies are actually using *your* service. You claim to be involved with a huge % of all transactions. If that is in fact true, obviously it shouldn't be hard to provide some examples of merchants using GAP600 to accept unconfirmed txs. > I don't see it being necessarily an either/or approach here. The risk > looking to be mitigated with FullRBF seems to be able to be mitigated with > FullRBF but with a swop limitation of at least the Inputs of Trx1 being in > Trx2 - no flagging required. Added to this all these trxs always have the > OptinRBF so if these platforms need to be able to recreate completely their > trxs they have that option as well. The option to Swop out or bump up trxs > seems to be well covered under those two options. You are not correct. One of the most important use-cases for full-rbf is multi-party transactions; adding that limitation to full-rbf negates that usecase. See my post on why full-rbf makes DoS attacks on multiparty protocols significantly more expensive: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2023-01-13 23:53 ` Peter Todd @ 2023-01-14 20:15 ` Daniel Lipshitz 2023-01-16 10:19 ` Daniel Lipshitz 2023-02-04 16:27 ` Peter Todd 0 siblings, 2 replies; 20+ messages in thread From: Daniel Lipshitz @ 2023-01-14 20:15 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 4197 bytes --] On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete@petertodd.org> wrote: > On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote: > > GAP600 is not a trxs processor or liquidity provider we service > merchants, > > payment processors & non-custodial liquidity providers - our service is > > purely the 0-conf enabling our clients to accept 0-conf. Clients access > our > > service via API - sending us the Trx hash & output address. Our service > is > > not based on AML/KYC it is purely an analysis of the Bitcoin network. > > I checked and to sign up for your service, you ask for the name, phone > number, > email, and company name. > > That is an example of AML/KYC. By learning the tx hash and output address, > you > learn which addresses are associated with what real world entity is paying > for > your service. You learning that information for what you claim is ~10% of > all > transactions is a significant privacy concern. On that basiss alone, I > would > argue that full-rbf should be implemented specifically to destroy your > business > and stop the collection of that data. > > We have standard commercial information about the payment processors, non custodial liquidity providers and merchants which become our clients - we do not have any kyc/aml information or telephone number on who is sending our clients the bitcoin for deposit. For us these are just bitcoin Trx which our clients choose to benefit from 0-conf deposit recognition. Our service is provided via API with the only information our clients share with us, regarding a specific bitcoin transaction, being public bitcoin information like trx hash and output address. > I am not at liberty to share names of other services which have developed > > their own 0-conf service - they include a payment processor on a gambling > > platform which services multiple gambling operators, a standalone gaming > > payment processor, and a payment processor recently I have come across. > We > > also do not have a significant presence in Asia - so I don't have > > visibility there. > > No, I asked you for information on what companies are actually using *your* > service. You claim to be involved with a huge % of all transactions. If > that is > in fact true, obviously it shouldn't be hard to provide some examples of > merchants using GAP600 to accept unconfirmed txs. > As already posted here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see link, is available to discuss further and may choose to share further information on the merchants they support. > > > I don't see it being necessarily an either/or approach here. The risk > > looking to be mitigated with FullRBF seems to be able to be mitigated > with > > FullRBF but with a swop limitation of at least the Inputs of Trx1 being > in > > Trx2 - no flagging required. Added to this all these trxs always have the > > OptinRBF so if these platforms need to be able to recreate completely > their > > trxs they have that option as well. The option to Swop out or bump up > trxs > > seems to be well covered under those two options. > > You are not correct. One of the most important use-cases for full-rbf is > multi-party transactions; adding that limitation to full-rbf negates that > usecase. See my post on why full-rbf makes DoS attacks on multiparty > protocols > significantly more expensive: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html I also note that there is ongoing debate as to the need for full RBF see here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html . This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF and common sense - offering enough coverage to mitigate. 0-conf although may not be liked by some actors in Bitcoin, is engaged with free choice and understanding of the risks. 0-conf is a long standing and significant use case which should not be ignored. 0-conf demise should be viewed as being a major and unnecessary cost to FullRBF as currently implemented. > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > [-- Attachment #2: Type: text/html, Size: 5814 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2023-01-14 20:15 ` Daniel Lipshitz @ 2023-01-16 10:19 ` Daniel Lipshitz 2023-01-17 17:07 ` Erik Aronesty 2023-02-04 16:27 ` Peter Todd 1 sibling, 1 reply; 20+ messages in thread From: Daniel Lipshitz @ 2023-01-16 10:19 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 5591 bytes --] Some further clarity on our unique trx hashes queried to our platform, our initial and followup numbers on unique trx hashes queried were not accurate - apologies. Bitcoin addresses queried and Usd value and unique were accurate. This is as a result of our platform viewing each queried bitcoin address as a transaction from our point of view. November 2022 Total queried unique bitcoin address- circa 1.5m trxs Unique Bitcoin trx hashes queried- circa 500k USD value - circa 220m December 2022 Total queried unique bitcoin address- circa 1.7m trxs Unique Bitcoin trx hashes queried - circa 500k USD value - circa 200m There are further merchants and service providers who enable 0-conf on Bitcoin who are not working via our platform - I do not know their numbers but believe they are significant. 0-conf on Bitcoin with its understood risks is a significant use case. For third party clarification please see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html ________________________________ Daniel Lipshitz GAP600| www.gap600.com On Sat, Jan 14, 2023 at 10:15 PM Daniel Lipshitz <daniel@gap600.com> wrote: > > > > On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete@petertodd.org> wrote: > >> On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote: >> > GAP600 is not a trxs processor or liquidity provider we service >> merchants, >> > payment processors & non-custodial liquidity providers - our service is >> > purely the 0-conf enabling our clients to accept 0-conf. Clients access >> our >> > service via API - sending us the Trx hash & output address. Our service >> is >> > not based on AML/KYC it is purely an analysis of the Bitcoin network. >> >> I checked and to sign up for your service, you ask for the name, phone >> number, >> email, and company name. >> >> That is an example of AML/KYC. By learning the tx hash and output >> address, you >> learn which addresses are associated with what real world entity is >> paying for >> your service. You learning that information for what you claim is ~10% of >> all >> transactions is a significant privacy concern. On that basiss alone, I >> would >> argue that full-rbf should be implemented specifically to destroy your >> business >> and stop the collection of that data. >> >> We have standard commercial information about the payment processors, non > custodial liquidity providers and merchants which become our clients - we > do not have any kyc/aml information or telephone number on who is sending > our clients the bitcoin for deposit. For us these are just bitcoin Trx > which our clients choose to benefit from 0-conf deposit recognition. Our > service is provided via API with the only information our clients share > with us, regarding a specific bitcoin transaction, being public bitcoin > information like trx hash and output address. > > > I am not at liberty to share names of other services which have developed >> > their own 0-conf service - they include a payment processor on a >> gambling >> > platform which services multiple gambling operators, a standalone gaming >> > payment processor, and a payment processor recently I have come across. >> We >> > also do not have a significant presence in Asia - so I don't have >> > visibility there. >> >> No, I asked you for information on what companies are actually using >> *your* >> service. You claim to be involved with a huge % of all transactions. If >> that is >> in fact true, obviously it shouldn't be hard to provide some examples of >> merchants using GAP600 to accept unconfirmed txs. >> > > As already posted here > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html > Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see > link, is available to discuss further and may choose to share further > information on the merchants they support. > >> >> > I don't see it being necessarily an either/or approach here. The risk >> > looking to be mitigated with FullRBF seems to be able to be mitigated >> with >> > FullRBF but with a swop limitation of at least the Inputs of Trx1 being >> in >> > Trx2 - no flagging required. Added to this all these trxs always have >> the >> > OptinRBF so if these platforms need to be able to recreate completely >> their >> > trxs they have that option as well. The option to Swop out or bump up >> trxs >> > seems to be well covered under those two options. >> >> You are not correct. One of the most important use-cases for full-rbf is >> multi-party transactions; adding that limitation to full-rbf negates that >> usecase. See my post on why full-rbf makes DoS attacks on multiparty >> protocols >> significantly more expensive: >> >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html > > > I also note that there is ongoing debate as to the need for full RBF see > here > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html > . > > This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF and > common sense - offering enough coverage to mitigate. > > 0-conf although may not be liked by some actors in Bitcoin, is engaged > with free choice and understanding of the risks. 0-conf is a long standing > and significant use case which should not be ignored. 0-conf demise should > be viewed as being a major and unnecessary cost to FullRBF as currently > implemented. > >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> > [-- Attachment #2: Type: text/html, Size: 8441 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2023-01-16 10:19 ` Daniel Lipshitz @ 2023-01-17 17:07 ` Erik Aronesty 2023-01-17 17:27 ` Daniel Lipshitz 0 siblings, 1 reply; 20+ messages in thread From: Erik Aronesty @ 2023-01-17 17:07 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion; +Cc: John Carvalho [-- Attachment #1: Type: text/plain, Size: 6350 bytes --] > 0-conf on Bitcoin with its understood risks is a significant use case and that use case doesn't change, at all, with full rbf. the risk profile will, likely, remain the same. observation of the fee paid, history of doing business with the customer, transaction size are all needed. On Mon, Jan 16, 2023 at 1:50 PM Daniel Lipshitz via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Some further clarity on our unique trx hashes queried to our platform, our > initial and followup numbers on unique trx hashes queried were not accurate > - apologies. Bitcoin addresses queried and Usd value and unique were > accurate. This is as a result of our platform viewing each queried bitcoin > address as a transaction from our point of view. > > November 2022 > Total queried unique bitcoin address- circa 1.5m trxs > Unique Bitcoin trx hashes queried- circa 500k > USD value - circa 220m > December 2022 > Total queried unique bitcoin address- circa 1.7m trxs > Unique Bitcoin trx hashes queried - circa 500k > USD value - circa 200m > > There are further merchants and service providers who enable 0-conf on > Bitcoin who are not working via our platform - I do not know their numbers > but believe they are significant. 0-conf on Bitcoin with its understood > risks is a significant use case. > > For third party clarification please see > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html > and > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html > ________________________________ > > Daniel Lipshitz > GAP600| www.gap600.com > > > > > On Sat, Jan 14, 2023 at 10:15 PM Daniel Lipshitz <daniel@gap600.com> > wrote: > >> >> >> >> On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete@petertodd.org> wrote: >> >>> On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote: >>> > GAP600 is not a trxs processor or liquidity provider we service >>> merchants, >>> > payment processors & non-custodial liquidity providers - our service is >>> > purely the 0-conf enabling our clients to accept 0-conf. Clients >>> access our >>> > service via API - sending us the Trx hash & output address. Our >>> service is >>> > not based on AML/KYC it is purely an analysis of the Bitcoin network. >>> >>> I checked and to sign up for your service, you ask for the name, phone >>> number, >>> email, and company name. >>> >>> That is an example of AML/KYC. By learning the tx hash and output >>> address, you >>> learn which addresses are associated with what real world entity is >>> paying for >>> your service. You learning that information for what you claim is ~10% >>> of all >>> transactions is a significant privacy concern. On that basiss alone, I >>> would >>> argue that full-rbf should be implemented specifically to destroy your >>> business >>> and stop the collection of that data. >>> >>> We have standard commercial information about the payment processors, >> non custodial liquidity providers and merchants which become our clients - >> we do not have any kyc/aml information or telephone number on who is >> sending our clients the bitcoin for deposit. For us these are just bitcoin >> Trx which our clients choose to benefit from 0-conf deposit recognition. >> Our service is provided via API with the only information our clients share >> with us, regarding a specific bitcoin transaction, being public bitcoin >> information like trx hash and output address. >> >> > I am not at liberty to share names of other services which have >>> developed >>> > their own 0-conf service - they include a payment processor on a >>> gambling >>> > platform which services multiple gambling operators, a standalone >>> gaming >>> > payment processor, and a payment processor recently I have come >>> across. We >>> > also do not have a significant presence in Asia - so I don't have >>> > visibility there. >>> >>> No, I asked you for information on what companies are actually using >>> *your* >>> service. You claim to be involved with a huge % of all transactions. If >>> that is >>> in fact true, obviously it shouldn't be hard to provide some examples of >>> merchants using GAP600 to accept unconfirmed txs. >>> >> >> As already posted here >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html >> Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see >> link, is available to discuss further and may choose to share further >> information on the merchants they support. >> >>> >>> > I don't see it being necessarily an either/or approach here. The risk >>> > looking to be mitigated with FullRBF seems to be able to be mitigated >>> with >>> > FullRBF but with a swop limitation of at least the Inputs of Trx1 >>> being in >>> > Trx2 - no flagging required. Added to this all these trxs always have >>> the >>> > OptinRBF so if these platforms need to be able to recreate completely >>> their >>> > trxs they have that option as well. The option to Swop out or bump up >>> trxs >>> > seems to be well covered under those two options. >>> >>> You are not correct. One of the most important use-cases for full-rbf is >>> multi-party transactions; adding that limitation to full-rbf negates that >>> usecase. See my post on why full-rbf makes DoS attacks on multiparty >>> protocols >>> significantly more expensive: >>> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html >> >> >> I also note that there is ongoing debate as to the need for full RBF see >> here >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html >> . >> >> This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF and >> common sense - offering enough coverage to mitigate. >> >> 0-conf although may not be liked by some actors in Bitcoin, is engaged >> with free choice and understanding of the risks. 0-conf is a long standing >> and significant use case which should not be ignored. 0-conf demise should >> be viewed as being a major and unnecessary cost to FullRBF as currently >> implemented. >> >>> -- >>> https://petertodd.org 'peter'[:-1]@petertodd.org >>> >> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 9572 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2023-01-17 17:07 ` Erik Aronesty @ 2023-01-17 17:27 ` Daniel Lipshitz 0 siblings, 0 replies; 20+ messages in thread From: Daniel Lipshitz @ 2023-01-17 17:27 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion, John Carvalho [-- Attachment #1: Type: text/plain, Size: 6904 bytes --] > > 0-conf on Bitcoin with its understood risks is a significant use case > > and that use case doesn't change, at all, with full rbf. the risk > profile will, likely, remain the same. observation of the fee paid, > history of doing business with the customer, transaction size are all > needed. > Currently 0-conf recognition is done without any KYC on the payor, this includes activities like, gaming, non-custodial trading and applications. In general OptinRBF is not possible to offer 0-conf since as soon as it is recognised it can be double spent. Full RBF would make all trxs just like OptinRBF. FullRBF but with FSS implemented will still enable 0-conf acceptance. > > On Mon, Jan 16, 2023 at 1:50 PM Daniel Lipshitz via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Some further clarity on our unique trx hashes queried to our platform, >> our initial and followup numbers on unique trx hashes queried were not >> accurate - apologies. Bitcoin addresses queried and Usd value and unique >> were accurate. This is as a result of our platform viewing each queried >> bitcoin address as a transaction from our point of view. >> >> November 2022 >> Total queried unique bitcoin address- circa 1.5m trxs >> Unique Bitcoin trx hashes queried- circa 500k >> USD value - circa 220m >> December 2022 >> Total queried unique bitcoin address- circa 1.7m trxs >> Unique Bitcoin trx hashes queried - circa 500k >> USD value - circa 200m >> >> There are further merchants and service providers who enable 0-conf on >> Bitcoin who are not working via our platform - I do not know their numbers >> but believe they are significant. 0-conf on Bitcoin with its understood >> risks is a significant use case. >> >> For third party clarification please see >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html >> and >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021238.html >> ________________________________ >> >> Daniel Lipshitz >> GAP600| www.gap600.com >> >> >> >> >> On Sat, Jan 14, 2023 at 10:15 PM Daniel Lipshitz <daniel@gap600.com> >> wrote: >> >>> >>> >>> >>> On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete@petertodd.org> wrote: >>> >>>> On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote: >>>> > GAP600 is not a trxs processor or liquidity provider we service >>>> merchants, >>>> > payment processors & non-custodial liquidity providers - our service >>>> is >>>> > purely the 0-conf enabling our clients to accept 0-conf. Clients >>>> access our >>>> > service via API - sending us the Trx hash & output address. Our >>>> service is >>>> > not based on AML/KYC it is purely an analysis of the Bitcoin network. >>>> >>>> I checked and to sign up for your service, you ask for the name, phone >>>> number, >>>> email, and company name. >>>> >>>> That is an example of AML/KYC. By learning the tx hash and output >>>> address, you >>>> learn which addresses are associated with what real world entity is >>>> paying for >>>> your service. You learning that information for what you claim is ~10% >>>> of all >>>> transactions is a significant privacy concern. On that basiss alone, I >>>> would >>>> argue that full-rbf should be implemented specifically to destroy your >>>> business >>>> and stop the collection of that data. >>>> >>>> We have standard commercial information about the payment processors, >>> non custodial liquidity providers and merchants which become our clients - >>> we do not have any kyc/aml information or telephone number on who is >>> sending our clients the bitcoin for deposit. For us these are just bitcoin >>> Trx which our clients choose to benefit from 0-conf deposit recognition. >>> Our service is provided via API with the only information our clients share >>> with us, regarding a specific bitcoin transaction, being public bitcoin >>> information like trx hash and output address. >>> >>> > I am not at liberty to share names of other services which have >>>> developed >>>> > their own 0-conf service - they include a payment processor on a >>>> gambling >>>> > platform which services multiple gambling operators, a standalone >>>> gaming >>>> > payment processor, and a payment processor recently I have come >>>> across. We >>>> > also do not have a significant presence in Asia - so I don't have >>>> > visibility there. >>>> >>>> No, I asked you for information on what companies are actually using >>>> *your* >>>> service. You claim to be involved with a huge % of all transactions. If >>>> that is >>>> in fact true, obviously it shouldn't be hard to provide some examples of >>>> merchants using GAP600 to accept unconfirmed txs. >>>> >>> >>> As already posted here >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html >>> Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see >>> link, is available to discuss further and may choose to share further >>> information on the merchants they support. >>> >>>> >>>> > I don't see it being necessarily an either/or approach here. The risk >>>> > looking to be mitigated with FullRBF seems to be able to be mitigated >>>> with >>>> > FullRBF but with a swop limitation of at least the Inputs of Trx1 >>>> being in >>>> > Trx2 - no flagging required. Added to this all these trxs always have >>>> the >>>> > OptinRBF so if these platforms need to be able to recreate completely >>>> their >>>> > trxs they have that option as well. The option to Swop out or bump up >>>> trxs >>>> > seems to be well covered under those two options. >>>> >>>> You are not correct. One of the most important use-cases for full-rbf is >>>> multi-party transactions; adding that limitation to full-rbf negates >>>> that >>>> usecase. See my post on why full-rbf makes DoS attacks on multiparty >>>> protocols >>>> significantly more expensive: >>>> >>>> >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html >>> >>> >>> I also note that there is ongoing debate as to the need for full RBF see >>> here >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html >>> . >>> >>> This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF >>> and common sense - offering enough coverage to mitigate. >>> >>> 0-conf although may not be liked by some actors in Bitcoin, is engaged >>> with free choice and understanding of the risks. 0-conf is a long standing >>> and significant use case which should not be ignored. 0-conf demise should >>> be viewed as being a major and unnecessary cost to FullRBF as currently >>> implemented. >>> >>>> -- >>>> https://petertodd.org 'peter'[:-1]@petertodd.org >>>> >>> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > [-- Attachment #2: Type: text/html, Size: 10334 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2023-01-14 20:15 ` Daniel Lipshitz 2023-01-16 10:19 ` Daniel Lipshitz @ 2023-02-04 16:27 ` Peter Todd 2023-02-06 12:08 ` Daniel Lipshitz 1 sibling, 1 reply; 20+ messages in thread From: Peter Todd @ 2023-02-04 16:27 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 1104 bytes --] On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote: > We have standard commercial information about the payment processors, non > custodial liquidity providers and merchants which become our clients - we > do not have any kyc/aml information or telephone number on who is sending > our clients the bitcoin for deposit. For us these are just bitcoin Trx > which our clients choose to benefit from 0-conf deposit recognition. Our > service is provided via API with the only information our clients share > with us, regarding a specific bitcoin transaction, being public bitcoin > information like trx hash and output address. You know who your clients are, and thus every request for information on a transaction is reasonably likely to be a deposit associated with the client who requested it. Learning what addresses are associated with what entity is a significant benefit to Chainalysis operations, and there's every reason to expect that the data you learn will either be sold or leaked to Chainalysis companies. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2023-02-04 16:27 ` Peter Todd @ 2023-02-06 12:08 ` Daniel Lipshitz 0 siblings, 0 replies; 20+ messages in thread From: Daniel Lipshitz @ 2023-02-06 12:08 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev, John Carvalho [-- Attachment #1: Type: text/plain, Size: 1950 bytes --] On Sat, Feb 4, 2023 at 6:28 PM Peter Todd <pete@petertodd.org> wrote: > On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote: > > We have standard commercial information about the payment processors, non > > custodial liquidity providers and merchants which become our clients - we > > do not have any kyc/aml information or telephone number on who is sending > > our clients the bitcoin for deposit. For us these are just bitcoin Trx > > which our clients choose to benefit from 0-conf deposit recognition. Our > > service is provided via API with the only information our clients share > > with us, regarding a specific bitcoin transaction, being public bitcoin > > information like trx hash and output address. > > You know who your clients are, and thus every request for information on a > transaction is reasonably likely to be a deposit associated with the > client who > requested it. Learning what addresses are associated with what entity is a > significant benefit to Chainalysis operations, and there's every reason to > expect that the data you learn will either be sold or leaked to Chainalysis > companies. > I would estimate based on general discussions with clients and open research more than 90% of our clients use different AML trx analysis service providers for trx deposited on their platforms - completely irrelevant to us or 0-conf. So if these clients were to stop recognising 0-conf this would have no impact on these AML service providers access to the data. We service payment processors and liquidity providers and have little or no insight into which wallets or merchants our clients service. Further to this many of the cluster addresses of our clients and just like other service providers in the bitcoin space are publicly known - just as Max had no issue sharing the cluster of his deposit address in his email which I posted to the list. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > [-- Attachment #2: Type: text/html, Size: 2668 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-13 9:59 ` John Carvalho 2022-12-13 11:33 ` Daniel Lipshitz @ 2022-12-14 8:12 ` Daniel Lipshitz 2022-12-14 17:41 ` Erik Aronesty 1 sibling, 1 reply; 20+ messages in thread From: Daniel Lipshitz @ 2022-12-14 8:12 UTC (permalink / raw) To: John Carvalho; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1786 bytes --] A 0-conf double spend caused by FSS-RBF would be harmless since the original output (address and amounts) remain in the double spending trx. So all a merchant would need to do is monitor block inclusion for the relevant output. Addition of some wallet logic would resolve it easily. Technically the only difference is that a FSS-RBF requires an additional input trx to be included in the second trx. Not clear to me, why the limitation of adding an additional input hinders the added value of FullRBF and how significant that hinderance is. On Tue, 13 Dec 2022 at 11:59 John Carvalho <john@synonym.to> wrote: > Why wasn't this solution put in place back then? Are there problems with > the design? > > While I still think there are unhealthy side-effects of Full-RBF (like > more doublespending at unknowing merchants, after years of FSS protection) > I think discussion of this FSS-RBF feature is worth considering. > > -- > John Carvalho > CEO, Synonym.to <http://synonym.to/> > > > On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> wrote: > >> Thank you for bringing that to my attention, apologies for not being >> aware of it. >> >> First-seen-safe replace-by-fee as detailed here >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >> by Peter Todd seems to be a very suitable option and route >> which balances FullRBF while retaining the significant 0-conf use case. >> >> This would seem like a good way forward. >> >> >> >> ________________________________ >> >> >> >> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> >> wrote: >> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>> >> -- ________________________________ Daniel Lipshitz GAP600 www.Gap600.com [-- Attachment #2: Type: text/html, Size: 4075 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 2022-12-14 8:12 ` Daniel Lipshitz @ 2022-12-14 17:41 ` Erik Aronesty 0 siblings, 0 replies; 20+ messages in thread From: Erik Aronesty @ 2022-12-14 17:41 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion; +Cc: John Carvalho [-- Attachment #1: Type: text/plain, Size: 2237 bytes --] NACK support for 0-conf is harmful for reasons already stated ad nauseum On Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A 0-conf double spend caused by FSS-RBF would be harmless since the > original output (address and amounts) remain in the double spending trx. > > So all a merchant would need to do is monitor block inclusion for the > relevant output. Addition of some wallet logic would resolve it easily. > > Technically the only difference is that a FSS-RBF requires an additional > input trx to be included in the second trx. > > Not clear to me, why the limitation of adding an additional input hinders > the added value of FullRBF and how significant that hinderance is. > > > > On Tue, 13 Dec 2022 at 11:59 John Carvalho <john@synonym.to> wrote: > >> Why wasn't this solution put in place back then? Are there problems with >> the design? >> >> While I still think there are unhealthy side-effects of Full-RBF (like >> more doublespending at unknowing merchants, after years of FSS protection) >> I think discussion of this FSS-RBF feature is worth considering. >> >> -- >> John Carvalho >> CEO, Synonym.to <http://synonym.to/> >> >> >> On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> >> wrote: >> >>> Thank you for bringing that to my attention, apologies for not being >>> aware of it. >>> >>> First-seen-safe replace-by-fee as detailed here >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>> by Peter Todd seems to be a very suitable option and route >>> which balances FullRBF while retaining the significant 0-conf use case. >>> >>> This would seem like a good way forward. >>> >>> >>> >>> ________________________________ >>> >>> >>> >>> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman <nothingmuch@woobling.org> >>> wrote: >>> >>>> >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>>> >>> -- > ________________________________ > 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: 4820 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2023-02-06 12:08 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-11 20:24 [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case Daniel Lipshitz 2022-12-13 4:20 ` Yuval Kogman 2022-12-13 8:08 ` Daniel Lipshitz 2022-12-13 9:59 ` John Carvalho 2022-12-13 11:33 ` Daniel Lipshitz 2022-12-13 14:00 ` Lucas Ontivero 2022-12-13 14:08 ` Daniel Lipshitz 2022-12-13 21:41 ` Peter Todd 2022-12-13 21:58 ` Daniel Lipshitz 2022-12-16 21:14 ` Peter Todd 2022-12-18 8:06 ` Daniel Lipshitz 2023-01-13 23:53 ` Peter Todd 2023-01-14 20:15 ` Daniel Lipshitz 2023-01-16 10:19 ` Daniel Lipshitz 2023-01-17 17:07 ` Erik Aronesty 2023-01-17 17:27 ` Daniel Lipshitz 2023-02-04 16:27 ` Peter Todd 2023-02-06 12:08 ` Daniel Lipshitz 2022-12-14 8:12 ` Daniel Lipshitz 2022-12-14 17:41 ` Erik Aronesty
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox