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