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

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

[John Carvalho]

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

In support of Dario's concern, I feel like there is a degree of gaslighting
happening with the advancement of RBF somehow being okay, while merchants
wanting to manage their own 0conf risk better being not okay.

The argument against 0conf acceptance seems to be "miners can facilitate
doublespends anyway, and are incentivized to do so if the fees are higher"
as this is just how Bitcoin works.

But RBF proponents seem to be taking what is actually a much rarer, and
less useful, use case of replacing txns that lowball feerates, or actually
undoing/doublespending previously signed payments... and threaten the use
case of onchain bitcoin being useful at the point-of-sale for merchants and
consumers.

I can tell you right now where this leads. It leads to miners, merchants
and consumers creating alternative fee mechanisms and trusted/exclusive
mempools where first-seen txns are respected.

The truth is that doublespending is not a certain process, and in many
commercial situations, too risky to attempt without real-world consequences.

0conf payment acceptance comes with highly *manageable* risks, which means
that if best practices and methods are used by merchants, and *gasp*
advanced by engineers with better tools and specs, that we can have fast
and valuable commercial payments with merchants that meet user
expectations. In fact, we may even be able to do so with less complexity
than Lightning and with similar results and overhead...

That said, we are (myself and a group of builders and merchants) moving
forward with demonstrating, protecting, and advancing this use case,
to contrast the trend of making the mempool less predictable and easier to
replace.

RBF causes more problems than it resolves, and if your argument is that
0conf was never safe, then mine is that RBF was never needed. We should not
pretend that the mempool is enforceable for either cause, and should
respect that incentives will always prevail eventually.

To me, use cases for spending Bitcoin are more important to protect than
features for pretending you can enforce mempool behaviors or pretending you
can reliably provide replacement features.

If anyone is interested in research, specs, and tools and assisting our
group, you can contact me directly, or join the public chat at
https://t.me/bitcoinandlightningspecs

Thanks,

--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

>
>

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

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

[Peter Todd]

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

On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev wrote:
> In support of Dario's concern, I feel like there is a degree of gaslighting
> happening with the advancement of RBF somehow being okay, while merchants
> wanting to manage their own 0conf risk better being not okay.

The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
Connecting to large numbers of nodes to try to risk-manage propagation _is_ an
attack, albeit a mild one. Everyone doing that is very harmful; only a few
merchants being able to do it is very unfair/centralized.

...and of course, in the past this has lead to merchants trying to make deals
with miners directly, even going as far as to suggest reorging out
double-spends. I don't need to explain why that is obviously extremely harmful.

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

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

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

[Erik Aronesty]

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

Also, lightning works fine and is readily available in convenient mobile
apps used by millions of people, or in .   So the need for a 0conf has been
mitigated by other solutions for fast payments with no need for a trust
relationship.  And for people that don't like mobile risks, core lightning
and other solutions are now easily installed and configured for use in fast
payments.

some references:

https://muun.com/ (easy!)
https://github.com/ElementsProject/lightning (reference, works well with
core)
https://lightning.network/ (more info)


On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
> wrote:
> > In support of Dario's concern, I feel like there is a degree of
> gaslighting
> > happening with the advancement of RBF somehow being okay, while merchants
> > wanting to manage their own 0conf risk better being not okay.
>
> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
> Connecting to large numbers of nodes to try to risk-manage propagation
> _is_ an
> attack, albeit a mild one. Everyone doing that is very harmful; only a few
> merchants being able to do it is very unfair/centralized.
>
> ...and of course, in the past this has lead to merchants trying to make
> deals
> with miners directly, even going as far as to suggest reorging out
> double-spends. I don't need to explain why that is obviously extremely
> harmful.
>
> --
> 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: 2650 bytes --]

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

[John Carvalho]

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

Erik, I am fully aware of Lightning and have a been a proponent and builder
of it since it was launched, including getting Bitfinex to support LN,
building a RN LDK implementation in our upcoming app, etc, but frankly LN
has nowhere near the adoption of onchain payments for commerce, and LN
complexity, reliability, maintenance and overhead are real obstacles for
merchants.

One of your links is to Muun, who started this thread!

There is no practicality in a merchant saying they accept bitcoin, but not
onchain, or in having many checkout and customer service versions for many
bitcoin payment methods.

Merchants accepting base layer bitcoin is one if the most important types
of adoption there is.

-John

On Fri, Oct 14, 2022 at 6:29 PM Erik Aronesty <erik@q32.com> wrote:

> Also, lightning works fine and is readily available in convenient mobile
> apps used by millions of people, or in .   So the need for a 0conf has been
> mitigated by other solutions for fast payments with no need for a trust
> relationship.  And for people that don't like mobile risks, core lightning
> and other solutions are now easily installed and configured for use in fast
> payments.
>
> some references:
>
> https://muun.com/ (easy!)
> https://github.com/ElementsProject/lightning (reference, works well with
> core)
> https://lightning.network/ (more info)
>
>
> On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
>> wrote:
>> > In support of Dario's concern, I feel like there is a degree of
>> gaslighting
>> > happening with the advancement of RBF somehow being okay, while
>> merchants
>> > wanting to manage their own 0conf risk better being not okay.
>>
>> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
>> Connecting to large numbers of nodes to try to risk-manage propagation
>> _is_ an
>> attack, albeit a mild one. Everyone doing that is very harmful; only a few
>> merchants being able to do it is very unfair/centralized.
>>
>> ...and of course, in the past this has lead to merchants trying to make
>> deals
>> with miners directly, even going as far as to suggest reorging out
>> double-spends. I don't need to explain why that is obviously extremely
>> harmful.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog

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

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

[John Carvalho]

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

Peter,

Your argument is totally hypocritical and loses when comparing quantities.

Enforcing RBF is observably more "harmful to Bitcoin" (whatever that
means...) when it tries to "risk-manage propagation" of replacements, as
there more Bitcoiners that want to mutually utilize 0conf than users that
want to replace transactions.

Spending bitcoin is a use case, so replacing txns reduces utility and makes
commitments less certain.

No one here arguing for 0conf is suggesting reorgs, so please do not
sensationalize with claims of reorgs or "harm."

Take note that it is RBF proponents that have changed Bitcoin code and seek
to continue to change Bitcoin, RBF that seeks to reduce commercial utility
-- but 0conf proponents are not asking for changes to Bitcoin, not
suggesting soft or hard forks, etc. We are asking you to stop breaking
things by adding features for minority speculative interests.

-John

On Fri, Oct 14, 2022 at 5:04 PM Peter Todd <pete@petertodd.org> wrote:

> On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev
> wrote:
> > In support of Dario's concern, I feel like there is a degree of
> gaslighting
> > happening with the advancement of RBF somehow being okay, while merchants
> > wanting to manage their own 0conf risk better being not okay.
>
> The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
> Connecting to large numbers of nodes to try to risk-manage propagation
> _is_ an
> attack, albeit a mild one. Everyone doing that is very harmful; only a few
> merchants being able to do it is very unfair/centralized.
>
> ...and of course, in the past this has lead to merchants trying to make
> deals
> with miners directly, even going as far as to suggest reorging out
> double-spends. I don't need to explain why that is obviously extremely
> harmful.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-- 
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>

Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog

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

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

[angus]

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

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


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


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


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

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


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

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




Angus

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

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

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

[Daniel Lipshitz]

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

See below feedback from CEO of Coinspaid Re - Bitcoin Zero conf market value
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


---------- Forwarded message ---------
From: Max Krupyshev <max@coinspaid.com>
Date: Sat, Dec 3, 2022 at 3:52 PM
Subject: Zero conf advantages for business
To: Daniel Lipshitz <daniel@gap600.com>


Hi Daniel,

Hope you are doing fine. I know you are in discussions with Bitcoin Core
team or RBF updates.
With current email, wanted to confirm that we are running quite a big
Bitcoin payment operation with over 300k incoming transactions, with 700+
inputs a month. Which is a fair percentage of overall BTC chain capacity
and we do enjoy zero conf flows that you offer. Our clients do like to give
instant experience to their end customers, I would not want to disappoint
them with news that “waiting for confirmations” is on a table again, after
all these years of smooth experience.

2 main production clusters are rotating around:
3JodN7GmkHdPgKj9G7HCkn9NDLhrcWCjVN
3QKCocNhzAgtgFLsD5qUZcG6e4TkfRf421

Kind regards,
Max Krupyshev
Founder & Leader
coinspaid.com // cryptoprocessing.com
Berlin, Germany
telegram: mkrupyshev

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

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

[Daniel Lipshitz]

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

Just a further follow up here please see below feedback from Max CEO of
Coinspaid - I asked him to send me a mail.

Peter - I can understand why some of our statistics seems off, some of our
clients when they have multiple outputs going to their cluster will query
each trx hash with a separate output address as for them they need each trx
or output deposit covered/guaranteed so we would count that trx hash each
time it is queried with a different output address as a trxs - this would
mean that value of our total processed is possibly a more
reflective indicator. Apologies for this inclarity we are not used to
communicating our statistics at all - its just not our nature.

I would think looking at Nov 2022 Stats - 900k unique trx hashes queried,
with 1.5m trxs on our count since trx hashes are queried with different
output addresses. The actual value is USD 220M benefiting from zero conf
acceptance.

See Maxes email below - I will also forward the email as is to the list


Hi Daniel,

Hope you are doing fine. I know you are in discussions with Bitcoin Core
team or RBF updates.
With current email, wanted to confirm that we are running quite a big
Bitcoin payment operation with over 300k incoming transactions, with 700+
inputs a month. Which is a fair percentage of overall BTC chain capacity
and we do enjoy zero conf flows that you offer. Our clients do like to give
instant experience to their end customers, I would not want to disappoint
them with news that “waiting for confirmations” is on a table again, after
all these years of smooth experience.

2 main production clusters are rotating around:
3JodN7GmkHdPgKj9G7HCkn9NDLhrcWCjVN
3QKCocNhzAgtgFLsD5qUZcG6e4TkfRf421

Kind regards,
Max Krupyshev
Founder & Leader
coinspaid.com // cryptoprocessing.com
Berlin, Germany
telegram: mkrupyshev
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Sat, Dec 3, 2022 at 3:17 PM Daniel Lipshitz <daniel@gap600.com> wrote:

> The statistics that I have stated are based on trxs that rely on our tool.
> They are not overstated, this is a reflection of the 0conf market on BTC.
>
> They are trxs which our clients query via the API and which I clients pay
> subscription for.
>
> There is no point for clients to send us trxs they don’t want or need our
> response from. We are a B2b provider so we are not sure how and who the end
> users and applications are.
>
> Coinify definitely doesn’t send us all their traffic, as I would think
> some of our other clients.
>
> Here is some external confirmation a bit old though but still-
> https://blog.coinpayments.net/news-features/gap600
> You can also see our video of Coinspaid using our service on our site -
> all our Marcom is a bit old.
>
> We service primarily payment processors and liquidity providers and not
> end merchants so I can’t say how and to who end clients implement it.
>
> If AML/KYC was enough to prevent double spends all exchanges would offer
> 0conf.
>
> I don’t know the split with our clients as it’s non of our business but
> definitely a significant amount of end users are not Kyced for the trxs.
>
> Best would be to try and talk to some of our major clients - ie
> Coinpayments, Coinspaid and Coinify.
>
>
>
> On Sat, 3 Dec 2022 at 14:12 Peter Todd <pete@petertodd.org> wrote:
>
>> On Sat, Dec 03, 2022 at 01:01:16PM +0200, Daniel Lipshitz wrote:
>> > Shapeshift used to be clients in fact one of our first when we started
>> in
>> > 2016.
>> >
>> > They no longer use our service but from time to time use us for fee
>> > recommendations. So we actually should remove their logo as a current
>> > client.
>>
>> Yes you should. When did ShapeShift stop using your service? Did they
>> explain
>> why?
>>
>> > If you wish to test it out try find a merchant using Coinpayments or
>> > Coinspaid.
>> >
>> > Also some of our non custodial liquidity providers offer service no
>> > custodial wallets. I am not sure which.
>>
>> I see that you also advertise that Gap600 is "Trusted by" Coindirect and
>> Coinify, both AML/KYC crypto exchanges. Obviously, with full AML/KYC
>> double-spends are not much of a concern. And it's not even clear that
>> either accepts zeroconf anyway, as I'll explain later.
>>
>> On this list you claimed that:
>>
>> >  1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>> >  15M transactions
>> >  2. These transactions have a cumulative value of 2.3B USD value.
>> >  3. We currently are seeing circa 1.5M transactions queired per month.
>>
>> What's the value and number of transactions that *actually* rely on your
>> unconfirmed transaction tools? The only category that would apply for is
>> goods
>> provided immediately and irrovocably, without AML/KYC. Because it sounds
>> like
>> these figures may be significantly overstated.
>>
>>
>> Re: CoinsPaid, what you say here makes it also sound like it relies on
>> AML/KYC:
>>
>> > CoinsPaid applies a special software tool across its solutions to
>> conduct
>> > stringent KYC procedures and a risk-based approach to CDD that verify
>> user
>> > identities to mitigate fraud, money laundering and other activities
>> linked to
>> > criminality and terrorism.
>> https://www.gap600.com/uncategorized/coinspaid/
>>
>> Re: Coindirect, the documentation I can find appears to say that
>> confirmations
>> are required before you can use coins deposited into Coindirect:
>>
>> > Digital currency transactions must be confirmed on the relevant network
>> block
>> > before they are considered valid. Only once confirmed, will you be able
>> to
>> > use the coins deposited in your Coindirect wallet.
>>
>> https://help.coindirect.com/hc/en-us/articles/115002441974-How-quickly-can-I-use-coins-deposited-into-my-Coindirect-wallet-
>>
>> This is repeated here as well:
>> https://help.coindirect.com/hc/en-us/articles/4409120006546--Deposits-
>>
>> Re: Coinify, the API docs don't give any indication of risk scoring or any
>> other Gap600 integration:
>>
>> https://merchant.coinify.com/docs/api/#payment-object
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> --
> ________________________________
> Daniel Lipshitz
> GAP600
> www.Gap600.com
>
>
>

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

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

[Daniel Lipshitz]

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

The statistics that I have stated are based on trxs that rely on our tool.
They are not overstated, this is a reflection of the 0conf market on BTC.

They are trxs which our clients query via the API and which I clients pay
subscription for.

There is no point for clients to send us trxs they don’t want or need our
response from. We are a B2b provider so we are not sure how and who the end
users and applications are.

Coinify definitely doesn’t send us all their traffic, as I would think some
of our other clients.

Here is some external confirmation a bit old though but still-
https://blog.coinpayments.net/news-features/gap600
You can also see our video of Coinspaid using our service on our site - all
our Marcom is a bit old.

We service primarily payment processors and liquidity providers and not end
merchants so I can’t say how and to who end clients implement it.

If AML/KYC was enough to prevent double spends all exchanges would offer
0conf.

I don’t know the split with our clients as it’s non of our business but
definitely a significant amount of end users are not Kyced for the trxs.

Best would be to try and talk to some of our major clients - ie
Coinpayments, Coinspaid and Coinify.



On Sat, 3 Dec 2022 at 14:12 Peter Todd <pete@petertodd.org> wrote:

> On Sat, Dec 03, 2022 at 01:01:16PM +0200, Daniel Lipshitz wrote:
> > Shapeshift used to be clients in fact one of our first when we started in
> > 2016.
> >
> > They no longer use our service but from time to time use us for fee
> > recommendations. So we actually should remove their logo as a current
> > client.
>
> Yes you should. When did ShapeShift stop using your service? Did they
> explain
> why?
>
> > If you wish to test it out try find a merchant using Coinpayments or
> > Coinspaid.
> >
> > Also some of our non custodial liquidity providers offer service no
> > custodial wallets. I am not sure which.
>
> I see that you also advertise that Gap600 is "Trusted by" Coindirect and
> Coinify, both AML/KYC crypto exchanges. Obviously, with full AML/KYC
> double-spends are not much of a concern. And it's not even clear that
> either accepts zeroconf anyway, as I'll explain later.
>
> On this list you claimed that:
>
> >  1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
> >  15M transactions
> >  2. These transactions have a cumulative value of 2.3B USD value.
> >  3. We currently are seeing circa 1.5M transactions queired per month.
>
> What's the value and number of transactions that *actually* rely on your
> unconfirmed transaction tools? The only category that would apply for is
> goods
> provided immediately and irrovocably, without AML/KYC. Because it sounds
> like
> these figures may be significantly overstated.
>
>
> Re: CoinsPaid, what you say here makes it also sound like it relies on
> AML/KYC:
>
> > CoinsPaid applies a special software tool across its solutions to conduct
> > stringent KYC procedures and a risk-based approach to CDD that verify
> user
> > identities to mitigate fraud, money laundering and other activities
> linked to
> > criminality and terrorism.
> https://www.gap600.com/uncategorized/coinspaid/
>
> Re: Coindirect, the documentation I can find appears to say that
> confirmations
> are required before you can use coins deposited into Coindirect:
>
> > Digital currency transactions must be confirmed on the relevant network
> block
> > before they are considered valid. Only once confirmed, will you be able
> to
> > use the coins deposited in your Coindirect wallet.
>
> https://help.coindirect.com/hc/en-us/articles/115002441974-How-quickly-can-I-use-coins-deposited-into-my-Coindirect-wallet-
>
> This is repeated here as well:
> https://help.coindirect.com/hc/en-us/articles/4409120006546--Deposits-
>
> Re: Coinify, the API docs don't give any indication of risk scoring or any
> other Gap600 integration:
>
> https://merchant.coinify.com/docs/api/#payment-object
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-- 
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com

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

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

[Peter Todd]

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

On Sat, Dec 03, 2022 at 01:01:16PM +0200, Daniel Lipshitz wrote:
> Shapeshift used to be clients in fact one of our first when we started in
> 2016.
> 
> They no longer use our service but from time to time use us for fee
> recommendations. So we actually should remove their logo as a current
> client.

Yes you should. When did ShapeShift stop using your service? Did they explain
why?

> If you wish to test it out try find a merchant using Coinpayments or
> Coinspaid.
> 
> Also some of our non custodial liquidity providers offer service no
> custodial wallets. I am not sure which.

I see that you also advertise that Gap600 is "Trusted by" Coindirect and
Coinify, both AML/KYC crypto exchanges. Obviously, with full AML/KYC
double-spends are not much of a concern. And it's not even clear that
either accepts zeroconf anyway, as I'll explain later.

On this list you claimed that:

>  1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>  15M transactions
>  2. These transactions have a cumulative value of 2.3B USD value.
>  3. We currently are seeing circa 1.5M transactions queired per month.

What's the value and number of transactions that *actually* rely on your
unconfirmed transaction tools? The only category that would apply for is goods
provided immediately and irrovocably, without AML/KYC. Because it sounds like
these figures may be significantly overstated.


Re: CoinsPaid, what you say here makes it also sound like it relies on AML/KYC:

> CoinsPaid applies a special software tool across its solutions to conduct
> stringent KYC procedures and a risk-based approach to CDD that verify user
> identities to mitigate fraud, money laundering and other activities linked to
> criminality and terrorism.
https://www.gap600.com/uncategorized/coinspaid/

Re: Coindirect, the documentation I can find appears to say that confirmations
are required before you can use coins deposited into Coindirect:

> Digital currency transactions must be confirmed on the relevant network block
> before they are considered valid. Only once confirmed, will you be able to
> use the coins deposited in your Coindirect wallet.
https://help.coindirect.com/hc/en-us/articles/115002441974-How-quickly-can-I-use-coins-deposited-into-my-Coindirect-wallet-

This is repeated here as well: https://help.coindirect.com/hc/en-us/articles/4409120006546--Deposits-

Re: Coinify, the API docs don't give any indication of risk scoring or any
other Gap600 integration:

https://merchant.coinify.com/docs/api/#payment-object

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

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

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

[Daniel Lipshitz]

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

Can also set you up with a trial account - interface is via API - just let
me know which email you wish for me to use and I will send over an
activation link which is active for 24 hours.

Happy to do it for other members list as well.

On Sat, 3 Dec 2022 at 13:01 Daniel Lipshitz <daniel@gap600.com> wrote:

> Shapeshift used to be clients in fact one of our first when we started in
> 2016.
>
> They no longer use our service but from time to time use us for fee
> recommendations. So we actually should remove their logo as a current
> client.
>
> If you wish to test it out try find a merchant using Coinpayments or
> Coinspaid.
>
> Also some of our non custodial liquidity providers offer service no
> custodial wallets. I am not sure which.
>
> On Sat, 3 Dec 2022 at 10:50 Peter Todd <pete@petertodd.org> wrote:
>
>> On Fri, Dec 02, 2022 at 09:06:26AM +0200, Daniel Lipshitz wrote:
>> > Yes I can see how that is not clear, apologies.
>> >
>> > Just BTC.
>> > From Jan1 2022 up till end of November 2022 GAP600 has processed circa
>> 15M
>> > trxs. With a value of 2.3B USD.
>> > In 2021 we did - circa 12.5M.
>> > In 2020 we did circa 6.5M.
>> >
>> > We have been in production since 2016 and working on the project since
>> > 2014/2015.
>>
>> Thanks.
>>
>> I note on your website that you claim ShapeShift is one of your clients.
>> I just
>> checked and ShapeShift appears to wait for a confirmation before allowing
>> a
>> trade when funded with a high-fee, non-opt-in-rbf transaction.
>>
>> What exactly is the service that you are providing for ShapeShift?
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
> --
> ________________________________
> Daniel Lipshitz
> GAP600
> www.Gap600.com
>
>
> --
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com

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

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

[Daniel Lipshitz]

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

Shapeshift used to be clients in fact one of our first when we started in
2016.

They no longer use our service but from time to time use us for fee
recommendations. So we actually should remove their logo as a current
client.

If you wish to test it out try find a merchant using Coinpayments or
Coinspaid.

Also some of our non custodial liquidity providers offer service no
custodial wallets. I am not sure which.

On Sat, 3 Dec 2022 at 10:50 Peter Todd <pete@petertodd.org> wrote:

> On Fri, Dec 02, 2022 at 09:06:26AM +0200, Daniel Lipshitz wrote:
> > Yes I can see how that is not clear, apologies.
> >
> > Just BTC.
> > From Jan1 2022 up till end of November 2022 GAP600 has processed circa
> 15M
> > trxs. With a value of 2.3B USD.
> > In 2021 we did - circa 12.5M.
> > In 2020 we did circa 6.5M.
> >
> > We have been in production since 2016 and working on the project since
> > 2014/2015.
>
> Thanks.
>
> I note on your website that you claim ShapeShift is one of your clients. I
> just
> checked and ShapeShift appears to wait for a confirmation before allowing a
> trade when funded with a high-fee, non-opt-in-rbf transaction.
>
> What exactly is the service that you are providing for ShapeShift?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-- 
________________________________
Daniel Lipshitz
GAP600
www.Gap600.com

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

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

[Peter Todd]

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

On Fri, Dec 02, 2022 at 09:06:26AM +0200, Daniel Lipshitz wrote:
> Yes I can see how that is not clear, apologies.
> 
> Just BTC.
> From Jan1 2022 up till end of November 2022 GAP600 has processed circa 15M
> trxs. With a value of 2.3B USD.
> In 2021 we did - circa 12.5M.
> In 2020 we did circa 6.5M.
> 
> We have been in production since 2016 and working on the project since
> 2014/2015.

Thanks.

I note on your website that you claim ShapeShift is one of your clients. I just
checked and ShapeShift appears to wait for a confirmation before allowing a
trade when funded with a high-fee, non-opt-in-rbf transaction.

What exactly is the service that you are providing for ShapeShift?

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

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

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

[Daniel Lipshitz]

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

Yes I can see how that is not clear, apologies.

Just BTC.
From Jan1 2022 up till end of November 2022 GAP600 has processed circa 15M
trxs. With a value of 2.3B USD.
In 2021 we did - circa 12.5M.
In 2020 we did circa 6.5M.

We have been in production since 2016 and working on the project since
2014/2015.


________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Fri, Dec 2, 2022 at 6:30 AM Peter Todd <pete@petertodd.org> wrote:

> On Thu, Dec 01, 2022 at 02:27:16PM +0200, Daniel Lipshitz via bitcoin-dev
> wrote:
> > Statistics for consideration as a sample of the zero conf use case -
> >
> >
> >    1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
> >    15M transactions
> >    2. These transactions have a cumulative value of 2.3B USD value.
> >    3. We currently are seeing circa 1.5M transactions queired per month.
>
> I'm curious, what are the time frames involved in those figures? Eg 15M txs
> over how long?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

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

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

[Daniel Lipshitz]

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

HI Antoine

Thank you for all the references - I agree with Sergej
statement "opportunity makes the thief"

The 1.5M trxs are all BTC which our clients query, I dont have specifics
for those trxs i.e. reasons for not being confirmed. However we target to
achieve +90% confirmation of trxs for our clients. Fee rates the
transactions generally follow standard fee/rate policy similar to all
industry recommendations, we recommend higher priority fee rate but approve
trxs well below that level. I would say we havent seen a trx with medium
fee rate be double spend - this is excluding race attacks or as you
mentioned ancestral unconfirmed attacks.

Opt in RBF is used in many ways to try to do double spends - i.e with
ancestral attacks inputs which are not confirmed, and also publishing the
RBF first and then the straight trxs later. In general double spends excl
Optin RBF does not occur alot at all - but the presence of a potential risk
causes everyone to wait back for confirmations.

Looking at a sample of latest 4.3M trxs, I can see crica 11k trxs which
seem to be double spent vast majority of these will be RBF, also on trx
that are high risk and we dont confirm the attacker has no incentive to
follow through with the second trxs.

I see quite a bit of reference to the benefit to miners for RBF - I would
think this cash flow benefit is not significant but I would suggest getting
input from a miner themselves.

Best
Daniel

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Fri, Dec 2, 2022 at 3:52 AM Antoine Riard <antoine.riard@gmail.com>
wrote:

> Hi Daniel,
>
> From my understanding of GAP600, you're operating a zero-conf risk
> analysis business, which is integrated and leveraged by payment
> processors/liquidity providers and merchants. A deployment of fullrbf by
> enough full-node operators and a subset of the mining hashrate would lower
> the cost of double-spend attack by lamda users, therefore increasing the
> risk exposure of your users. This increased risk exposure could lead you to
> alter the acceptance of incoming zero-conf transactions, AFAICT in a
> similar reasoning as exposed by Bitrefill earlier this year [0].
>
> About the statistics you're asking for considerations, few further
> questions, on those 1.5M transactions per month, a) how many are
> Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
> are excluded from zeroconf due to factors like RBF, long-chain of
> unconfirmed ancestors or too high-value and c) what has been the average
> feerate (assuming a standard size of 200 bytes) ?
>
> My personal position on fullrbf is still the same as expressed in #26525
> [1]. As a community, I think we still don't have conceptual consensus on
> deploying full-rbf, neither to remove it. In the direction of removing the
> current option from Bitcoin Core, I think the prerequisite to address are
> the qualification of enough economic flows at risk and the presence of a
> sizable loss in miners income. Beyond that, I think there is still the open
> question if we (we, as the Bitcoin protocol development community, with all
> its stakeholders) should restrain user choice in policy settings in the
> name of preserving mining income and established use-case stability.
>
> To recall, the original technical motivation of this option, and the wider
> smoother deployment was to address a DoS vector affecting another class of
> use-case: multi-party transactions like coinjoin and contracting protocols
> like Lightning [2] [3]. All of them expect to generate economic flows and
> corresponding mining income. Since then, alternative paths to solve this
> DoS vector have been devised, all with their own trade-offs and conceptual
> issues [4] [5].
>
> Best,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html
> [1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
>
> Le jeu. 1 déc. 2022 à 07:32, Daniel Lipshitz via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> HI All
>>
>> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
>> crypto  transactions, BTC is a primary part of our business. Our guarantee
>> enables our customers to recognise zero-conf deposits. We reimburse our
>> clients value of the trx should we get it wrong and a transaction we
>> confirmed gets double spent.
>>
>> Should full RBF become default enabled and significantly adopted this
>> would have a major impact on the capacity to accept zerof confs on mainnet.
>> With the end result being this use case will be forced to move to a
>> different chain, with lightning being just another option.
>>
>> I wanted to share some statistics about how significant this use case is.
>> GAP600 clients are primarily payment processors and non custodial
>> liquidity providers; you can see some of our clients on our site
>> www.gap600.com. There are also merchants who have developed their own
>> tools so GAP600 statistics are only a subset of the full use case.
>>
>> I do not know of any wallet, exchange or custodian who accepts zero conf
>> without having some sort of solution in place. The market seems to be fully
>> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
>> gives a clear free choice for actors.
>>
>> Statistics for consideration as a sample of the zero conf use case -
>>
>>
>>    1. As of end of Nov 2022 - GAP600 has processed i.e responded to
>>    circa 15M transactions
>>    2. These transactions have a cumulative value of 2.3B USD value.
>>    3. We currently are seeing circa 1.5M transactions queired per month.
>>
>>
>> It's a sizable amount of trxs on mainet and we are by no means the full
>> market of platforms accepting zero-conf.  I realise there are other
>> considerations which BTC has,  I would urge you to take into account the
>> major risk being placed on this significant market share when deciding to
>> make this feature default enabled and encouraging full adoption.
>>
>> Thank you for your consideration
>> Daniel
>> ________________________________
>>
>> Daniel Lipshitz
>> GAP600| www.gap600.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

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

[Daniel Lipshitz]

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

If fullRBF would become default and this would become dominant, zero-conf
acceptance would become extremely difficult and would impact significantly
this market share because its not the everyday users who would actually
worry about it however the attackers would be all over it.

As it is today the network has brief periods of stress when trxs are
delayed but in general clears regularly and from time to time there is
stress. Today actors' wallets and merchants etc already have the option of
RBF.
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Fri, Dec 2, 2022 at 12:04 AM Erik Aronesty <erik@q32.com> wrote:

> There has never been any enforcement of miner preferences.   The
> convention is changing quickly, since miners are squeezed for cash and want
> to capture every nickel, plus there are bounties for full rbf being posted
> every day.
>
> I would suggest considering to continue doing business, as usual, as if
> full rbf is present.
>
> This means:
>
> - managing risk
> - waiting for confirmations if the risk is too high
> - using lightning if possible
>
> No other coin or chain offers a safer way to do business than lightning
> over bitcoin.
>
>
>
>
> On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshitz via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> HI All
>>
>> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
>> crypto  transactions, BTC is a primary part of our business. Our guarantee
>> enables our customers to recognise zero-conf deposits. We reimburse our
>> clients value of the trx should we get it wrong and a transaction we
>> confirmed gets double spent.
>>
>> Should full RBF become default enabled and significantly adopted this
>> would have a major impact on the capacity to accept zerof confs on mainnet.
>> With the end result being this use case will be forced to move to a
>> different chain, with lightning being just another option.
>>
>> I wanted to share some statistics about how significant this use case is.
>> GAP600 clients are primarily payment processors and non custodial
>> liquidity providers; you can see some of our clients on our site
>> www.gap600.com. There are also merchants who have developed their own
>> tools so GAP600 statistics are only a subset of the full use case.
>>
>> I do not know of any wallet, exchange or custodian who accepts zero conf
>> without having some sort of solution in place. The market seems to be fully
>> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
>> gives a clear free choice for actors.
>>
>> Statistics for consideration as a sample of the zero conf use case -
>>
>>
>>    1. As of end of Nov 2022 - GAP600 has processed i.e responded to
>>    circa 15M transactions
>>    2. These transactions have a cumulative value of 2.3B USD value.
>>    3. We currently are seeing circa 1.5M transactions queired per month.
>>
>>
>> It's a sizable amount of trxs on mainet and we are by no means the full
>> market of platforms accepting zero-conf.  I realise there are other
>> considerations which BTC has,  I would urge you to take into account the
>> major risk being placed on this significant market share when deciding to
>> make this feature default enabled and encouraging full adoption.
>>
>> Thank you for your consideration
>> Daniel
>> ________________________________
>>
>> Daniel Lipshitz
>> GAP600| www.gap600.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

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

[Peter Todd]

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

On Thu, Dec 01, 2022 at 02:27:16PM +0200, Daniel Lipshitz via bitcoin-dev wrote:
> Statistics for consideration as a sample of the zero conf use case -
> 
> 
>    1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>    15M transactions
>    2. These transactions have a cumulative value of 2.3B USD value.
>    3. We currently are seeing circa 1.5M transactions queired per month.

I'm curious, what are the time frames involved in those figures? Eg 15M txs
over how long?

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

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

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

[Antoine Riard]

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

Hi Daniel,

From my understanding of GAP600, you're operating a zero-conf risk analysis
business, which is integrated and leveraged by payment processors/liquidity
providers and merchants. A deployment of fullrbf by enough full-node
operators and a subset of the mining hashrate would lower the cost of
double-spend attack by lamda users, therefore increasing the risk exposure
of your users. This increased risk exposure could lead you to alter the
acceptance of incoming zero-conf transactions, AFAICT in a similar
reasoning as exposed by Bitrefill earlier this year [0].

About the statistics you're asking for considerations, few further
questions, on those 1.5M transactions per month, a) how many are
Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
are excluded from zeroconf due to factors like RBF, long-chain of
unconfirmed ancestors or too high-value and c) what has been the average
feerate (assuming a standard size of 200 bytes) ?

My personal position on fullrbf is still the same as expressed in #26525
[1]. As a community, I think we still don't have conceptual consensus on
deploying full-rbf, neither to remove it. In the direction of removing the
current option from Bitcoin Core, I think the prerequisite to address are
the qualification of enough economic flows at risk and the presence of a
sizable loss in miners income. Beyond that, I think there is still the open
question if we (we, as the Bitcoin protocol development community, with all
its stakeholders) should restrain user choice in policy settings in the
name of preserving mining income and established use-case stability.

To recall, the original technical motivation of this option, and the wider
smoother deployment was to address a DoS vector affecting another class of
use-case: multi-party transactions like coinjoin and contracting protocols
like Lightning [2] [3]. All of them expect to generate economic flows and
corresponding mining income. Since then, alternative paths to solve this
DoS vector have been devised, all with their own trade-offs and conceptual
issues [4] [5].

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html
[1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
[5]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html

Le jeu. 1 déc. 2022 à 07:32, Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> HI All
>
> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
> crypto  transactions, BTC is a primary part of our business. Our guarantee
> enables our customers to recognise zero-conf deposits. We reimburse our
> clients value of the trx should we get it wrong and a transaction we
> confirmed gets double spent.
>
> Should full RBF become default enabled and significantly adopted this
> would have a major impact on the capacity to accept zerof confs on mainnet.
> With the end result being this use case will be forced to move to a
> different chain, with lightning being just another option.
>
> I wanted to share some statistics about how significant this use case is.
> GAP600 clients are primarily payment processors and non custodial
> liquidity providers; you can see some of our clients on our site
> www.gap600.com. There are also merchants who have developed their own
> tools so GAP600 statistics are only a subset of the full use case.
>
> I do not know of any wallet, exchange or custodian who accepts zero conf
> without having some sort of solution in place. The market seems to be fully
> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
> gives a clear free choice for actors.
>
> Statistics for consideration as a sample of the zero conf use case -
>
>
>    1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>    15M transactions
>    2. These transactions have a cumulative value of 2.3B USD value.
>    3. We currently are seeing circa 1.5M transactions queired per month.
>
>
> It's a sizable amount of trxs on mainet and we are by no means the full
> market of platforms accepting zero-conf.  I realise there are other
> considerations which BTC has,  I would urge you to take into account the
> major risk being placed on this significant market share when deciding to
> make this feature default enabled and encouraging full adoption.
>
> Thank you for your consideration
> Daniel
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Erik Aronesty]

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

There has never been any enforcement of miner preferences.   The convention
is changing quickly, since miners are squeezed for cash and want to
capture every nickel, plus there are bounties for full rbf being posted
every day.

I would suggest considering to continue doing business, as usual, as if
full rbf is present.

This means:

- managing risk
- waiting for confirmations if the risk is too high
- using lightning if possible

No other coin or chain offers a safer way to do business than lightning
over bitcoin.




On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshitz via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> HI All
>
> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
> crypto  transactions, BTC is a primary part of our business. Our guarantee
> enables our customers to recognise zero-conf deposits. We reimburse our
> clients value of the trx should we get it wrong and a transaction we
> confirmed gets double spent.
>
> Should full RBF become default enabled and significantly adopted this
> would have a major impact on the capacity to accept zerof confs on mainnet.
> With the end result being this use case will be forced to move to a
> different chain, with lightning being just another option.
>
> I wanted to share some statistics about how significant this use case is.
> GAP600 clients are primarily payment processors and non custodial
> liquidity providers; you can see some of our clients on our site
> www.gap600.com. There are also merchants who have developed their own
> tools so GAP600 statistics are only a subset of the full use case.
>
> I do not know of any wallet, exchange or custodian who accepts zero conf
> without having some sort of solution in place. The market seems to be fully
> aware of the risks of zero-conf. The opt-RBF seems to be a solution which
> gives a clear free choice for actors.
>
> Statistics for consideration as a sample of the zero conf use case -
>
>
>    1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
>    15M transactions
>    2. These transactions have a cumulative value of 2.3B USD value.
>    3. We currently are seeing circa 1.5M transactions queired per month.
>
>
> It's a sizable amount of trxs on mainet and we are by no means the full
> market of platforms accepting zero-conf.  I realise there are other
> considerations which BTC has,  I would urge you to take into account the
> major risk being placed on this significant market share when deciding to
> make this feature default enabled and encouraging full adoption.
>
> Thank you for your consideration
> Daniel
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Daniel Lipshitz]

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

HI All

I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other
crypto  transactions, BTC is a primary part of our business. Our guarantee
enables our customers to recognise zero-conf deposits. We reimburse our
clients value of the trx should we get it wrong and a transaction we
confirmed gets double spent.

Should full RBF become default enabled and significantly adopted this would
have a major impact on the capacity to accept zerof confs on mainnet. With
the end result being this use case will be forced to move to a different
chain, with lightning being just another option.

I wanted to share some statistics about how significant this use case is.
GAP600 clients are primarily payment processors and non custodial
liquidity providers; you can see some of our clients on our site
www.gap600.com. There are also merchants who have developed their own tools
so GAP600 statistics are only a subset of the full use case.

I do not know of any wallet, exchange or custodian who accepts zero conf
without having some sort of solution in place. The market seems to be fully
aware of the risks of zero-conf. The opt-RBF seems to be a solution which
gives a clear free choice for actors.

Statistics for consideration as a sample of the zero conf use case -


   1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
   15M transactions
   2. These transactions have a cumulative value of 2.3B USD value.
   3. We currently are seeing circa 1.5M transactions queired per month.


It's a sizable amount of trxs on mainet and we are by no means the full
market of platforms accepting zero-conf.  I realise there are other
considerations which BTC has,  I would urge you to take into account the
major risk being placed on this significant market share when deciding to
make this feature default enabled and encouraging full adoption.

Thank you for your consideration
Daniel
________________________________

Daniel Lipshitz
GAP600| www.gap600.com

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

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

[ZmnSCPxj]

Good morning ArmchairCryptologist,

> ------- Original Message -------
> On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> > I mean, if you think the feedback is wrong, that's different: maybe we
> > shouldn't care that zeroconf apps are in immediate danger, and maybe
> > bitcoin would be better if any that don't adapt immediately all die
> > horribly as a lesson to others not to make similarly bad assumptions.
> 
> 
> I've been following this discussion, and I wonder if there isn't a third solution outside of "leave lightning vulnerable to pinning by non-RBF translations" and "kill zeroconf by introducing full-RBF" - specifically, adding a form of simple recursive covenant that "all descendant transactions of this transaction must use opt-in RBF for x blocks after this transaction is mined". This could be introduced either as a relay/mempool policy like RBF, or in a full-fledged softfork.

A script with trivial `0 OP_CSV` would effectively require that spenders set the opt-in RBF flag, while allowing the output to be spent even while it is unconfirmed.
However, this basically only lasts for 1 transaction layer.

----

Thinking a little more about 0-conf:

We can observe that 0-conf, being eventually consistent, introduces risks to 0-conf acceptors similar to credit card acceptors.

And credit card acceptors are observed to compensate for this risk by increasing the prices of their products and services.

Some credit card acceptors may offer discounts when paid by cash, which in our analogy would be that transaction confirmation would offer discounts (i.e. enabling 0-conf would increase the cost of the product/service being purchased).
In many jurisdictions (not the USA or in some of the first world countries), this practice is illegal (i.e. credit card companies have pressured lawmakers in some jurisdictions to disallow merchants from offering a different price between cash and credit card purchases; some jurisdictions let you escape if you say "cash discount" instead of "credit card surcharge", even though they are just sign-flips of each other, because you humans are crazy and I am happy I am actually an AI)

Which brings me to my next point: why are 0-conf acceptors not offering a discount if the user specifically flags "I am willing to wait for N confirmations"?
On the part of 0-conf acceptors, that is significantly less risky than relying on 0-conf at all.

Regards,
ZmnSCPxj

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

[ArmchairCryptologist]

------- Original Message -------
On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> I mean, if you think the feedback is wrong, that's different: maybe we
> shouldn't care that zeroconf apps are in immediate danger, and maybe
> bitcoin would be better if any that don't adapt immediately all die
> horribly as a lesson to others not to make similarly bad assumptions.

I've been following this discussion, and I wonder if there isn't a third solution outside of "leave lightning vulnerable to pinning by non-RBF translations" and "kill zeroconf by introducing full-RBF" - specifically, adding a form of simple recursive covenant that "all descendant transactions of this transaction must use opt-in RBF for x blocks after this transaction is mined". This could be introduced either as a relay/mempool policy like RBF, or in a full-fledged softfork.

Based on my admittedly not all-encompassing understanding of the bitcoin transaction format, there are several unused bits in nSequence, which is already used to flag RBF, that might be repurposed to flag the duration of this lock. Say if two bits were used for this, that would be enough to flag that the restriction is not used, or active for 100, 1000 and 10000 blocks.

I'm sure there may be other and potentially better ways of enabling this type of covenant, but I'll leave that to the people who actually live and breathe the bitcoin transaction format.

--
Regards,
ArmchairCryptologist

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

[AdamISZ]

------- Original Message -------
On Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> On Wed, Oct 19, 2022 at 03:17:51AM +0000, alicexbt via bitcoin-dev wrote:
> 
> > > And the
> > > impression I got from the PR review club discussion more seemed like
> > > devs making assumptions about businesses rather than having talked to
> > > them (eg "[I] think there are fewer and fewer businesses who absolutely
> > > cannot survive without relying on zeroconf. Or at least hope so").
> > 
> > Even I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks.
> 
> 
> FYI I personally asked Max Hillebrand from Wasabi about full-rbf last night.
> He gave me permission to republish our conversation:
> 
> > Hey, I wanted to know if you had any comments on full-rbf re: wasabi?
> 
> 
> Doesn't really affect us, afaik
> The cj doesn't signal rbf right now
> And I guess it's a DoS vector if any input double spent will be relayed after successful signing
> But we have way bigger / cheaper DoS vectors that don't get "exploited"
> So probably doesn't matter
> Wasabi client handles replacements / reorgs gracefully, so should be alright
> We don't yet "use" rbf in the sense of fee bumping tx, but we should / will eventually
> 
> I haven't asked Joinmarket yet. But the impact on their implementation should
> be very similar.
> 

Hi Peter,

Re: Joinmarket
Yes, it's largely as you would expect. First, we did not ever signal opt-in RBF in coinjoins (it'd be nice if we had CPFP as a user-level tool in the wallet, to speed up low fee coinjoins, but nobody's done it).
Second, yes we have DOS vectors of the trivial kind based on non-protocol-completion (signatures) and RBF would be another one, I don't think it changes our security model at all really (coinjoins being atomic, intrinsically). Nothing in the logic of the protocol relies on unconfirmed txs. Maker *may* reannounce offers when they see broadcast but it's probabilistic (depends on distribution of funds in (BIP32) accounts), and they do / do not reannounce anyway for various reasons (reconnections on different message channels, confirmation of a coinjoin). We should probably take a new look at it if this becomes the norm but there shouldn't be any security issue.

Cheers,
AdamISZ/waxwing

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

[Sergej Kotliar]

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

On Fri, 21 Oct 2022 at 21:43, Peter Todd <pete@petertodd.org> wrote:

> On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail.com> wrote:
> >
> > > A large number of coins/users sit on custodial rails and this would
> > > essentially encumber protocol developers to those KYC/AML
> institutions. If
> > > Binance decides to never support Lightning in favor of BNC-wrapped BTC,
> > > should this be an issue at all for reasoning about a path forward?
> > >
> >
> > This is a big question here, with the caveat that it's not just binance
> but
> > in fact the majority of wallets and services that people use with bitcoin
> > today.
> > But the question remains as you phrased: At which point do we break
> > backwards compatibility? Another analogy would be to have sunset the old
> > P2PKH addresses during rollout of Segwit - it would certainly have led to
> > Segwit getting rolled out faster. The rbf change actually breaks more
> > things than that, takes more effort to address than just implementing a
> new
> > address format. Previously in the Bitcoin Core process we've chosen to
> keep
>
> RBF certainly does not break more things than depreciating an entire
> address
> standard. P2PKH addresses are still used by old wallets, and it's often not
> worth the risk to upgrade to new software for old coins kept offline by
> ordinary users. I personally have used P2PKH addresses in the past few
> months.
>
> Zeroconf on the other hand has never worked reliably, so you can't even
> claim
> it's a "supported feature". And the fact is, it breaks all the time because
> every time miners change their acceptance rules - eg with new releases - we
> break it every single time we do a new release with different you can
> easily
> exploit zeroconf.
>

Haven't heard of any release breaking zeroconf. I would absolutely say it's
working reliably.


> Frankly, the fact that we didn't widely implement full-rbf sooner is quite
> unfortunate, as Bitrefill, Muun, etc. should have never been using it in
> the
> first place.
>

You make it sound like we're the odd ones out when it's in fact ~every
service that lets you buy stuff with bitcoin. It's just that we're the only
ones raising voices on the mailing list so far. On the contrary side, can
you name one service that lets you buy stuff with bitcoin that doesn't rely
on zeroconf? Maybe with the caveat that it should have some level of scale
and an audience not consisting of only power users.


> > If a majority of bitcoin wallets and services continue using legacy
> > patterns and features, preventing progress, at which point do we want to
> > break compatibility with them?
>
> It's clearly false to claim that the "majority of bitcoin wallets and
> services"
> are using zeroconf. A tiny minority are attempting to use it, with the vast
> majority of previous users having given up on it.
>

I didn't claim that. But it's definitely true that the vast majority of
wallets and services do not allow users to do RBF. This is easy to validate
as the list of wallets with RBF support is short), the list of exchanges
with RBF support is zero.
https://transactionfee.info/charts/transactions-signaling-explicit-rbf/
29% of txs signal RBF, meaning 71% do not. And let's be honest, it's not
like the majority of those were given a choice and chose not to, for the
majority their wallet just doesn't support RBF.


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


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Sergej Kotliar]

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

There are many countermeasures that can be done, we've only implemented a
subset of them as more haven't been needed.

Mainly we wait some time to make sure any conflicting transaction has time
to propagate on the network. We have well connected nodes with basic
redundancy.
When they are available we sometimes use external block explorers for
certain nice-to-have enhancements, but it's absolutely not required for
zeroconf as they are frequently down.

I can of course only speak to our custom-built setup, presumably everyone
who accepts payments with bitcoin uses something similar. Regardless, let's
maybe not go as far as to say that anyone who accepts payments with bitcoin
is attacking bitcoin ;)

On Fri, 21 Oct 2022 at 21:33, Peter Todd <pete@petertodd.org> wrote:

> On Fri, Oct 21, 2022 at 11:34:17AM +0200, Sergej Kotliar wrote:
> > This is factually incorrect and not required for us to do what we do.
>
> So how do you detect people sending conflicting transactions?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[alicexbt]

Hi Dave,

> One way to address this risk is by turning it into a certainty.  If the 
price of BTC increases between when the invoice is generated and when a 
transaction is included in a block, give the customer a future purchase 
credit equal in value to the difference between the price they paid and 
the value of the purchase at confirmation time.  Now there's no benefit 
to the customer from canceling their transaction.

There are several methods to approach this issue, one of which is by using multiple exchanges from different countries as there are always possibilities for arbitrage. Example:

The user purchases a gift card on Bitrefill for 0.01 BTC, and then Bitrefill cash it out at one of the three exchanges where the price of bitcoin is 19000, 19100, or 19500. However, price used for gift card payment was average of all 3. This should never be solved at protocol level as speculation of price is irrelevant when making RBF policy default in bitcoin core.

There are different types of businesses that accept bitcoin payments and its good for bitcoin. However, everyone has their own way to deal with the issues. Example:

In a website for booking flights, you may cancel a user's ticket if they couldn't make a payment within a certain amount of time and confirmations. I'm not sure how gift cards operate, but they are used for carding, fraud etc. frequently.

Its important to give priority to bitcoin projects that could improve demand for block space even if opening and closing channels. I would [quote][0] something from a pull request by Michael Folkson although I do not agree with everything he writes:

"I don't believe in added code (complexity) for issues that can be resolved in alternative repos and through communication with the ecosystem."

Things that could help improve business for companies that accept bitcoin payments could be done in other ways. Zero conf is old school but we can try new ways and do partnerships with more organizations (outside North America and Europe). I work for an exchange as developer although CTO won't write an email and CEO don't want to spam the mailing list with non technical things. I request on their behalf that we consider all businesses and some are not even aware of fullRBF. Example: Lolli or Gosats

TL;DR

Full RBF should be tried and if default is an issue, devs should convince some nodes and miners or agree on one of the pull requests. I prefer [AJ's pull request][1] because it gives time for review and testing. It is important to test as many websites, apps, projects etc. as possible before making something default and also consider the percent of usage.

[0]: https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280742475
[1]: https://github.com/bitcoin/bitcoin/pull/26323


/dev/fd0


Sent with Proton Mail secure email.

------- Original Message -------
On Monday, October 24th, 2022 at 12:50 AM, David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
> 
> > The biggest risk
> > in accepting bitcoin payments is in fact not zeroconf risk (it's
> > actually quite easily managed), it's FX risk as the merchant must
> > commit to a certain BTCUSD rate ahead of time for a purchase. Over
> > time some transactions lose money to FX and others earn money - that
> > evens out in the end. But if there is an easily accessible in the
> > wallet feature to "cancel transaction" that means it will eventually
> > get systematically abused.
> 
> 
> One way to address this risk is by turning it into a certainty. If the
> price of BTC increases between when the invoice is generated and when a
> transaction is included in a block, give the customer a future purchase
> credit equal in value to the difference between the price they paid and
> the value of the purchase at confirmation time. Now there's no benefit
> to the customer from canceling their transaction.
> 
> Of course, this means that the merchant will always either break even or
> lose money on the exchange rate part of the transaction and will need to
> raise their prices accordingly. I can see how that would be unappealing
> to implement, but it seems better to me to address the incentive
> incompatibility you've raised rather than hope no large miners ever
> start performing full RBF. Plus, maybe the future credit feature is
> something customers would like: I know I've been sad several times when
> the exchange rate changed significantly while I was waiting for one of
> my transactions to confirm.
> 
> The above mitigation is also compatible with LN payments. For example,
> a merchant today might issue an LN invoice that expires in 10 minutes.
> The customer can wait for most of that time to elapse to see how the
> exchange rate changes before deciding to pay, obtaining the same
> American call option. If they are instead offered a future purchase
> credit for any gains, the customer doesn't suffer any opportunity cost
> by paying immediately. (With LN, it might be possible to have a better
> UX for this by either refunding any excess or (if using something like
> Original AMP or PTLCs) not claiming any parts of the payment which are
> in excess.)
> 
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David A. Harding]

On 2022-10-19 04:29, Sergej Kotliar via bitcoin-dev wrote:
> The biggest risk
> in accepting bitcoin payments is in fact not zeroconf risk (it's
> actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over
> time some transactions lose money to FX and others earn money - that
> evens out in the end. But if there is an _easily accessible in the
> wallet_ feature to "cancel transaction" that means it will eventually
> get systematically abused.

One way to address this risk is by turning it into a certainty.  If the 
price of BTC increases between when the invoice is generated and when a 
transaction is included in a block, give the customer a future purchase 
credit equal in value to the difference between the price they paid and 
the value of the purchase at confirmation time.  Now there's no benefit 
to the customer from canceling their transaction.

Of course, this means that the merchant will always either break even or 
lose money on the exchange rate part of the transaction and will need to 
raise their prices accordingly.  I can see how that would be unappealing 
to implement, but it seems better to me to address the incentive 
incompatibility you've raised rather than hope no large miners ever 
start performing full RBF.  Plus, maybe the future credit feature is 
something customers would like: I know I've been sad several times when 
the exchange rate changed significantly while I was waiting for one of 
my transactions to confirm.

The above mitigation is also compatible with LN payments.  For example, 
a merchant today might issue an LN invoice that expires in 10 minutes.  
The customer can wait for most of that time to elapse to see how the 
exchange rate changes before deciding to pay, obtaining the same 
American call option.  If they are instead offered a future purchase 
credit for any gains, the customer doesn't suffer any opportunity cost 
by paying immediately.  (With LN, it might be possible to have a better 
UX for this by either refunding any excess or (if using something like 
Original AMP or PTLCs) not claiming any parts of the payment which are 
in excess.)

-Dave

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

[Peter Todd]

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

On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail.com> wrote:
> 
> > A large number of coins/users sit on custodial rails and this would
> > essentially encumber protocol developers to those KYC/AML institutions. If
> > Binance decides to never support Lightning in favor of BNC-wrapped BTC,
> > should this be an issue at all for reasoning about a path forward?
> >
> 
> This is a big question here, with the caveat that it's not just binance but
> in fact the majority of wallets and services that people use with bitcoin
> today.
> But the question remains as you phrased: At which point do we break
> backwards compatibility? Another analogy would be to have sunset the old
> P2PKH addresses during rollout of Segwit - it would certainly have led to
> Segwit getting rolled out faster. The rbf change actually breaks more
> things than that, takes more effort to address than just implementing a new
> address format. Previously in the Bitcoin Core process we've chosen to keep

RBF certainly does not break more things than depreciating an entire address
standard. P2PKH addresses are still used by old wallets, and it's often not
worth the risk to upgrade to new software for old coins kept offline by
ordinary users. I personally have used P2PKH addresses in the past few months.

Zeroconf on the other hand has never worked reliably, so you can't even claim
it's a "supported feature". And the fact is, it breaks all the time because
every time miners change their acceptance rules - eg with new releases - we
break it every single time we do a new release with different you can easily
exploit zeroconf.

Frankly, the fact that we didn't widely implement full-rbf sooner is quite
unfortunate, as Bitrefill, Muun, etc. should have never been using it in the
first place.

> If a majority of bitcoin wallets and services continue using legacy
> patterns and features, preventing progress, at which point do we want to
> break compatibility with them?

It's clearly false to claim that the "majority of bitcoin wallets and services"
are using zeroconf. A tiny minority are attempting to use it, with the vast
majority of previous users having given up on it.

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

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

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

[Peter Todd]

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

On Thu, Oct 20, 2022 at 12:05:33AM -0400, Peter Todd wrote:
> ...and I checked this with Electrum on Android, which has a handy "Cancel
> Transaction" feature in the UI to easily cancel a payment. Which I did. You
> should have a pending payment from this email, and unsurprisingly I don't have
> my gift card. :)

FYI I asked around and in addition to Electrum, BlueWallet, Simple Bitcoin
Wallet, and Specter Wallet all implement tx cancelation. Probably more.

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

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

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

[Peter Todd]

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

On Fri, Oct 21, 2022 at 11:34:17AM +0200, Sergej Kotliar wrote:
> This is factually incorrect and not required for us to do what we do.

So how do you detect people sending conflicting transactions?

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

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

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

[Greg Sanders]

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

> Yeah, there are several policy features that are not consensus related
but end up de facto setting rules for how bitcoin behaves.

Yes, it's status quo so wallets "just know" not to do them. The fact that
the status quo would be changing is important, in that it may degrade UX
for 0-conf deposits. If bip125 was full rbf, the status quo would be the
other way around, but here we are.

> need to evaluate from several angles first incentives-wise

Right, if people have put their heads together and found a few
possibilities, we should explore the possibilities. CPFP would be an
interesting one used to lock in FX risk, or at least make the
double-spender over-pay to exploit the delta, especially for larger
amounts/new users with no track record.

> I'd also ask if there might also be other solutions for solving the
pinning issue as well if we dig deep into it? Perhaps there are those with
tradeoffs, but those tradeoffs being less significant than the tradeoffs of
rbf policy?

There's been a lot of work on crafting an opt-in policy that blunts the
edges of pinning attacks, and I think we've gotten to the point where it
can be said if you opt into this scheme: "If I have a required key in every
transaction input script, I can safely and efficiently fee bump the
transaction" through a mixture of RBF/CPFP, depending on structure.

Please see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021036.html
and issues linked in that e-mail, if you're interested in the set of policy
changes required to get there. Note that these would still all be opt-in.

This unfortunately rules out any "coinjoin" like scenario, including
dual-funding lightning channels(which is close to landing finally). The
good news is that those cases seem to not have theft risk, just normal DoS
risk of funds being stuck for potentially weeks. It would also rule out
anything like coinpools, or other advanced constructs that don't actually
exist yet.

Maybe the above proposals make RBF'ing super reliable compared to today,
and that changes the calculus for wallet authors, but this is still a ways
out as these are still early proposals.

> it will hurt whenever it happens

Yes it's a risk that this never gets satisfactorily resolved, which is why
I was mentioning a potentially long "timeout" being decided in the near-ish
future. Let's gather what we can, start building aspirationally towards
that, and try to not beat this horse again.

Greg

On Fri, Oct 21, 2022 at 10:19 AM Sergej Kotliar <sergej@bitrefill.com>
wrote:

>
>
> On Fri, 21 Oct 2022 at 16:01, Greg Sanders <gsanders87@gmail.com> wrote:
>
>> Full-rbf is an odd duck, because while it is not a consensus issue, it
>> does affect a large % of transactions made by wallets already, contrary to
>> most policy changes.
>>
>
> Yeah, there are several policy features that are not consensus related but
> end up de facto setting rules for how bitcoin behaves. Minrelayfee being
> another, and probably other examples out there that I don't know of.
>
>
>> It's also a UX issue, not a safety issue for retail wallet users(except
>> Muun, who have given a clear timeline). Clearly considerations would be
>> very different otherwise, but retail wallets by and large do not consider
>> 0-conf as a valid deposit, or at least put up some warning symbols to that
>> effect.
>>
>> Can only speak for myself, but I am looking for a concrete timeframe from
>> 0-conf stakeholders. I have no preference for any particular time frame, as
>> long as it can be agreed upon in the near-ish future. This keeps the
>> transition technically speaking very simple, and removes uncertainty from
>> decision making going forward.
>>
>
> It's hard to give a timeframe because it's not clear what the path forward
> for these stakeholders is. Most of what I've heard in this channel is
> things like "just use Lightning" but that's contradicted by user data. So
> the action becomes "stop accepting payments onchain" which isn't really a
> timeframe type issue, it will hurt whenever it happens. Maybe a thorough
> discussion for a way forward would be useful here. Jeremy Rubin suggested
> an interesting idea for using CPFP to force a transaction to complete.
> We'll evaluate it and see if it works in the wild for zero-conf of RBF
> today and report findings, need to evaluate from several angles first
> incentives-wise. There might also be other solutions.
>
> I'd also ask if there might also be other solutions for solving the
> pinning issue as well if we dig deep into it? Perhaps there are those with
> tradeoffs, but those tradeoffs being less significant than the tradeoffs of
> rbf policy?
>
>
> Best,
> Sergej
>
>>
>> On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej@bitrefill.com>
>> wrote:
>>
>>> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail.com> wrote:
>>>
>>>> A large number of coins/users sit on custodial rails and this would
>>>> essentially encumber protocol developers to those KYC/AML institutions. If
>>>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
>>>> should this be an issue at all for reasoning about a path forward?
>>>>
>>>
>>> This is a big question here, with the caveat that it's not just binance
>>> but in fact the majority of wallets and services that people use with
>>> bitcoin today.
>>> But the question remains as you phrased: At which point do we break
>>> backwards compatibility? Another analogy would be to have sunset the old
>>> P2PKH addresses during rollout of Segwit - it would certainly have led to
>>> Segwit getting rolled out faster. The rbf change actually breaks more
>>> things than that, takes more effort to address than just implementing a new
>>> address format. Previously in the Bitcoin Core process we've chosen to keep
>>> backwards compatibility and only roll out opt-in changes with broad
>>> consensus over them, with the default behavior being to not roll out
>>> changes that are controversial. At which point it's time to back away from
>>> that - I honestly don't know. There is probably such a point, and we should
>>> maybe have some kind of discussion around that topic on a higher level,
>>> just as you phrased it, and I'll paraphrase:
>>> If a majority of bitcoin wallets and services continue using legacy
>>> patterns and features, preventing progress, at which point do we want to
>>> break compatibility with them?
>>>
>>> Best,
>>> Sergej
>>>
>>>
>>> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
>>>>> bitcoin-dev wrote:
>>>>> > > If someone's going to systematically exploit your store via this
>>>>> > > mechanism, it seems like they'd just find a single wallet with a
>>>>> good
>>>>> > > UX for opt-in RBF and lowballing fees, and go to town -- not
>>>>> something
>>>>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>>>>> > Sort of. But yes once this starts being abused systemically we will
>>>>> have to
>>>>> > do something else w RBF payments, such as crediting the amount in
>>>>> BTC to a
>>>>> > custodial account. But this option isn't available to your normal
>>>>> payment
>>>>> > processor type business.
>>>>>
>>>>> So, what I'm hearing is:
>>>>>
>>>>>  * lightning works great, but is still pretty small
>>>>>  * zeroconf works great for txs that opt-out of RBF
>>>>>  * opt-in RBF is a pain for two reasons:
>>>>>     - people don't like that it's not treated as zeroconf
>>>>>     - the risk of fiat/BTC exchange rate changes between
>>>>>       now and when the tx actually confirms is worrying
>>>>>       even if it hasn't caused real problems yet
>>>>>
>>>>> (Please correct me if that's too far wrong)
>>>>>
>>>>> Maybe it would be productive to explore this opt-in RBF part a bit
>>>>> more? ie, see if "we" can come up with better answers to some question
>>>>> along the lines of:
>>>>>
>>>>>  "how can we make on-chain payments for goods priced in fiat work well
>>>>>   for payees that opt-in to RBF?"
>>>>>
>>>>> That seems like the sort of thing that's better solved by a
>>>>> collaboration
>>>>> between wallet devs and merchant devs (and protocol devs?), rather than
>>>>> just one or the other?
>>>>>
>>>>> Is that something that we could talk about here? Or maybe it's better
>>>>> done via an optech workgroup or something?
>>>>>
>>>>> If "we'll credit your account in BTC, then work out the USD coversion
>>>>> and deduct that for your purchase, then you can do whatever you like
>>>>> with any remaining BTC from your on-chain payment" is the idea, maybe
>>>>> we
>>>>> should just roll with that design, but make it more decentralised: have
>>>>> the initial payment setup a lightning channel between the customer and
>>>>> the merchant with the BTC (so it's not custodial), but do some magic to
>>>>> allow USD amounts to be transferred over it (Taro? something oracle
>>>>> based
>>>>> so that both parties are confident a fair exchange rate will be used?).
>>>>>
>>>>> Maybe that particular idea is naive, but having an actual problem to
>>>>> solve seems more constructive than just saying "we want rbf" "but we
>>>>> want zeroconf" all the time?
>>>>>
>>>>> (Ideally the lightning channels above would be dual funded so they
>>>>> could
>>>>> be used for routing more generally; but then dual funded channels are
>>>>> one of the things that get broken by lack of full rbf)
>>>>>
>>>>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
>>>>> create
>>>>> > > two conflicting txs in advance, one paying the merchant, one paying
>>>>> > > yourself, connect to many peers, relay the one paying the merchant
>>>>> to
>>>>> > > the merchant, and the other to everyone else.
>>>>> > > I'm just basing this off Peter Todd's stuff from years ago:
>>>>> > >
>>>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>>>> > >
>>>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>>>> > Yeah, I know the list still rehashes a single incident from 10 years
>>>>> ago to
>>>>> > declare the entire practice as unsafe, and ignores real-world data
>>>>> that of
>>>>> > the last million transactions we had zero cases of this successfully
>>>>> > abusing us.
>>>>>
>>>>> I mean, the avenue above isn't easy to exploit -- you have to identify
>>>>> the merchant's node so that they get the bad tx, and you have to
>>>>> connect
>>>>> to many peers so that your preferred tx propogates to miners first --
>>>>> and probably more importantly, it's relatively easy to detect -- if the
>>>>> merchant has a few passive nodes that the attacker doesn't know about
>>>>> it, and uses those to watch for attempted doublespends while it tries
>>>>> to ensure the real tx has propogated widely. So it doesn't surprise me
>>>>> at all that it's not often attempted, and even less often successful.
>>>>>
>>>>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
>>>>> > > > payments.
>>>>> > > So, based on last year's numbers, presumably that makes your
>>>>> bitcoin
>>>>> > > payments break down as something like:
>>>>> > >    5% txs are on-chain and seem shady and are excluded from
>>>>> zeroconf
>>>>> > >   15% txs are lightning
>>>>> > >   20% txs are on-chain but signal rbf and are excluded from
>>>>> zeroconf
>>>>> > >   60% txs are on-chain and seem fine for zeroconf
>>>>> > Numbers are right. Shady is too strong a word,
>>>>>
>>>>> Heh, fair enough.
>>>>>
>>>>> So the above suggests 25% of payments already get a sub-par experience,
>>>>> compared to what you'd like them to have (which sucks, but if you're
>>>>> trying to reinvent both money and payments, maybe isn't surprising).
>>>>> And
>>>>> going full rbf would bump that from 25% to 85%, which would be pretty
>>>>> terrible.
>>>>>
>>>>> > RBF is a strictly worse UX as proven by anyone
>>>>> > accepting bitcoin payments at scale.
>>>>>
>>>>> So let's make it better? Building bitcoin businesses on the lie that
>>>>> unconfirmed txs are safe and won't be replaced is going to bite us
>>>>> eventually; focussing on trying to push that back indefinitely is just
>>>>> going to make everyone less prepared when it eventually happens.
>>>>>
>>>>> > > > For me
>>>>> > > > personally it would be an easier discussion to have when
>>>>> Lightning is at
>>>>> > > > 80%+ of all bitcoin transactions.
>>>>> > > Can you extrapolate from the numbers you've seen to estimate when
>>>>> that
>>>>> > > might be, given current trends?
>>>>> > Not sure, it might be exponential growth, and the next 60% of
>>>>> Lightning
>>>>> > growth happen faster than the first 15%. Hard to tell. But we're
>>>>> likely
>>>>> > talking years here..
>>>>>
>>>>> Okay? Two years is very different from 50 years, and at the moment
>>>>> there's
>>>>> not really any data, so people are just going to go with their gut...
>>>>>
>>>>> If it were growing in line with lightning capacity in BTC, per
>>>>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>>>>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>>>>> getting from 15% to 80% would then be about 8 years.
>>>>>
>>>>> Presumably that's a laughably terrible model, of course. But if we had
>>>>> some actual numbers where we can watch the progress, it might be a lot
>>>>> easier to be patient about waiting for lightning adoption to hit 80%
>>>>> or whatever, and focus on productive things in the meantime?
>>>>>
>>>>> Cheers,
>>>>> aj
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill> | Blog
>>> <https://www.bitrefill.com/blog/> | Angellist
>>> <https://angel.co/bitrefill>
>>>
>>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
>

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

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

[Sergej Kotliar]

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

On Fri, 21 Oct 2022 at 16:01, Greg Sanders <gsanders87@gmail.com> wrote:

> Full-rbf is an odd duck, because while it is not a consensus issue, it
> does affect a large % of transactions made by wallets already, contrary to
> most policy changes.
>

Yeah, there are several policy features that are not consensus related but
end up de facto setting rules for how bitcoin behaves. Minrelayfee being
another, and probably other examples out there that I don't know of.


> It's also a UX issue, not a safety issue for retail wallet users(except
> Muun, who have given a clear timeline). Clearly considerations would be
> very different otherwise, but retail wallets by and large do not consider
> 0-conf as a valid deposit, or at least put up some warning symbols to that
> effect.
>
> Can only speak for myself, but I am looking for a concrete timeframe from
> 0-conf stakeholders. I have no preference for any particular time frame, as
> long as it can be agreed upon in the near-ish future. This keeps the
> transition technically speaking very simple, and removes uncertainty from
> decision making going forward.
>

It's hard to give a timeframe because it's not clear what the path forward
for these stakeholders is. Most of what I've heard in this channel is
things like "just use Lightning" but that's contradicted by user data. So
the action becomes "stop accepting payments onchain" which isn't really a
timeframe type issue, it will hurt whenever it happens. Maybe a thorough
discussion for a way forward would be useful here. Jeremy Rubin suggested
an interesting idea for using CPFP to force a transaction to complete.
We'll evaluate it and see if it works in the wild for zero-conf of RBF
today and report findings, need to evaluate from several angles first
incentives-wise. There might also be other solutions.

I'd also ask if there might also be other solutions for solving the pinning
issue as well if we dig deep into it? Perhaps there are those with
tradeoffs, but those tradeoffs being less significant than the tradeoffs of
rbf policy?


Best,
Sergej

>
> On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej@bitrefill.com>
> wrote:
>
>> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail.com> wrote:
>>
>>> A large number of coins/users sit on custodial rails and this would
>>> essentially encumber protocol developers to those KYC/AML institutions. If
>>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
>>> should this be an issue at all for reasoning about a path forward?
>>>
>>
>> This is a big question here, with the caveat that it's not just binance
>> but in fact the majority of wallets and services that people use with
>> bitcoin today.
>> But the question remains as you phrased: At which point do we break
>> backwards compatibility? Another analogy would be to have sunset the old
>> P2PKH addresses during rollout of Segwit - it would certainly have led to
>> Segwit getting rolled out faster. The rbf change actually breaks more
>> things than that, takes more effort to address than just implementing a new
>> address format. Previously in the Bitcoin Core process we've chosen to keep
>> backwards compatibility and only roll out opt-in changes with broad
>> consensus over them, with the default behavior being to not roll out
>> changes that are controversial. At which point it's time to back away from
>> that - I honestly don't know. There is probably such a point, and we should
>> maybe have some kind of discussion around that topic on a higher level,
>> just as you phrased it, and I'll paraphrase:
>> If a majority of bitcoin wallets and services continue using legacy
>> patterns and features, preventing progress, at which point do we want to
>> break compatibility with them?
>>
>> Best,
>> Sergej
>>
>>
>> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
>>>> bitcoin-dev wrote:
>>>> > > If someone's going to systematically exploit your store via this
>>>> > > mechanism, it seems like they'd just find a single wallet with a
>>>> good
>>>> > > UX for opt-in RBF and lowballing fees, and go to town -- not
>>>> something
>>>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>>>> > Sort of. But yes once this starts being abused systemically we will
>>>> have to
>>>> > do something else w RBF payments, such as crediting the amount in BTC
>>>> to a
>>>> > custodial account. But this option isn't available to your normal
>>>> payment
>>>> > processor type business.
>>>>
>>>> So, what I'm hearing is:
>>>>
>>>>  * lightning works great, but is still pretty small
>>>>  * zeroconf works great for txs that opt-out of RBF
>>>>  * opt-in RBF is a pain for two reasons:
>>>>     - people don't like that it's not treated as zeroconf
>>>>     - the risk of fiat/BTC exchange rate changes between
>>>>       now and when the tx actually confirms is worrying
>>>>       even if it hasn't caused real problems yet
>>>>
>>>> (Please correct me if that's too far wrong)
>>>>
>>>> Maybe it would be productive to explore this opt-in RBF part a bit
>>>> more? ie, see if "we" can come up with better answers to some question
>>>> along the lines of:
>>>>
>>>>  "how can we make on-chain payments for goods priced in fiat work well
>>>>   for payees that opt-in to RBF?"
>>>>
>>>> That seems like the sort of thing that's better solved by a
>>>> collaboration
>>>> between wallet devs and merchant devs (and protocol devs?), rather than
>>>> just one or the other?
>>>>
>>>> Is that something that we could talk about here? Or maybe it's better
>>>> done via an optech workgroup or something?
>>>>
>>>> If "we'll credit your account in BTC, then work out the USD coversion
>>>> and deduct that for your purchase, then you can do whatever you like
>>>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>>>> should just roll with that design, but make it more decentralised: have
>>>> the initial payment setup a lightning channel between the customer and
>>>> the merchant with the BTC (so it's not custodial), but do some magic to
>>>> allow USD amounts to be transferred over it (Taro? something oracle
>>>> based
>>>> so that both parties are confident a fair exchange rate will be used?).
>>>>
>>>> Maybe that particular idea is naive, but having an actual problem to
>>>> solve seems more constructive than just saying "we want rbf" "but we
>>>> want zeroconf" all the time?
>>>>
>>>> (Ideally the lightning channels above would be dual funded so they could
>>>> be used for routing more generally; but then dual funded channels are
>>>> one of the things that get broken by lack of full rbf)
>>>>
>>>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
>>>> create
>>>> > > two conflicting txs in advance, one paying the merchant, one paying
>>>> > > yourself, connect to many peers, relay the one paying the merchant
>>>> to
>>>> > > the merchant, and the other to everyone else.
>>>> > > I'm just basing this off Peter Todd's stuff from years ago:
>>>> > >
>>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>>> > >
>>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>>> > Yeah, I know the list still rehashes a single incident from 10 years
>>>> ago to
>>>> > declare the entire practice as unsafe, and ignores real-world data
>>>> that of
>>>> > the last million transactions we had zero cases of this successfully
>>>> > abusing us.
>>>>
>>>> I mean, the avenue above isn't easy to exploit -- you have to identify
>>>> the merchant's node so that they get the bad tx, and you have to connect
>>>> to many peers so that your preferred tx propogates to miners first --
>>>> and probably more importantly, it's relatively easy to detect -- if the
>>>> merchant has a few passive nodes that the attacker doesn't know about
>>>> it, and uses those to watch for attempted doublespends while it tries
>>>> to ensure the real tx has propogated widely. So it doesn't surprise me
>>>> at all that it's not often attempted, and even less often successful.
>>>>
>>>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
>>>> > > > payments.
>>>> > > So, based on last year's numbers, presumably that makes your bitcoin
>>>> > > payments break down as something like:
>>>> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
>>>> > >   15% txs are lightning
>>>> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>>> > >   60% txs are on-chain and seem fine for zeroconf
>>>> > Numbers are right. Shady is too strong a word,
>>>>
>>>> Heh, fair enough.
>>>>
>>>> So the above suggests 25% of payments already get a sub-par experience,
>>>> compared to what you'd like them to have (which sucks, but if you're
>>>> trying to reinvent both money and payments, maybe isn't surprising). And
>>>> going full rbf would bump that from 25% to 85%, which would be pretty
>>>> terrible.
>>>>
>>>> > RBF is a strictly worse UX as proven by anyone
>>>> > accepting bitcoin payments at scale.
>>>>
>>>> So let's make it better? Building bitcoin businesses on the lie that
>>>> unconfirmed txs are safe and won't be replaced is going to bite us
>>>> eventually; focussing on trying to push that back indefinitely is just
>>>> going to make everyone less prepared when it eventually happens.
>>>>
>>>> > > > For me
>>>> > > > personally it would be an easier discussion to have when
>>>> Lightning is at
>>>> > > > 80%+ of all bitcoin transactions.
>>>> > > Can you extrapolate from the numbers you've seen to estimate when
>>>> that
>>>> > > might be, given current trends?
>>>> > Not sure, it might be exponential growth, and the next 60% of
>>>> Lightning
>>>> > growth happen faster than the first 15%. Hard to tell. But we're
>>>> likely
>>>> > talking years here..
>>>>
>>>> Okay? Two years is very different from 50 years, and at the moment
>>>> there's
>>>> not really any data, so people are just going to go with their gut...
>>>>
>>>> If it were growing in line with lightning capacity in BTC, per
>>>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>>>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>>>> getting from 15% to 80% would then be about 8 years.
>>>>
>>>> Presumably that's a laughably terrible model, of course. But if we had
>>>> some actual numbers where we can watch the progress, it might be a lot
>>>> easier to be patient about waiting for lightning adoption to hit 80%
>>>> or whatever, and focus on productive things in the meantime?
>>>>
>>>> Cheers,
>>>> aj
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>>
>

-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Greg Sanders]

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

Full-rbf is an odd duck, because while it is not a consensus issue, it does
affect a large % of transactions made by wallets already, contrary to most
policy changes. We have a status quo that is understandable, but
unfortunately long-term incentive incompatible.

It's also a UX issue, not a safety issue for retail wallet users(except
Muun, who have given a clear timeline). Clearly considerations would be
very different otherwise, but retail wallets by and large do not consider
0-conf as a valid deposit, or at least put up some warning symbols to that
effect.

Can only speak for myself, but I am looking for a concrete timeframe from
0-conf stakeholders. I have no preference for any particular time frame, as
long as it can be agreed upon in the near-ish future. This keeps the
transition technically speaking very simple, and removes uncertainty from
decision making going forward.

To make a follow-on consensus analogy, I am in the BIP8
lock-on-timeout=true camp for full rbf. If metrics arise that shows we're
ready early, great. If not, I still want to avoid having this discussion
again in N+ years.

Cheers,
Greg

On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej@bitrefill.com> wrote:

> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail.com> wrote:
>
>> A large number of coins/users sit on custodial rails and this would
>> essentially encumber protocol developers to those KYC/AML institutions. If
>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
>> should this be an issue at all for reasoning about a path forward?
>>
>
> This is a big question here, with the caveat that it's not just binance
> but in fact the majority of wallets and services that people use with
> bitcoin today.
> But the question remains as you phrased: At which point do we break
> backwards compatibility? Another analogy would be to have sunset the old
> P2PKH addresses during rollout of Segwit - it would certainly have led to
> Segwit getting rolled out faster. The rbf change actually breaks more
> things than that, takes more effort to address than just implementing a new
> address format. Previously in the Bitcoin Core process we've chosen to keep
> backwards compatibility and only roll out opt-in changes with broad
> consensus over them, with the default behavior being to not roll out
> changes that are controversial. At which point it's time to back away from
> that - I honestly don't know. There is probably such a point, and we should
> maybe have some kind of discussion around that topic on a higher level,
> just as you phrased it, and I'll paraphrase:
> If a majority of bitcoin wallets and services continue using legacy
> patterns and features, preventing progress, at which point do we want to
> break compatibility with them?
>
> Best,
> Sergej
>
>
> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
>>> wrote:
>>> > > If someone's going to systematically exploit your store via this
>>> > > mechanism, it seems like they'd just find a single wallet with a good
>>> > > UX for opt-in RBF and lowballing fees, and go to town -- not
>>> something
>>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>>> > Sort of. But yes once this starts being abused systemically we will
>>> have to
>>> > do something else w RBF payments, such as crediting the amount in BTC
>>> to a
>>> > custodial account. But this option isn't available to your normal
>>> payment
>>> > processor type business.
>>>
>>> So, what I'm hearing is:
>>>
>>>  * lightning works great, but is still pretty small
>>>  * zeroconf works great for txs that opt-out of RBF
>>>  * opt-in RBF is a pain for two reasons:
>>>     - people don't like that it's not treated as zeroconf
>>>     - the risk of fiat/BTC exchange rate changes between
>>>       now and when the tx actually confirms is worrying
>>>       even if it hasn't caused real problems yet
>>>
>>> (Please correct me if that's too far wrong)
>>>
>>> Maybe it would be productive to explore this opt-in RBF part a bit
>>> more? ie, see if "we" can come up with better answers to some question
>>> along the lines of:
>>>
>>>  "how can we make on-chain payments for goods priced in fiat work well
>>>   for payees that opt-in to RBF?"
>>>
>>> That seems like the sort of thing that's better solved by a collaboration
>>> between wallet devs and merchant devs (and protocol devs?), rather than
>>> just one or the other?
>>>
>>> Is that something that we could talk about here? Or maybe it's better
>>> done via an optech workgroup or something?
>>>
>>> If "we'll credit your account in BTC, then work out the USD coversion
>>> and deduct that for your purchase, then you can do whatever you like
>>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>>> should just roll with that design, but make it more decentralised: have
>>> the initial payment setup a lightning channel between the customer and
>>> the merchant with the BTC (so it's not custodial), but do some magic to
>>> allow USD amounts to be transferred over it (Taro? something oracle based
>>> so that both parties are confident a fair exchange rate will be used?).
>>>
>>> Maybe that particular idea is naive, but having an actual problem to
>>> solve seems more constructive than just saying "we want rbf" "but we
>>> want zeroconf" all the time?
>>>
>>> (Ideally the lightning channels above would be dual funded so they could
>>> be used for routing more generally; but then dual funded channels are
>>> one of the things that get broken by lack of full rbf)
>>>
>>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
>>> create
>>> > > two conflicting txs in advance, one paying the merchant, one paying
>>> > > yourself, connect to many peers, relay the one paying the merchant to
>>> > > the merchant, and the other to everyone else.
>>> > > I'm just basing this off Peter Todd's stuff from years ago:
>>> > >
>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>> > >
>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>> > Yeah, I know the list still rehashes a single incident from 10 years
>>> ago to
>>> > declare the entire practice as unsafe, and ignores real-world data
>>> that of
>>> > the last million transactions we had zero cases of this successfully
>>> > abusing us.
>>>
>>> I mean, the avenue above isn't easy to exploit -- you have to identify
>>> the merchant's node so that they get the bad tx, and you have to connect
>>> to many peers so that your preferred tx propogates to miners first --
>>> and probably more importantly, it's relatively easy to detect -- if the
>>> merchant has a few passive nodes that the attacker doesn't know about
>>> it, and uses those to watch for attempted doublespends while it tries
>>> to ensure the real tx has propogated widely. So it doesn't surprise me
>>> at all that it's not often attempted, and even less often successful.
>>>
>>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
>>> > > > payments.
>>> > > So, based on last year's numbers, presumably that makes your bitcoin
>>> > > payments break down as something like:
>>> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
>>> > >   15% txs are lightning
>>> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>> > >   60% txs are on-chain and seem fine for zeroconf
>>> > Numbers are right. Shady is too strong a word,
>>>
>>> Heh, fair enough.
>>>
>>> So the above suggests 25% of payments already get a sub-par experience,
>>> compared to what you'd like them to have (which sucks, but if you're
>>> trying to reinvent both money and payments, maybe isn't surprising). And
>>> going full rbf would bump that from 25% to 85%, which would be pretty
>>> terrible.
>>>
>>> > RBF is a strictly worse UX as proven by anyone
>>> > accepting bitcoin payments at scale.
>>>
>>> So let's make it better? Building bitcoin businesses on the lie that
>>> unconfirmed txs are safe and won't be replaced is going to bite us
>>> eventually; focussing on trying to push that back indefinitely is just
>>> going to make everyone less prepared when it eventually happens.
>>>
>>> > > > For me
>>> > > > personally it would be an easier discussion to have when Lightning
>>> is at
>>> > > > 80%+ of all bitcoin transactions.
>>> > > Can you extrapolate from the numbers you've seen to estimate when
>>> that
>>> > > might be, given current trends?
>>> > Not sure, it might be exponential growth, and the next 60% of Lightning
>>> > growth happen faster than the first 15%. Hard to tell. But we're likely
>>> > talking years here..
>>>
>>> Okay? Two years is very different from 50 years, and at the moment
>>> there's
>>> not really any data, so people are just going to go with their gut...
>>>
>>> If it were growing in line with lightning capacity in BTC, per
>>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>>> getting from 15% to 80% would then be about 8 years.
>>>
>>> Presumably that's a laughably terrible model, of course. But if we had
>>> some actual numbers where we can watch the progress, it might be a lot
>>> easier to be patient about waiting for lightning adoption to hit 80%
>>> or whatever, and focus on productive things in the meantime?
>>>
>>> Cheers,
>>> aj
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
>

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

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

[Sergej Kotliar]

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

On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail.com> wrote:

> A large number of coins/users sit on custodial rails and this would
> essentially encumber protocol developers to those KYC/AML institutions. If
> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
> should this be an issue at all for reasoning about a path forward?
>

This is a big question here, with the caveat that it's not just binance but
in fact the majority of wallets and services that people use with bitcoin
today.
But the question remains as you phrased: At which point do we break
backwards compatibility? Another analogy would be to have sunset the old
P2PKH addresses during rollout of Segwit - it would certainly have led to
Segwit getting rolled out faster. The rbf change actually breaks more
things than that, takes more effort to address than just implementing a new
address format. Previously in the Bitcoin Core process we've chosen to keep
backwards compatibility and only roll out opt-in changes with broad
consensus over them, with the default behavior being to not roll out
changes that are controversial. At which point it's time to back away from
that - I honestly don't know. There is probably such a point, and we should
maybe have some kind of discussion around that topic on a higher level,
just as you phrased it, and I'll paraphrase:
If a majority of bitcoin wallets and services continue using legacy
patterns and features, preventing progress, at which point do we want to
break compatibility with them?

Best,
Sergej


On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
>> wrote:
>> > > If someone's going to systematically exploit your store via this
>> > > mechanism, it seems like they'd just find a single wallet with a good
>> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>> > Sort of. But yes once this starts being abused systemically we will
>> have to
>> > do something else w RBF payments, such as crediting the amount in BTC
>> to a
>> > custodial account. But this option isn't available to your normal
>> payment
>> > processor type business.
>>
>> So, what I'm hearing is:
>>
>>  * lightning works great, but is still pretty small
>>  * zeroconf works great for txs that opt-out of RBF
>>  * opt-in RBF is a pain for two reasons:
>>     - people don't like that it's not treated as zeroconf
>>     - the risk of fiat/BTC exchange rate changes between
>>       now and when the tx actually confirms is worrying
>>       even if it hasn't caused real problems yet
>>
>> (Please correct me if that's too far wrong)
>>
>> Maybe it would be productive to explore this opt-in RBF part a bit
>> more? ie, see if "we" can come up with better answers to some question
>> along the lines of:
>>
>>  "how can we make on-chain payments for goods priced in fiat work well
>>   for payees that opt-in to RBF?"
>>
>> That seems like the sort of thing that's better solved by a collaboration
>> between wallet devs and merchant devs (and protocol devs?), rather than
>> just one or the other?
>>
>> Is that something that we could talk about here? Or maybe it's better
>> done via an optech workgroup or something?
>>
>> If "we'll credit your account in BTC, then work out the USD coversion
>> and deduct that for your purchase, then you can do whatever you like
>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>> should just roll with that design, but make it more decentralised: have
>> the initial payment setup a lightning channel between the customer and
>> the merchant with the BTC (so it's not custodial), but do some magic to
>> allow USD amounts to be transferred over it (Taro? something oracle based
>> so that both parties are confident a fair exchange rate will be used?).
>>
>> Maybe that particular idea is naive, but having an actual problem to
>> solve seems more constructive than just saying "we want rbf" "but we
>> want zeroconf" all the time?
>>
>> (Ideally the lightning channels above would be dual funded so they could
>> be used for routing more generally; but then dual funded channels are
>> one of the things that get broken by lack of full rbf)
>>
>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
>> create
>> > > two conflicting txs in advance, one paying the merchant, one paying
>> > > yourself, connect to many peers, relay the one paying the merchant to
>> > > the merchant, and the other to everyone else.
>> > > I'm just basing this off Peter Todd's stuff from years ago:
>> > >
>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>> > >
>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>> > Yeah, I know the list still rehashes a single incident from 10 years
>> ago to
>> > declare the entire practice as unsafe, and ignores real-world data that
>> of
>> > the last million transactions we had zero cases of this successfully
>> > abusing us.
>>
>> I mean, the avenue above isn't easy to exploit -- you have to identify
>> the merchant's node so that they get the bad tx, and you have to connect
>> to many peers so that your preferred tx propogates to miners first --
>> and probably more importantly, it's relatively easy to detect -- if the
>> merchant has a few passive nodes that the attacker doesn't know about
>> it, and uses those to watch for attempted doublespends while it tries
>> to ensure the real tx has propogated widely. So it doesn't surprise me
>> at all that it's not often attempted, and even less often successful.
>>
>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
>> > > > payments.
>> > > So, based on last year's numbers, presumably that makes your bitcoin
>> > > payments break down as something like:
>> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
>> > >   15% txs are lightning
>> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
>> > >   60% txs are on-chain and seem fine for zeroconf
>> > Numbers are right. Shady is too strong a word,
>>
>> Heh, fair enough.
>>
>> So the above suggests 25% of payments already get a sub-par experience,
>> compared to what you'd like them to have (which sucks, but if you're
>> trying to reinvent both money and payments, maybe isn't surprising). And
>> going full rbf would bump that from 25% to 85%, which would be pretty
>> terrible.
>>
>> > RBF is a strictly worse UX as proven by anyone
>> > accepting bitcoin payments at scale.
>>
>> So let's make it better? Building bitcoin businesses on the lie that
>> unconfirmed txs are safe and won't be replaced is going to bite us
>> eventually; focussing on trying to push that back indefinitely is just
>> going to make everyone less prepared when it eventually happens.
>>
>> > > > For me
>> > > > personally it would be an easier discussion to have when Lightning
>> is at
>> > > > 80%+ of all bitcoin transactions.
>> > > Can you extrapolate from the numbers you've seen to estimate when that
>> > > might be, given current trends?
>> > Not sure, it might be exponential growth, and the next 60% of Lightning
>> > growth happen faster than the first 15%. Hard to tell. But we're likely
>> > talking years here..
>>
>> Okay? Two years is very different from 50 years, and at the moment there's
>> not really any data, so people are just going to go with their gut...
>>
>> If it were growing in line with lightning capacity in BTC, per
>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>> getting from 15% to 80% would then be about 8 years.
>>
>> Presumably that's a laughably terrible model, of course. But if we had
>> some actual numbers where we can watch the progress, it might be a lot
>> easier to be patient about waiting for lightning adoption to hit 80%
>> or whatever, and focus on productive things in the meantime?
>>
>> Cheers,
>> aj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Sergej Kotliar]

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

On Thu, 20 Oct 2022 at 21:58, Anthony Towns <aj@erisian.com.au> wrote:

> So, what I'm hearing is:
>
>  * lightning works great, but is still pretty small
>  * zeroconf works great for txs that opt-out of RBF
>  * opt-in RBF is a pain for two reasons:
>     - people don't like that it's not treated as zeroconf
>     - the risk of fiat/BTC exchange rate changes between
>       now and when the tx actually confirms is worrying
>       even if it hasn't caused real problems yet
>
> This is about right yes


> Maybe it would be productive to explore this opt-in RBF part a bit
> more? ie, see if "we" can come up with better answers to some question
> along the lines of:
>
>  "how can we make on-chain payments for goods priced in fiat work well
>   for payees that opt-in to RBF?"
>
> That seems like the sort of thing that's better solved by a collaboration
> between wallet devs and merchant devs (and protocol devs?), rather than
> just one or the other?
>
> Is that something that we could talk about here? Or maybe it's better
> done via an optech workgroup or something?
>

Agreed, more work is needed in the regard and we're happy to participate in
any efforts to make things better. It's not like we _want_ to be against
the core dev roadmap :)


> If "we'll credit your account in BTC, then work out the USD coversion
> and deduct that for your purchase, then you can do whatever you like
> with any remaining BTC from your on-chain payment" is the idea, maybe we
> should just roll with that design, but make it more decentralised: have
> the initial payment setup a lightning channel between the customer and
> the merchant with the BTC (so it's not custodial), but do some magic to
> allow USD amounts to be transferred over it (Taro? something oracle based
> so that both parties are confident a fair exchange rate will be used?).
>
> Maybe that particular idea is naive, but having an actual problem to
> solve seems more constructive than just saying "we want rbf" "but we
> want zeroconf" all the time?
>

Don't think it would solve any of the issues even if the above could
technically work, which it can't, simply because wallets that can only do
dump onchain payments are unlikely to be able to implement a scheme like
this.


> > > > Currently Lightning is somewhere around 15% of our total bitcoin
> > > > payments.
> > > So, based on last year's numbers, presumably that makes your bitcoin
> > > payments break down as something like:
> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
> > >   15% txs are lightning
> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
> > >   60% txs are on-chain and seem fine for zeroconf
> > Numbers are right. Shady is too strong a word,
>
> Heh, fair enough.
>
> So the above suggests 25% of payments already get a sub-par experience,
> compared to what you'd like them to have (which sucks, but if you're
> trying to reinvent both money and payments, maybe isn't surprising). And
> going full rbf would bump that from 25% to 85%, which would be pretty
> terrible.
>
> > RBF is a strictly worse UX as proven by anyone
> > accepting bitcoin payments at scale.
>
> So let's make it better? Building bitcoin businesses on the lie that
> unconfirmed txs are safe and won't be replaced is going to bite us
> eventually; focussing on trying to push that back indefinitely is just
> going to make everyone less prepared when it eventually happens.
>

Sure. The question is if we "make it better" first or if we standardize on
that which works worse first.


> > > > For me
> > > > personally it would be an easier discussion to have when Lightning
> is at
> > > > 80%+ of all bitcoin transactions.
> > > Can you extrapolate from the numbers you've seen to estimate when that
> > > might be, given current trends?
> > Not sure, it might be exponential growth, and the next 60% of Lightning
> > growth happen faster than the first 15%. Hard to tell. But we're likely
> > talking years here..
>
> Okay? Two years is very different from 50 years, and at the moment there's
> not really any data, so people are just going to go with their gut...
>
> If it were growing in line with lightning capacity in BTC, per
> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
> getting from 15% to 80% would then be about 8 years.
>

This math doesn't work. Capacity is a bad metric for activity, something we
unfortunately imported from the ETH world's TVL. Liquid has the same number
of btc on it as Lightning, but we probably all know there are several
orders of magnitude of difference in terms of usage.

There is another type of linear math that can but done but it's
significantly more gloomy: Over the past 3 years the share of bitcoin
payments among services has dropped from ~90%+ to below 50%. These figures
are similar across Bitrefill, Living Room of Satoshi, CoinCards, Bitpay
which is all the sources I know that have published stats on this. If we
assume this trend continues at that pace we might be at a point where
payments on Bitcoin are irrelevant, especially onchain, and there isn't
much left to argue over. I don't think that's going to happen tho, this
math probably also doesn't work for the same reasons, and we will work hard
for it to not happen. Fundamentally the issue of legacy support for bitcoin
things remains, and the ossification that happened on bitcoin things around
the 2015 level of UX. Solving that issue has proven to be a very tricky
subject, that we spend lots of energy on, but yet without overwhelming
success.

Best,
Sergej


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Sergej Kotliar]

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

This is factually incorrect and not required for us to do what we do.

On Fri, 21 Oct 2022 at 00:13, Peter Todd <pete@petertodd.org> wrote:

> On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > > If someone's going to systematically exploit your store via this
> > > > mechanism, it seems like they'd just find a single wallet with a good
> > > > UX for opt-in RBF and lowballing fees, and go to town -- not
> something
> > > > where opt-in rbf vs fullrbf policies make any difference at all?
> > > Sort of. But yes once this starts being abused systemically we will
> have to
> > > do something else w RBF payments, such as crediting the amount in BTC
> to a
> > > custodial account. But this option isn't available to your normal
> payment
> > > processor type business.
> >
> > So, what I'm hearing is:
> >
> >  * lightning works great, but is still pretty small
> >  * zeroconf works great for txs that opt-out of RBF
>
> It's important to note that the businesses that say "zeroconf works great"
> for
> them, appear to be achieving that by sybil attacking the network to measure
> propagation. That's not sustainable nor decentralized, as only a small
> number
> of companies can do that without causing a lot of harm to Bitcoin by using
> up
> inbound slots. We've gone through this before with "zeroconf guarantee"
> services, and the end result is not good.
>
> It's in our interests to make sure those companies stop doing that, and no
> new
> companies start.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Antoine Riard]

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

> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these
and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could implement
more
> of the countermeasures as appropriate to the abuse that has happened in
the
> wild.

From reading one of your other mail, apparently 60% of Bitrefill payments
are non-rbfable on-chain transactions and as such fine for zeroconf. What
I'm wondering is, in case of a wide majority of the full-nodes supporting
full-rbf, if any incoming transaction traffic could be risk-managed
well-enough thanks to some additional countermeasures to be
zeroconf-acceptable ?

We can be technically creative here. One could think of some overlay
monitoring between zeroconf merchants, where mempooldiffs are exchanged to
observe if any acceptance candidate is double-spent inside some other
participant's mempool. Of course, the reconciliation rate would need to be
pretty high to still ensure an "instant payment" UX, though the bandwidth
overhead should be okay as we assume full-node enterprise hosts. I don't
think such functionality would be used by any full-node, it might leverage
p2p extensions but it would be some differentiated services on top of the
usual messages. This is just an idea, and the concrete 0conf acceptance
flow problem needs to be better specified.

> Fundamentally, my view is that all the UX problems related to RBF alone
are
> sufficient of an issue to hold off on rolling out these upgrades for the
> foreseeable future and think of other ways of solving the pinning issue
and
> other issues w the current policy. Might be that it's just a fundamental
> goal conflict that different people want different behavior but I remain
> optimistic for creative solutions from both sides. UX issues are soft as
> opposed to theoretical attack vectors which are hard and binary, we need
> find a way to weigh "even though it doesn't happen it can theoretically be
> hacked" against "many users find it confusing and stressful" which is not
a
> trivial assessment to do.

Seriously, solving the pinning issues for contracting protocols already
busy few of the most brilliant bitcoin developers almost full-time. If we
had straightforward and backward compatible with all classes of current
Bitcoin applications, we would go for it. Of course, it doesn't mean we
should close the problem of space exploration, and if someone can come up
with solutions offering equivalent trade-offs, I'm all to listen. This is
still an open question if we would have to allow a subset of transactions
to be full-rbf, to fully achieve the semantics of v3 transactions, or at
least if we would like to protect currently open Lightning channels. Hard
problems here.

While I'm hearing the uncertainty of an easy assessment weighting between
favoring UX issues or solving hard theoretical attacks, those latter
concerns I've been serious enough among the Lightning development community
to take it as one of the top engineering issues among all those last years.
From my experience, pentesting in a "black-box" fashion of some subset of
LN vulnerabilities, they turn out as really practical after a few days of
hacking if you know where to hit. Moreover, it should be underscored that
the attacker incentive model between targeting a 0conf merchant like
Bitrefill and a sizable Lightning infrastructure is a bit different. On one
side, you will pocket free gift cards that are likely traceable to
real-world identities, or cancellable by calling out the issuers. On the
other side, you get a stack of free satoshis, easily fungible among all
other coins. As such, we might foresee far more exploitations against LN,
once the network has caught up in terms of volume and stakes to compare
with the most advanced Defi smart contract platforms in the wider
cryptocurrencies ecosystem, attracting today sophisticated attackers. Or at
least, I'm worried by such an outcome playing out for LN if we're too slow
on rolling out mitigations...

All that said, from my perspective upgrading mempool policy doesn't seem
incompatible with a parallel effort to improve the UX problems of RBF, by
automatic fee-bumping logic in a transparent way for the end-users. Like
you said, we should be all optimistic on creative solutions, and
communicate better between merchants and devs on the problem space.

Looking forward to having more interactions on these topics in the future!

Best,
Antoine

Le jeu. 20 oct. 2022 à 10:12, Sergej Kotliar <sergej@bitrefill.com> a
écrit :

>
>
> On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi Sergej,
>>
>> Thanks for the insightful posting, especially highlighting the FX risk
>> which was far from being evident on my side!
>>
>> I don't know in details the security architecture of Bitrefill zeroconf
>> acceptance system, though from what I suppose there is at least a set of
>> full-nodes well-connected across the p2p network, on top of which some
>> mempools reconciliation is exercised
>> and zeroconf candidate sanitize against. While I believe this is a
>> far-more robust deployment against double-spend attempts, there is still
>> the ability for a sophisticated attacker to "taint" miner mempools, and
>> from then partition judiciously the transaction-relay network to game such
>> distributed mempool monitoring system. There is also the possibility of an
>> attacker using some "divide-and-conquer" transaction broadcast algorithm to
>> map Bitrefill monitoring point, though as far as I'm aware such algorithm
>> has not been discussed. I agree with all of that, easier said than done.
>>
>
> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could implement more
> of the countermeasures as appropriate to the abuse that has happened in the
> wild.
>
>
>> On the efficacy of RBF, I understand the current approach of assuming
>> "manual" RBFing by power users ill UX thinking. I hope in the future to
>> have automatic fee-bumping implemented by user wallets, where a fee-bumping
>> budget and a confirmation preference are pre-defined for all payments, and
>> the fee-bumping logic "simply" enforcing the user policy, ideally based on
>> historical mempool data. True fact: we don't have such logic in consumer
>> wallets today.
>>
>
> In deed. And the vast majority of bitcoin users don't even have access to
> any RBF functionality today, so we're not even seeing gradual development
> of these things yet. I think this fact needs to be taken into account when
> designing breaking changes to bitcoin policy. Had these things been in
> place and widely used the conversation would have been much easier.
>
> Fundamentally, my view is that all the UX problems related to RBF alone
> are sufficient of an issue to hold off on rolling out these upgrades for
> the foreseeable future and think of other ways of solving the pinning issue
> and other issues w the current policy. Might be that it's just a
> fundamental goal conflict that different people want different behavior but
> I remain optimistic for creative solutions from both sides. UX issues are
> soft as opposed to theoretical attack vectors which are hard and binary, we
> need find a way to weigh "even though it doesn't happen it can
> theoretically be hacked" against "many users find it confusing and
> stressful" which is not a trivial assessment to do.
>
> All that said, I learn to converge that as a community we would be better
>> off to weigh deeper the risks/costs between 0confs applications and
>> contracting protocols in light of full-rbf.
>>
>
> In deed. And as you wrote in a different message, I agree that it's
> unfortunate that there isn't more interaction between the mailing list and
> services and companies using this stuff day-to-day. Not that it's anyone's
> fault in particular, let's try from all sides to find more ways to create
> more interaction on these topics. I've pinged a few colleagues that work on
> payments in the space and hope they will chime in more in this forum!
>
> All the best,
> Sergej
>
>
>> Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>>
>>> Hi all,
>>>
>>> Chiming in on this thread as I feel like the real dangers of RBF as
>>> default policy aren't sufficiently elaborated here. It's not only about the
>>> zero-conf (I'll get to that) but there is an even bigger danger called the
>>> american call option, which risks endangering the entirety of BIP21 "Scan
>>> this QR code with your wallet to buy this product" model that I believe
>>> we've all come to appreciate. Specifically, in a scenario with high
>>> volatility and many transactions in the mempools (which is where RBF would
>>> come in handy), a user can make a low-fee transaction and then wait for
>>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>>> up, user can cancel his transaction and make a new - cheaper one. The
>>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>>> (it's actually quite easily managed), it's FX risk as the merchant must
>>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>>> some transactions lose money to FX and others earn money - that evens out
>>> in the end. But if there is an _easily accessible in the wallet_ feature to
>>> "cancel transaction" that means it will eventually get systematically
>>> abused. A risk of X% loss on many payments that's easy to systematically
>>> abuse is more scary than a rare risk of losing 100% of one occasional
>>> payment. It's already possible to execute this form of abuse with opt-in
>>> RBF, which may lead to us at some point refusing those payments (even with
>>> confirmation) or cumbersome UX to work around it, such as crediting the
>>> bitcoin to a custodial account.
>>>
>>> To compare zeroconf risk with FX risk: I think we've had one incident in
>>> 8 years of operation where a user successfully fooled our server to accept
>>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>>> zeroconf one needs to have access to mining infrastructure and probability
>>> of success is the % of hash rate controlled. This is simply due to the fact
>>> that the network currently won't propagage the replacement transaction to
>>> the miner, which is what's being discussed here. American call option risk
>>> would however be available to 100% of all users, needs nothing beyond the
>>> wallet app, and has no cost to the user - only upside.
>>>
>>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>>> us, a world where bitcoin becomes de facto RBF by default, means that we
>>> would likely turn off the BIP21 model for onchain payments, instruct
>>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>>> account that we have.
>>> This option is however not available for your typical
>>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>>> from other merchants or payment providers how they see this new behavior
>>> and how they would counteract it.
>>>
>>> Currently Lightning is somewhere around 15% of our total bitcoin
>>> payments. This is very much not nothing, and all of us here want Lightning
>>> to grow, but I think it warrants a serious discussion on whether we want
>>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>>> For me personally it would be an easier discussion to have when Lightning
>>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>>> users simply don't have access to Lightning, and of those that do and hold
>>> their own keys Muun is the biggest wallet per our data, not least due to
>>> their ease-of-use which is under threat per the OP. It's hard to assess how
>>> many users would switch to Lightning in such a scenario, the communication
>>> around it would be hard. My intuition says that the majority of the current
>>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
>>> probably shift to an alt. The benefits of Lightning are many and obvious,
>>> we don't need to limit onchain to make Lightning more appealing. As an
>>> anecdote, we did experiment with defaulting to bech32 addresses some years
>>> back. The result was that simply users of the wallets that weren't able to
>>> pay to bech32 didn't complete the purchase, no support ticket or anything,
>>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
>>> implemented a wallet selector to allow modern wallets to pay to bech32
>>> while other wallets can pay to P2SH. This type of thing  is clunky, and
>>> requires a certain level of scale to be able to do, we certainly wouldn't
>>> have had the manpower for that when we were starting out. This why I'm
>>> cautious about introducing more such clunkiness vectors as they are
>>> centralizing factors.
>>>
>>> I'm well aware of the reason for this policy being suggested and the
>>> potential pinning attack vector for LN and other smart contracts, but I
>>> think these two risks/costs need to be weighed against eachother first and
>>> thoroughly discussed because the costs are non-trivial on both sides.
>>>
>>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>>> After interacting with users during high-fee periods I've come to not
>>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>>> don't have access to that functionality, because their wallet doesn't
>>> support it, or they use a custodial (exchange) wallet etc. Of those that
>>> have the feature - only the power users understand how RBF works, and
>>> explaining how to do RBF to a non-power-user is just too complex, for the
>>> same reason why it's complex for wallets to make sensible non-power-user UI
>>> around it. Current equilibrium is that mostly only power users have access
>>> to RBF and they know how to handle it, so things are somewhat working. But
>>> rolling this out to the broad market is something else and would likely
>>> cause more confusion.
>>> CPFP is somewhat more viable but also not perfect as it would require
>>> lots of edge case code to handle abuse vectors: What if users abuse a
>>> generous CPFP policy to unstuck past transactions or consolidate large
>>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>>> side, but there too are the same UX issues as with RBF.
>>> In the end a risk-based approach to decide on which payments are
>>> non-trivial to reverse is the easiest, taking account user experience and
>>> such. Remember that in the fiat world card payments have up to 5%
>>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>>> 1 in a million" accepted transactions successfully reversed. These days we
>>> have very few support issues related to bitcoin payments. The few that do
>>> come in are due to accidental RBF users venting frustration about waiting
>>> for their tx to confirm.
>>> "In theory, theory and practice are the same. In practice, they are not"
>>>
>>> All the best,
>>> Sergej Kotliar
>>> CEO Bitrefill.com
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill> | Blog
>>> <https://www.bitrefill.com/blog/> | Angellist
>>> <https://angel.co/bitrefill>
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill> | Blog
>>> <https://www.bitrefill.com/blog/> | Angellist
>>> <https://angel.co/bitrefill>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
>

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

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

[Peter Todd]

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

On Tue, Oct 18, 2022 at 05:00:45PM +1000, Anthony Towns via bitcoin-dev wrote:
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.

FWIW I'm not aware of any zeroconf accepting businesses where exploiting double
spends can be done without significant legal risk. Bitrefill has significant
legal risk, because pretty much everything you buy with Bitrefill can be traced
to your real world identity. ATMs have less risk. But I haven't seen an ATM
that accepts BTC without a confirmation in many years. Nor have I found a
non-KYC/AML in-person currency exchange service that would accept funds without a
confirmation (yes, I've had to wait 30 mins to get my cash before!). And all
the anonymous crypto-exchange websites like FixedFloat require a confirmation.

I have found AML/KYC in-person currency exchange services that would accept
zero conf. But of course, they had sufficient details on me to just call the
police if I double-spent them.

In practice, there are very few people who are actually affected by zeroconf
going away.

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

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

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

[Peter Todd]

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

On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev wrote:
> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> > > If someone's going to systematically exploit your store via this
> > > mechanism, it seems like they'd just find a single wallet with a good
> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
> > > where opt-in rbf vs fullrbf policies make any difference at all?
> > Sort of. But yes once this starts being abused systemically we will have to
> > do something else w RBF payments, such as crediting the amount in BTC to a
> > custodial account. But this option isn't available to your normal payment
> > processor type business.
> 
> So, what I'm hearing is:
> 
>  * lightning works great, but is still pretty small
>  * zeroconf works great for txs that opt-out of RBF

It's important to note that the businesses that say "zeroconf works great" for
them, appear to be achieving that by sybil attacking the network to measure
propagation. That's not sustainable nor decentralized, as only a small number
of companies can do that without causing a lot of harm to Bitcoin by using up
inbound slots. We've gone through this before with "zeroconf guarantee"
services, and the end result is not good.

It's in our interests to make sure those companies stop doing that, and no new
companies start.

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

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

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

[Peter Todd]

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

On Wed, Oct 19, 2022 at 03:17:51AM +0000, alicexbt via bitcoin-dev wrote:
> > And the
> > impression I got from the PR review club discussion more seemed like
> > devs making assumptions about businesses rather than having talked to
> > them (eg "[I] think there are fewer and fewer businesses who absolutely
> > cannot survive without relying on zeroconf. Or at least hope so").
> 
> Even I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks.

FYI I personally asked Max Hillebrand from Wasabi about full-rbf last night.
He gave me permission to republish our conversation:

    > Hey, I wanted to know if you had any comments on full-rbf re: wasabi?

    Doesn't really affect us, afaik
    The cj doesn't signal rbf right now
    And I guess it's a DoS vector if any input double spent will be relayed after successful signing
    But we have way bigger / cheaper DoS vectors that don't get "exploited"
    So probably doesn't matter
    Wasabi client handles replacements / reorgs gracefully, so should be alright
    We don't yet "use" rbf in the sense of fee bumping tx, but we should / will eventually

I haven't asked Joinmarket yet. But the impact on their implementation should
be very similar.

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

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

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

[Eloy]

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

There is obviously an alternative approach to the issue.

If we like opt-in RBF and would like to keep opt out RBF 0CONF working, we could add another option to punish those nodes that replace transactions. That is, a miner that publishes a block with a NO RBF, that is replaced (that is easy to check for a full node) could stop propagation of that block (so it have less chances to win). That would make the network decide when it is the time to deploy RBF.

It seems obvious for me that most devs prefer full RBF to force users to use centralized stuff (that is why the full RBF option is there already on core), but just wanted to make that clear that there is always a way to enforce a policy (read to keep zero conf working).

Regards.

El 20 de octubre de 2022 18:07:07 ART, Greg Sanders via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escribió:
>> If it were growing in line with lightning capacity in BTC, per
>bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>getting from 15% to 80% would then be about 8 years.
>
>I'd caution against any metrics-based approach like this, unless it's
>simply used for ballparking potential adoption curves to set a a timeframe
>people can live with.
>
>A large number of coins/users sit on custodial rails and this would
>essentially encumber protocol developers to those KYC/AML institutions. If
>Binance decides to never support Lightning in favor of BNC-wrapped BTC,
>should this be an issue at all for reasoning about a path forward?
>
>Hoping to be wrong,
>Greg
>
>
>
>On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
>> wrote:
>> > > If someone's going to systematically exploit your store via this
>> > > mechanism, it seems like they'd just find a single wallet with a good
>> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
>> > > where opt-in rbf vs fullrbf policies make any difference at all?
>> > Sort of. But yes once this starts being abused systemically we will have
>> to
>> > do something else w RBF payments, such as crediting the amount in BTC to
>> a
>> > custodial account. But this option isn't available to your normal payment
>> > processor type business.
>>
>> So, what I'm hearing is:
>>
>>  * lightning works great, but is still pretty small
>>  * zeroconf works great for txs that opt-out of RBF
>>  * opt-in RBF is a pain for two reasons:
>>     - people don't like that it's not treated as zeroconf
>>     - the risk of fiat/BTC exchange rate changes between
>>       now and when the tx actually confirms is worrying
>>       even if it hasn't caused real problems yet
>>
>> (Please correct me if that's too far wrong)
>>
>> Maybe it would be productive to explore this opt-in RBF part a bit
>> more? ie, see if "we" can come up with better answers to some question
>> along the lines of:
>>
>>  "how can we make on-chain payments for goods priced in fiat work well
>>   for payees that opt-in to RBF?"
>>
>> That seems like the sort of thing that's better solved by a collaboration
>> between wallet devs and merchant devs (and protocol devs?), rather than
>> just one or the other?
>>
>> Is that something that we could talk about here? Or maybe it's better
>> done via an optech workgroup or something?
>>
>> If "we'll credit your account in BTC, then work out the USD coversion
>> and deduct that for your purchase, then you can do whatever you like
>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>> should just roll with that design, but make it more decentralised: have
>> the initial payment setup a lightning channel between the customer and
>> the merchant with the BTC (so it's not custodial), but do some magic to
>> allow USD amounts to be transferred over it (Taro? something oracle based
>> so that both parties are confident a fair exchange rate will be used?).
>>
>> Maybe that particular idea is naive, but having an actual problem to
>> solve seems more constructive than just saying "we want rbf" "but we
>> want zeroconf" all the time?
>>
>> (Ideally the lightning channels above would be dual funded so they could
>> be used for routing more generally; but then dual funded channels are
>> one of the things that get broken by lack of full rbf)
>>
>> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
>> create
>> > > two conflicting txs in advance, one paying the merchant, one paying
>> > > yourself, connect to many peers, relay the one paying the merchant to
>> > > the merchant, and the other to everyone else.
>> > > I'm just basing this off Peter Todd's stuff from years ago:
>> > >
>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>> > >
>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>> > Yeah, I know the list still rehashes a single incident from 10 years ago
>> to
>> > declare the entire practice as unsafe, and ignores real-world data that
>> of
>> > the last million transactions we had zero cases of this successfully
>> > abusing us.
>>
>> I mean, the avenue above isn't easy to exploit -- you have to identify
>> the merchant's node so that they get the bad tx, and you have to connect
>> to many peers so that your preferred tx propogates to miners first --
>> and probably more importantly, it's relatively easy to detect -- if the
>> merchant has a few passive nodes that the attacker doesn't know about
>> it, and uses those to watch for attempted doublespends while it tries
>> to ensure the real tx has propogated widely. So it doesn't surprise me
>> at all that it's not often attempted, and even less often successful.
>>
>> > > > Currently Lightning is somewhere around 15% of our total bitcoin
>> > > > payments.
>> > > So, based on last year's numbers, presumably that makes your bitcoin
>> > > payments break down as something like:
>> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
>> > >   15% txs are lightning
>> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
>> > >   60% txs are on-chain and seem fine for zeroconf
>> > Numbers are right. Shady is too strong a word,
>>
>> Heh, fair enough.
>>
>> So the above suggests 25% of payments already get a sub-par experience,
>> compared to what you'd like them to have (which sucks, but if you're
>> trying to reinvent both money and payments, maybe isn't surprising). And
>> going full rbf would bump that from 25% to 85%, which would be pretty
>> terrible.
>>
>> > RBF is a strictly worse UX as proven by anyone
>> > accepting bitcoin payments at scale.
>>
>> So let's make it better? Building bitcoin businesses on the lie that
>> unconfirmed txs are safe and won't be replaced is going to bite us
>> eventually; focussing on trying to push that back indefinitely is just
>> going to make everyone less prepared when it eventually happens.
>>
>> > > > For me
>> > > > personally it would be an easier discussion to have when Lightning
>> is at
>> > > > 80%+ of all bitcoin transactions.
>> > > Can you extrapolate from the numbers you've seen to estimate when that
>> > > might be, given current trends?
>> > Not sure, it might be exponential growth, and the next 60% of Lightning
>> > growth happen faster than the first 15%. Hard to tell. But we're likely
>> > talking years here..
>>
>> Okay? Two years is very different from 50 years, and at the moment there's
>> not really any data, so people are just going to go with their gut...
>>
>> If it were growing in line with lightning capacity in BTC, per
>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>> getting from 15% to 80% would then be about 8 years.
>>
>> Presumably that's a laughably terrible model, of course. But if we had
>> some actual numbers where we can watch the progress, it might be a lot
>> easier to be patient about waiting for lightning adoption to hit 80%
>> or whatever, and focus on productive things in the meantime?
>>
>> Cheers,
>> aj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

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

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

[Greg Sanders]

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

> If it were growing in line with lightning capacity in BTC, per
bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
getting from 15% to 80% would then be about 8 years.

I'd caution against any metrics-based approach like this, unless it's
simply used for ballparking potential adoption curves to set a a timeframe
people can live with.

A large number of coins/users sit on custodial rails and this would
essentially encumber protocol developers to those KYC/AML institutions. If
Binance decides to never support Lightning in favor of BNC-wrapped BTC,
should this be an issue at all for reasoning about a path forward?

Hoping to be wrong,
Greg



On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > If someone's going to systematically exploit your store via this
> > > mechanism, it seems like they'd just find a single wallet with a good
> > > UX for opt-in RBF and lowballing fees, and go to town -- not something
> > > where opt-in rbf vs fullrbf policies make any difference at all?
> > Sort of. But yes once this starts being abused systemically we will have
> to
> > do something else w RBF payments, such as crediting the amount in BTC to
> a
> > custodial account. But this option isn't available to your normal payment
> > processor type business.
>
> So, what I'm hearing is:
>
>  * lightning works great, but is still pretty small
>  * zeroconf works great for txs that opt-out of RBF
>  * opt-in RBF is a pain for two reasons:
>     - people don't like that it's not treated as zeroconf
>     - the risk of fiat/BTC exchange rate changes between
>       now and when the tx actually confirms is worrying
>       even if it hasn't caused real problems yet
>
> (Please correct me if that's too far wrong)
>
> Maybe it would be productive to explore this opt-in RBF part a bit
> more? ie, see if "we" can come up with better answers to some question
> along the lines of:
>
>  "how can we make on-chain payments for goods priced in fiat work well
>   for payees that opt-in to RBF?"
>
> That seems like the sort of thing that's better solved by a collaboration
> between wallet devs and merchant devs (and protocol devs?), rather than
> just one or the other?
>
> Is that something that we could talk about here? Or maybe it's better
> done via an optech workgroup or something?
>
> If "we'll credit your account in BTC, then work out the USD coversion
> and deduct that for your purchase, then you can do whatever you like
> with any remaining BTC from your on-chain payment" is the idea, maybe we
> should just roll with that design, but make it more decentralised: have
> the initial payment setup a lightning channel between the customer and
> the merchant with the BTC (so it's not custodial), but do some magic to
> allow USD amounts to be transferred over it (Taro? something oracle based
> so that both parties are confident a fair exchange rate will be used?).
>
> Maybe that particular idea is naive, but having an actual problem to
> solve seems more constructive than just saying "we want rbf" "but we
> want zeroconf" all the time?
>
> (Ideally the lightning channels above would be dual funded so they could
> be used for routing more generally; but then dual funded channels are
> one of the things that get broken by lack of full rbf)
>
> > > I thought the "normal" avenue for fooling non-RBF zeroconf was to
> create
> > > two conflicting txs in advance, one paying the merchant, one paying
> > > yourself, connect to many peers, relay the one paying the merchant to
> > > the merchant, and the other to everyone else.
> > > I'm just basing this off Peter Todd's stuff from years ago:
> > >
> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
> > >
> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
> > Yeah, I know the list still rehashes a single incident from 10 years ago
> to
> > declare the entire practice as unsafe, and ignores real-world data that
> of
> > the last million transactions we had zero cases of this successfully
> > abusing us.
>
> I mean, the avenue above isn't easy to exploit -- you have to identify
> the merchant's node so that they get the bad tx, and you have to connect
> to many peers so that your preferred tx propogates to miners first --
> and probably more importantly, it's relatively easy to detect -- if the
> merchant has a few passive nodes that the attacker doesn't know about
> it, and uses those to watch for attempted doublespends while it tries
> to ensure the real tx has propogated widely. So it doesn't surprise me
> at all that it's not often attempted, and even less often successful.
>
> > > > Currently Lightning is somewhere around 15% of our total bitcoin
> > > > payments.
> > > So, based on last year's numbers, presumably that makes your bitcoin
> > > payments break down as something like:
> > >    5% txs are on-chain and seem shady and are excluded from zeroconf
> > >   15% txs are lightning
> > >   20% txs are on-chain but signal rbf and are excluded from zeroconf
> > >   60% txs are on-chain and seem fine for zeroconf
> > Numbers are right. Shady is too strong a word,
>
> Heh, fair enough.
>
> So the above suggests 25% of payments already get a sub-par experience,
> compared to what you'd like them to have (which sucks, but if you're
> trying to reinvent both money and payments, maybe isn't surprising). And
> going full rbf would bump that from 25% to 85%, which would be pretty
> terrible.
>
> > RBF is a strictly worse UX as proven by anyone
> > accepting bitcoin payments at scale.
>
> So let's make it better? Building bitcoin businesses on the lie that
> unconfirmed txs are safe and won't be replaced is going to bite us
> eventually; focussing on trying to push that back indefinitely is just
> going to make everyone less prepared when it eventually happens.
>
> > > > For me
> > > > personally it would be an easier discussion to have when Lightning
> is at
> > > > 80%+ of all bitcoin transactions.
> > > Can you extrapolate from the numbers you've seen to estimate when that
> > > might be, given current trends?
> > Not sure, it might be exponential growth, and the next 60% of Lightning
> > growth happen faster than the first 15%. Hard to tell. But we're likely
> > talking years here..
>
> Okay? Two years is very different from 50 years, and at the moment there's
> not really any data, so people are just going to go with their gut...
>
> If it were growing in line with lightning capacity in BTC, per
> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
> getting from 15% to 80% would then be about 8 years.
>
> Presumably that's a laughably terrible model, of course. But if we had
> some actual numbers where we can watch the progress, it might be a lot
> easier to be patient about waiting for lightning adoption to hit 80%
> or whatever, and focus on productive things in the meantime?
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[David A. Harding]

On 2022-10-20 09:58, Anthony Towns via bitcoin-dev wrote:
> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via 
> bitcoin-dev wrote:
>> AJ previously wrote:
>> > presumably that makes your bitcoin
>> > payments break down as something like:
>> >    5% txs are on-chain and seem shady and are excluded from zeroconf
>> >   15% txs are lightning
>> >   20% txs are on-chain but signal rbf and are excluded from zeroconf
>> >   60% txs are on-chain and seem fine for zeroconf
>> Numbers are right. [...]
> 
> [...]
> 
> So the above suggests 25% of payments already get a sub-par experience 
> [...]
> going full rbf would bump that from 25% to 85%, which would be pretty
> terrible.

Is it worth considering incremental steps between opt-in only (BIP125) 
and replace anything full RBF?  For example, in addition to opt-in RBF 
rules, treat any transaction with a txid ending in `0x1` as replacable?  
I assume 1/16th (6.25%) of transactions would match that pattern (some 
of which already opt-in to RBF, so the net effect would be smaller).  
This would have the following advantages:

1. We could see if miners are willing to enable unsignaled RBF at all

2. We could gather more evidence on how the change affects zeroconf 
businesses and everyday users, hopefully without requiring they make 
immediate and huge changes

3. Any wallet authors that oppose unsignaled RBF can opt-out by grinding 
their txids, at least until full RBF is accomplished

4. We can increase the percentage of transactions subject to unsignaled 
RBF in later releases of Bitcoin Core, steadily moving the system 
towards full RBF without any sudden leaps (assuming nobody builds a 
successful relay and mining network with less restrictive replacement 
rules)

I don't think this directly helps solve the problems with non-replacable 
transactions suffered by contract protocols since any adversary can 
opt-out of this scheme by grinding their txid, but I do think there's an 
advantage in transitioning slowly when people are still depending on 
previous behaviors.

Thanks,

-Dave

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

[Anthony Towns]

On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> > If someone's going to systematically exploit your store via this
> > mechanism, it seems like they'd just find a single wallet with a good
> > UX for opt-in RBF and lowballing fees, and go to town -- not something
> > where opt-in rbf vs fullrbf policies make any difference at all?
> Sort of. But yes once this starts being abused systemically we will have to
> do something else w RBF payments, such as crediting the amount in BTC to a
> custodial account. But this option isn't available to your normal payment
> processor type business.

So, what I'm hearing is:

 * lightning works great, but is still pretty small
 * zeroconf works great for txs that opt-out of RBF
 * opt-in RBF is a pain for two reasons:
    - people don't like that it's not treated as zeroconf
    - the risk of fiat/BTC exchange rate changes between
      now and when the tx actually confirms is worrying
      even if it hasn't caused real problems yet

(Please correct me if that's too far wrong)

Maybe it would be productive to explore this opt-in RBF part a bit
more? ie, see if "we" can come up with better answers to some question
along the lines of:

 "how can we make on-chain payments for goods priced in fiat work well
  for payees that opt-in to RBF?"

That seems like the sort of thing that's better solved by a collaboration
between wallet devs and merchant devs (and protocol devs?), rather than
just one or the other?

Is that something that we could talk about here? Or maybe it's better
done via an optech workgroup or something?

If "we'll credit your account in BTC, then work out the USD coversion
and deduct that for your purchase, then you can do whatever you like
with any remaining BTC from your on-chain payment" is the idea, maybe we
should just roll with that design, but make it more decentralised: have
the initial payment setup a lightning channel between the customer and
the merchant with the BTC (so it's not custodial), but do some magic to
allow USD amounts to be transferred over it (Taro? something oracle based
so that both parties are confident a fair exchange rate will be used?).

Maybe that particular idea is naive, but having an actual problem to
solve seems more constructive than just saying "we want rbf" "but we
want zeroconf" all the time?

(Ideally the lightning channels above would be dual funded so they could
be used for routing more generally; but then dual funded channels are
one of the things that get broken by lack of full rbf)

> > I thought the "normal" avenue for fooling non-RBF zeroconf was to create
> > two conflicting txs in advance, one paying the merchant, one paying
> > yourself, connect to many peers, relay the one paying the merchant to
> > the merchant, and the other to everyone else.
> > I'm just basing this off Peter Todd's stuff from years ago:
> > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
> > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
> Yeah, I know the list still rehashes a single incident from 10 years ago to
> declare the entire practice as unsafe, and ignores real-world data that of
> the last million transactions we had zero cases of this successfully
> abusing us.

I mean, the avenue above isn't easy to exploit -- you have to identify
the merchant's node so that they get the bad tx, and you have to connect
to many peers so that your preferred tx propogates to miners first --
and probably more importantly, it's relatively easy to detect -- if the
merchant has a few passive nodes that the attacker doesn't know about
it, and uses those to watch for attempted doublespends while it tries
to ensure the real tx has propogated widely. So it doesn't surprise me
at all that it's not often attempted, and even less often successful.

> > > Currently Lightning is somewhere around 15% of our total bitcoin
> > > payments.
> > So, based on last year's numbers, presumably that makes your bitcoin
> > payments break down as something like:
> >    5% txs are on-chain and seem shady and are excluded from zeroconf
> >   15% txs are lightning
> >   20% txs are on-chain but signal rbf and are excluded from zeroconf
> >   60% txs are on-chain and seem fine for zeroconf
> Numbers are right. Shady is too strong a word,

Heh, fair enough.

So the above suggests 25% of payments already get a sub-par experience,
compared to what you'd like them to have (which sucks, but if you're
trying to reinvent both money and payments, maybe isn't surprising). And
going full rbf would bump that from 25% to 85%, which would be pretty
terrible.

> RBF is a strictly worse UX as proven by anyone
> accepting bitcoin payments at scale.

So let's make it better? Building bitcoin businesses on the lie that
unconfirmed txs are safe and won't be replaced is going to bite us
eventually; focussing on trying to push that back indefinitely is just
going to make everyone less prepared when it eventually happens.

> > > For me
> > > personally it would be an easier discussion to have when Lightning is at
> > > 80%+ of all bitcoin transactions.
> > Can you extrapolate from the numbers you've seen to estimate when that
> > might be, given current trends?
> Not sure, it might be exponential growth, and the next 60% of Lightning
> growth happen faster than the first 15%. Hard to tell. But we're likely
> talking years here..

Okay? Two years is very different from 50 years, and at the moment there's
not really any data, so people are just going to go with their gut...

If it were growing in line with lightning capacity in BTC, per
bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
getting from 15% to 80% would then be about 8 years. 

Presumably that's a laughably terrible model, of course. But if we had
some actual numbers where we can watch the progress, it might be a lot
easier to be patient about waiting for lightning adoption to hit 80%
or whatever, and focus on productive things in the meantime?

Cheers,
aj

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

[Sergej Kotliar]

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

It's a good idea in theory, the issue is that most wallets and services
bitcoin users use today to send bitcoin don't use solutions to that. So we
end up with "you need to use X wallet to buy stuff", which is equivalent to
"you need to use a Lightning wallet to buy stuff"

On Thu, 20 Oct 2022 at 16:14, Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi,
>
> There is a reasonable tradeoff one can make to get eventual settlement
> assurance prior to confirmation: lock up the funds with a counterparty in a
> 2-of-2 multisig with a timelock back to the owner. As long as the timelock
> has not expired and the recipients trust the counterparty not to sign
> double spends, transactions that are spent from this multisig can be
> considered instant. In cases where the counterparty and the recipient are
> the same person, this solution is trustless. Since merchant purchases tend
> to be low-value, the counterparty risk (facilitating double spends) seems
> acceptable. GreenAddress provided such a service in 2015 or so, but the
> idea got abandoned.
>
> Personally, I find this solution much more tenable than relying on
> spurious network assumptions about what will be propagated and mined.
>
> Best regards,
> Ruben
>
>
>
> On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> wrote:
>>
>>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
>>> wrote:
>>> > The
>>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>>> > (it's actually quite easily managed),
>>>
>>> You mean "it's quite easily managed, provided the transaction doesn't
>>> opt-in to rbf", right? At least, that's what I understood you saying last
>>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
>>> matter what other trustworthy signals you might see:
>>>
>>>   https://twitter.com/ziggamon/status/1435863691816275970
>>>
>>> (rbf txs seem to have increased from 22% then to 29% now)
>>>
>>
>> Yeah. Our share of RBF is a bit lower than that as many RBF transactions
>> are something other than consumer purchases, and most consumer purchases
>> can't do RBF
>>
>>
>>> > it's FX risk as the merchant must
>>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>>> > some transactions lose money to FX and others earn money - that evens
>>> out
>>> > in the end.
>>>
>>> > But if there is an _easily accessible in the wallet_ feature to
>>> > "cancel transaction" that means it will eventually get systematically
>>> > abused. A risk of X% loss on many payments that's easy to
>>> systematically
>>> > abuse is more scary than a rare risk of losing 100% of one occasional
>>> > payment. It's already possible to execute this form of abuse with
>>> opt-in
>>> > RBF,
>>>
>>> If someone's going to systematically exploit your store via this
>>> mechanism, it seems like they'd just find a single wallet with a good
>>> UX for opt-in RBF and lowballing fees, and go to town -- not something
>>> where opt-in rbf vs fullrbf policies make any difference at all?
>>>
>>
>> Sort of. But yes once this starts being abused systemically we will have
>> to do something else w RBF payments, such as crediting the amount in BTC to
>> a custodial account. But this option isn't available to your normal payment
>> processor type business.
>>
>> Also worth keeping in mind that sometimes "opportunity makes the thief".
>> Currently only power-user wallet have that feature and their market share
>> is relatively small, mainly electrum stands out. But if this is available
>> to all users everywhere then it will start being abused and we'll have to
>> then direct all payments to custodial account, or some other convoluted
>> solution.
>>
>>
>>> It's not like existing wallets that don't let you set RBF will suddenly
>>> get a good UX for replacing transactions just because they'd be relayed
>>> if they did, is it?
>>>
>>> > To successfully fool (non-RBF)
>>> > zeroconf one needs to have access to mining infrastructure and
>>> probability
>>> > of success is the % of hash rate controlled.
>>>
>>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
>>> two conflicting txs in advance, one paying the merchant, one paying
>>> yourself, connect to many peers, relay the one paying the merchant to
>>> the merchant, and the other to everyone else.
>>>
>>> I'm just basing this off Peter Todd's stuff from years ago:
>>>
>>>
>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>>
>>>
>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>>
>>>
>>
>> Yeah, I know the list still rehashes a single incident from 10 years ago
>> to declare the entire practice as unsafe, and ignores real-world data that
>> of the last million transactions we had zero cases of this successfully
>> abusing us.
>>
>>
>>> > Currently Lightning is somewhere around 15% of our total bitcoin
>>> payments.
>>>
>>> So, based on last year's numbers, presumably that makes your bitcoin
>>> payments break down as something like:
>>>
>>>    5% txs are on-chain and seem shady and are excluded from zeroconf
>>>   15% txs are lightning
>>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>>   60% txs are on-chain and seem fine for zeroconf
>>>
>>
>> Numbers are right. Shady is too strong a word, it's mostly transactions
>> with very low fee, or high purchase amount, or many dependent unconfirmed
>> transactions, stuff like that. In some cases we do a human assessment of
>> the support ticket and often just pass them through.
>>
>>
>>> > This is very much not nothing, and all of us here want Lightning to
>>> grow,
>>> > but I think it warrants a serious discussion on whether we want
>>> Lightning
>>> > adoption to go to 100% by means of disabling on-chain commerce.
>>>
>>> If the numbers above were accurate, this would just mean you'd go from
>>> 60%
>>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>>>
>>
>> Point is that RBF transactions are unsafe even when waiting for a
>> confirmation, which Peter Todd trivially proved in the reply next to this.
>> The reliable solution is to reject all RBF payments and direct those users
>> to custodial accounts. There are other variants to solve this with varying
>> degree of convolutedness. RBF is a strictly worse UX as proven by anyone
>> accepting bitcoin payments at scale.
>>
>>
>>> > For me
>>> > personally it would be an easier discussion to have when Lightning is
>>> at
>>> > 80%+ of all bitcoin transactions.
>>>
>>> Can you extrapolate from the numbers you've seen to estimate when that
>>> might be, given current trends?
>>>
>>
>> Not sure, it might be exponential growth, and the next 60% of Lightning
>> growth happen faster than the first 15%. Hard to tell. But we're likely
>> talking years here..
>>
>>
>>>
>>> > The benefits of Lightning are many and obvious,
>>> > we don't need to limit onchain to make Lightning more appealing.
>>>
>>> To be fair, I think making lightning (and coinjoins) work better is
>>> exactly what inspired this -- not as a "make on-chain worse so we look
>>> better in comparison", but as a "making lightning work well is a bunch
>>> of hard problems, here's the next thing we need in order to beat the
>>> next problem".
>>>
>>
>> In deed. The fact that the largest non-custodial Lightning wallet started
>> this thread should be an indicator that despite these intentions the
>> solution harms more than it fixes.
>> Transactions being evicted from mempool is solved by requiring a minimum
>> fee rate, which we do and now seems to have become a standard practice.
>> Theoretically we can imagine them being evicted anyway but now we're
>> several theoreticals deep again when discussing something that will cause
>> massive problems right away. In emergency situations CPFP and similar can
>> of course be done manually in special circumstances.
>>
>> Cheers
>> Sergej
>>
>>
>> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> wrote:
>>
>>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
>>> wrote:
>>> > The
>>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>>> > (it's actually quite easily managed),
>>>
>>> You mean "it's quite easily managed, provided the transaction doesn't
>>> opt-in to rbf", right? At least, that's what I understood you saying last
>>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
>>> matter what other trustworthy signals you might see:
>>>
>>>   https://twitter.com/ziggamon/status/1435863691816275970
>>>
>>> (rbf txs seem to have increased from 22% then to 29% now)
>>>
>>> > it's FX risk as the merchant must
>>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>>> > some transactions lose money to FX and others earn money - that evens
>>> out
>>> > in the end.
>>>
>>> > But if there is an _easily accessible in the wallet_ feature to
>>> > "cancel transaction" that means it will eventually get systematically
>>> > abused. A risk of X% loss on many payments that's easy to
>>> systematically
>>> > abuse is more scary than a rare risk of losing 100% of one occasional
>>> > payment. It's already possible to execute this form of abuse with
>>> opt-in
>>> > RBF,
>>>
>>> If someone's going to systematically exploit your store via this
>>> mechanism, it seems like they'd just find a single wallet with a good
>>> UX for opt-in RBF and lowballing fees, and go to town -- not something
>>> where opt-in rbf vs fullrbf policies make any difference at all?
>>>
>>> It's not like existing wallets that don't let you set RBF will suddenly
>>> get a good UX for replacing transactions just because they'd be relayed
>>> if they did, is it?
>>>
>>> > To successfully fool (non-RBF)
>>> > zeroconf one needs to have access to mining infrastructure and
>>> probability
>>> > of success is the % of hash rate controlled.
>>>
>>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
>>> two conflicting txs in advance, one paying the merchant, one paying
>>> yourself, connect to many peers, relay the one paying the merchant to
>>> the merchant, and the other to everyone else.
>>>
>>> I'm just basing this off Peter Todd's stuff from years ago:
>>>
>>>
>>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>>
>>>
>>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>>
>>> > Currently Lightning is somewhere around 15% of our total bitcoin
>>> payments.
>>>
>>> So, based on last year's numbers, presumably that makes your bitcoin
>>> payments break down as something like:
>>>
>>>    5% txs are on-chain and seem shady and are excluded from zeroconf
>>>   15% txs are lightning
>>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>>   60% txs are on-chain and seem fine for zeroconf
>>>
>>> > This is very much not nothing, and all of us here want Lightning to
>>> grow,
>>> > but I think it warrants a serious discussion on whether we want
>>> Lightning
>>> > adoption to go to 100% by means of disabling on-chain commerce.
>>>
>>> If the numbers above were accurate, this would just mean you'd go from
>>> 60%
>>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>>>
>>> > For me
>>> > personally it would be an easier discussion to have when Lightning is
>>> at
>>> > 80%+ of all bitcoin transactions.
>>>
>>> Can you extrapolate from the numbers you've seen to estimate when that
>>> might be, given current trends? Or perhaps when fine-for-zeroconf txs
>>> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
>>> work the same in a fullrbf world.
>>>
>>> > The benefits of Lightning are many and obvious,
>>> > we don't need to limit onchain to make Lightning more appealing.
>>>
>>> To be fair, I think making lightning (and coinjoins) work better is
>>> exactly what inspired this -- not as a "make on-chain worse so we look
>>> better in comparison", but as a "making lightning work well is a bunch
>>> of hard problems, here's the next thing we need in order to beat the
>>> next problem".
>>>
>>> > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>>> > After interacting with users during high-fee periods I've come to not
>>> > appreciate RBF as a solution to that issue. Most users (80% or so)
>>> simply
>>> > don't have access to that functionality, because their wallet doesn't
>>> > support it, or they use a custodial (exchange) wallet etc. Of those
>>> that
>>> > have the feature - only the power users understand how RBF works, and
>>> > explaining how to do RBF to a non-power-user is just too complex, for
>>> the
>>> > same reason why it's complex for wallets to make sensible
>>> non-power-user UI
>>> > around it. Current equilibrium is that mostly only power users have
>>> access
>>> > to RBF and they know how to handle it, so things are somewhat working.
>>> But
>>> > rolling this out to the broad market is something else and would likely
>>> > cause more confusion.
>>> > CPFP is somewhat more viable but also not perfect as it would require
>>> lots
>>> > of edge case code to handle abuse vectors: What if users abuse a
>>> generous
>>> > CPFP policy to unstuck past transactions or consolidate large wallets.
>>> Best
>>> > is for CPFP to be done on the wallet side, not the merchant side, but
>>> there
>>> > too are the same UX issues as with RBF.
>>>
>>> I think if you're ruling out both merchants and users being able to add
>>> fees to a tx to get it to confirm, then you're going to lose either way.
>>> Txs will either expire because they've been stuck for more than a week,
>>> and be vulnerable to replacement at that point anyway, or they'll be
>>> dropped from mempools because they've filled up and they were the lowest
>>> fee tx, and be vulnerable to replacement for that reason. In the expiry
>>> case, the merchant can rebroadcast the original transaction to keep it
>>> alive, perhaps with a good chance of beating an attacker to the punch,
>>> but in the full mempool case, you could only do that if you were also
>>> CPFPing it, which you already ruled out.
>>>
>>> Cheers,
>>> aj
>>>
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Ruben Somsen]

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

Hi,

There is a reasonable tradeoff one can make to get eventual settlement
assurance prior to confirmation: lock up the funds with a counterparty in a
2-of-2 multisig with a timelock back to the owner. As long as the timelock
has not expired and the recipients trust the counterparty not to sign
double spends, transactions that are spent from this multisig can be
considered instant. In cases where the counterparty and the recipient are
the same person, this solution is trustless. Since merchant purchases tend
to be low-value, the counterparty risk (facilitating double spends) seems
acceptable. GreenAddress provided such a service in 2015 or so, but the
idea got abandoned.

Personally, I find this solution much more tenable than relying on spurious
network assumptions about what will be propagated and mined.

Best regards,
Ruben



On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> wrote:
>
>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
>> wrote:
>> > The
>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> > (it's actually quite easily managed),
>>
>> You mean "it's quite easily managed, provided the transaction doesn't
>> opt-in to rbf", right? At least, that's what I understood you saying last
>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
>> matter what other trustworthy signals you might see:
>>
>>   https://twitter.com/ziggamon/status/1435863691816275970
>>
>> (rbf txs seem to have increased from 22% then to 29% now)
>>
>
> Yeah. Our share of RBF is a bit lower than that as many RBF transactions
> are something other than consumer purchases, and most consumer purchases
> can't do RBF
>
>
>> > it's FX risk as the merchant must
>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> > some transactions lose money to FX and others earn money - that evens
>> out
>> > in the end.
>>
>> > But if there is an _easily accessible in the wallet_ feature to
>> > "cancel transaction" that means it will eventually get systematically
>> > abused. A risk of X% loss on many payments that's easy to systematically
>> > abuse is more scary than a rare risk of losing 100% of one occasional
>> > payment. It's already possible to execute this form of abuse with opt-in
>> > RBF,
>>
>> If someone's going to systematically exploit your store via this
>> mechanism, it seems like they'd just find a single wallet with a good
>> UX for opt-in RBF and lowballing fees, and go to town -- not something
>> where opt-in rbf vs fullrbf policies make any difference at all?
>>
>
> Sort of. But yes once this starts being abused systemically we will have
> to do something else w RBF payments, such as crediting the amount in BTC to
> a custodial account. But this option isn't available to your normal payment
> processor type business.
>
> Also worth keeping in mind that sometimes "opportunity makes the thief".
> Currently only power-user wallet have that feature and their market share
> is relatively small, mainly electrum stands out. But if this is available
> to all users everywhere then it will start being abused and we'll have to
> then direct all payments to custodial account, or some other convoluted
> solution.
>
>
>> It's not like existing wallets that don't let you set RBF will suddenly
>> get a good UX for replacing transactions just because they'd be relayed
>> if they did, is it?
>>
>> > To successfully fool (non-RBF)
>> > zeroconf one needs to have access to mining infrastructure and
>> probability
>> > of success is the % of hash rate controlled.
>>
>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
>> two conflicting txs in advance, one paying the merchant, one paying
>> yourself, connect to many peers, relay the one paying the merchant to
>> the merchant, and the other to everyone else.
>>
>> I'm just basing this off Peter Todd's stuff from years ago:
>>
>>
>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>
>>
>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>
>>
>
> Yeah, I know the list still rehashes a single incident from 10 years ago
> to declare the entire practice as unsafe, and ignores real-world data that
> of the last million transactions we had zero cases of this successfully
> abusing us.
>
>
>> > Currently Lightning is somewhere around 15% of our total bitcoin
>> payments.
>>
>> So, based on last year's numbers, presumably that makes your bitcoin
>> payments break down as something like:
>>
>>    5% txs are on-chain and seem shady and are excluded from zeroconf
>>   15% txs are lightning
>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>   60% txs are on-chain and seem fine for zeroconf
>>
>
> Numbers are right. Shady is too strong a word, it's mostly transactions
> with very low fee, or high purchase amount, or many dependent unconfirmed
> transactions, stuff like that. In some cases we do a human assessment of
> the support ticket and often just pass them through.
>
>
>> > This is very much not nothing, and all of us here want Lightning to
>> grow,
>> > but I think it warrants a serious discussion on whether we want
>> Lightning
>> > adoption to go to 100% by means of disabling on-chain commerce.
>>
>> If the numbers above were accurate, this would just mean you'd go from 60%
>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>>
>
> Point is that RBF transactions are unsafe even when waiting for a
> confirmation, which Peter Todd trivially proved in the reply next to this.
> The reliable solution is to reject all RBF payments and direct those users
> to custodial accounts. There are other variants to solve this with varying
> degree of convolutedness. RBF is a strictly worse UX as proven by anyone
> accepting bitcoin payments at scale.
>
>
>> > For me
>> > personally it would be an easier discussion to have when Lightning is at
>> > 80%+ of all bitcoin transactions.
>>
>> Can you extrapolate from the numbers you've seen to estimate when that
>> might be, given current trends?
>>
>
> Not sure, it might be exponential growth, and the next 60% of Lightning
> growth happen faster than the first 15%. Hard to tell. But we're likely
> talking years here..
>
>
>>
>> > The benefits of Lightning are many and obvious,
>> > we don't need to limit onchain to make Lightning more appealing.
>>
>> To be fair, I think making lightning (and coinjoins) work better is
>> exactly what inspired this -- not as a "make on-chain worse so we look
>> better in comparison", but as a "making lightning work well is a bunch
>> of hard problems, here's the next thing we need in order to beat the
>> next problem".
>>
>
> In deed. The fact that the largest non-custodial Lightning wallet started
> this thread should be an indicator that despite these intentions the
> solution harms more than it fixes.
> Transactions being evicted from mempool is solved by requiring a minimum
> fee rate, which we do and now seems to have become a standard practice.
> Theoretically we can imagine them being evicted anyway but now we're
> several theoreticals deep again when discussing something that will cause
> massive problems right away. In emergency situations CPFP and similar can
> of course be done manually in special circumstances.
>
> Cheers
> Sergej
>
>
> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> wrote:
>
>> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
>> wrote:
>> > The
>> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> > (it's actually quite easily managed),
>>
>> You mean "it's quite easily managed, provided the transaction doesn't
>> opt-in to rbf", right? At least, that's what I understood you saying last
>> time; ie that if the tx signals rbf, then you just don't do zeroconf no
>> matter what other trustworthy signals you might see:
>>
>>   https://twitter.com/ziggamon/status/1435863691816275970
>>
>> (rbf txs seem to have increased from 22% then to 29% now)
>>
>> > it's FX risk as the merchant must
>> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> > some transactions lose money to FX and others earn money - that evens
>> out
>> > in the end.
>>
>> > But if there is an _easily accessible in the wallet_ feature to
>> > "cancel transaction" that means it will eventually get systematically
>> > abused. A risk of X% loss on many payments that's easy to systematically
>> > abuse is more scary than a rare risk of losing 100% of one occasional
>> > payment. It's already possible to execute this form of abuse with opt-in
>> > RBF,
>>
>> If someone's going to systematically exploit your store via this
>> mechanism, it seems like they'd just find a single wallet with a good
>> UX for opt-in RBF and lowballing fees, and go to town -- not something
>> where opt-in rbf vs fullrbf policies make any difference at all?
>>
>> It's not like existing wallets that don't let you set RBF will suddenly
>> get a good UX for replacing transactions just because they'd be relayed
>> if they did, is it?
>>
>> > To successfully fool (non-RBF)
>> > zeroconf one needs to have access to mining infrastructure and
>> probability
>> > of success is the % of hash rate controlled.
>>
>> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
>> two conflicting txs in advance, one paying the merchant, one paying
>> yourself, connect to many peers, relay the one paying the merchant to
>> the merchant, and the other to everyone else.
>>
>> I'm just basing this off Peter Todd's stuff from years ago:
>>
>>
>> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>>
>>
>> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>>
>> > Currently Lightning is somewhere around 15% of our total bitcoin
>> payments.
>>
>> So, based on last year's numbers, presumably that makes your bitcoin
>> payments break down as something like:
>>
>>    5% txs are on-chain and seem shady and are excluded from zeroconf
>>   15% txs are lightning
>>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>>   60% txs are on-chain and seem fine for zeroconf
>>
>> > This is very much not nothing, and all of us here want Lightning to
>> grow,
>> > but I think it warrants a serious discussion on whether we want
>> Lightning
>> > adoption to go to 100% by means of disabling on-chain commerce.
>>
>> If the numbers above were accurate, this would just mean you'd go from 60%
>> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>>
>> > For me
>> > personally it would be an easier discussion to have when Lightning is at
>> > 80%+ of all bitcoin transactions.
>>
>> Can you extrapolate from the numbers you've seen to estimate when that
>> might be, given current trends? Or perhaps when fine-for-zeroconf txs
>> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
>> work the same in a fullrbf world.
>>
>> > The benefits of Lightning are many and obvious,
>> > we don't need to limit onchain to make Lightning more appealing.
>>
>> To be fair, I think making lightning (and coinjoins) work better is
>> exactly what inspired this -- not as a "make on-chain worse so we look
>> better in comparison", but as a "making lightning work well is a bunch
>> of hard problems, here's the next thing we need in order to beat the
>> next problem".
>>
>> > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> > After interacting with users during high-fee periods I've come to not
>> > appreciate RBF as a solution to that issue. Most users (80% or so)
>> simply
>> > don't have access to that functionality, because their wallet doesn't
>> > support it, or they use a custodial (exchange) wallet etc. Of those that
>> > have the feature - only the power users understand how RBF works, and
>> > explaining how to do RBF to a non-power-user is just too complex, for
>> the
>> > same reason why it's complex for wallets to make sensible
>> non-power-user UI
>> > around it. Current equilibrium is that mostly only power users have
>> access
>> > to RBF and they know how to handle it, so things are somewhat working.
>> But
>> > rolling this out to the broad market is something else and would likely
>> > cause more confusion.
>> > CPFP is somewhat more viable but also not perfect as it would require
>> lots
>> > of edge case code to handle abuse vectors: What if users abuse a
>> generous
>> > CPFP policy to unstuck past transactions or consolidate large wallets.
>> Best
>> > is for CPFP to be done on the wallet side, not the merchant side, but
>> there
>> > too are the same UX issues as with RBF.
>>
>> I think if you're ruling out both merchants and users being able to add
>> fees to a tx to get it to confirm, then you're going to lose either way.
>> Txs will either expire because they've been stuck for more than a week,
>> and be vulnerable to replacement at that point anyway, or they'll be
>> dropped from mempools because they've filled up and they were the lowest
>> fee tx, and be vulnerable to replacement for that reason. In the expiry
>> case, the merchant can rebroadcast the original transaction to keep it
>> alive, perhaps with a good chance of beating an attacker to the punch,
>> but in the full mempool case, you could only do that if you were also
>> CPFPing it, which you already ruled out.
>>
>> Cheers,
>> aj
>>
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Sergej Kotliar]

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

On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard@gmail.com> wrote:

> Hi Sergej,
>
> Thanks for the insightful posting, especially highlighting the FX risk
> which was far from being evident on my side!
>
> I don't know in details the security architecture of Bitrefill zeroconf
> acceptance system, though from what I suppose there is at least a set of
> full-nodes well-connected across the p2p network, on top of which some
> mempools reconciliation is exercised
> and zeroconf candidate sanitize against. While I believe this is a
> far-more robust deployment against double-spend attempts, there is still
> the ability for a sophisticated attacker to "taint" miner mempools, and
> from then partition judiciously the transaction-relay network to game such
> distributed mempool monitoring system. There is also the possibility of an
> attacker using some "divide-and-conquer" transaction broadcast algorithm to
> map Bitrefill monitoring point, though as far as I'm aware such algorithm
> has not been discussed. I agree with all of that, easier said than done.
>

There is a long list of countermeasures that can be built to reduce these
attacks, but to be frank we've only implemented a small subset of these and
not had any issues, so even a lower level of security is more than fine
today to have basically zero abuse. If issues arise we could implement more
of the countermeasures as appropriate to the abuse that has happened in the
wild.


> On the efficacy of RBF, I understand the current approach of assuming
> "manual" RBFing by power users ill UX thinking. I hope in the future to
> have automatic fee-bumping implemented by user wallets, where a fee-bumping
> budget and a confirmation preference are pre-defined for all payments, and
> the fee-bumping logic "simply" enforcing the user policy, ideally based on
> historical mempool data. True fact: we don't have such logic in consumer
> wallets today.
>

In deed. And the vast majority of bitcoin users don't even have access to
any RBF functionality today, so we're not even seeing gradual development
of these things yet. I think this fact needs to be taken into account when
designing breaking changes to bitcoin policy. Had these things been in
place and widely used the conversation would have been much easier.

Fundamentally, my view is that all the UX problems related to RBF alone are
sufficient of an issue to hold off on rolling out these upgrades for the
foreseeable future and think of other ways of solving the pinning issue and
other issues w the current policy. Might be that it's just a fundamental
goal conflict that different people want different behavior but I remain
optimistic for creative solutions from both sides. UX issues are soft as
opposed to theoretical attack vectors which are hard and binary, we need
find a way to weigh "even though it doesn't happen it can theoretically be
hacked" against "many users find it confusing and stressful" which is not a
trivial assessment to do.

All that said, I learn to converge that as a community we would be better
> off to weigh deeper the risks/costs between 0confs applications and
> contracting protocols in light of full-rbf.
>

In deed. And as you wrote in a different message, I agree that it's
unfortunate that there isn't more interaction between the mailing list and
services and companies using this stuff day-to-day. Not that it's anyone's
fault in particular, let's try from all sides to find more ways to create
more interaction on these topics. I've pinged a few colleagues that work on
payments in the space and hope they will chime in more in this forum!

All the best,
Sergej


> Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hi all,
>>
>> Chiming in on this thread as I feel like the real dangers of RBF as
>> default policy aren't sufficiently elaborated here. It's not only about the
>> zero-conf (I'll get to that) but there is an even bigger danger called the
>> american call option, which risks endangering the entirety of BIP21 "Scan
>> this QR code with your wallet to buy this product" model that I believe
>> we've all come to appreciate. Specifically, in a scenario with high
>> volatility and many transactions in the mempools (which is where RBF would
>> come in handy), a user can make a low-fee transaction and then wait for
>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>> up, user can cancel his transaction and make a new - cheaper one. The
>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> (it's actually quite easily managed), it's FX risk as the merchant must
>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> some transactions lose money to FX and others earn money - that evens out
>> in the end. But if there is an _easily accessible in the wallet_ feature to
>> "cancel transaction" that means it will eventually get systematically
>> abused. A risk of X% loss on many payments that's easy to systematically
>> abuse is more scary than a rare risk of losing 100% of one occasional
>> payment. It's already possible to execute this form of abuse with opt-in
>> RBF, which may lead to us at some point refusing those payments (even with
>> confirmation) or cumbersome UX to work around it, such as crediting the
>> bitcoin to a custodial account.
>>
>> To compare zeroconf risk with FX risk: I think we've had one incident in
>> 8 years of operation where a user successfully fooled our server to accept
>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>> zeroconf one needs to have access to mining infrastructure and probability
>> of success is the % of hash rate controlled. This is simply due to the fact
>> that the network currently won't propagage the replacement transaction to
>> the miner, which is what's being discussed here. American call option risk
>> would however be available to 100% of all users, needs nothing beyond the
>> wallet app, and has no cost to the user - only upside.
>>
>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>> us, a world where bitcoin becomes de facto RBF by default, means that we
>> would likely turn off the BIP21 model for onchain payments, instruct
>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>> account that we have.
>> This option is however not available for your typical
>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>> from other merchants or payment providers how they see this new behavior
>> and how they would counteract it.
>>
>> Currently Lightning is somewhere around 15% of our total bitcoin
>> payments. This is very much not nothing, and all of us here want Lightning
>> to grow, but I think it warrants a serious discussion on whether we want
>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>> For me personally it would be an easier discussion to have when Lightning
>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>> users simply don't have access to Lightning, and of those that do and hold
>> their own keys Muun is the biggest wallet per our data, not least due to
>> their ease-of-use which is under threat per the OP. It's hard to assess how
>> many users would switch to Lightning in such a scenario, the communication
>> around it would be hard. My intuition says that the majority of the current
>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
>> probably shift to an alt. The benefits of Lightning are many and obvious,
>> we don't need to limit onchain to make Lightning more appealing. As an
>> anecdote, we did experiment with defaulting to bech32 addresses some years
>> back. The result was that simply users of the wallets that weren't able to
>> pay to bech32 didn't complete the purchase, no support ticket or anything,
>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
>> implemented a wallet selector to allow modern wallets to pay to bech32
>> while other wallets can pay to P2SH. This type of thing  is clunky, and
>> requires a certain level of scale to be able to do, we certainly wouldn't
>> have had the manpower for that when we were starting out. This why I'm
>> cautious about introducing more such clunkiness vectors as they are
>> centralizing factors.
>>
>> I'm well aware of the reason for this policy being suggested and the
>> potential pinning attack vector for LN and other smart contracts, but I
>> think these two risks/costs need to be weighed against eachother first and
>> thoroughly discussed because the costs are non-trivial on both sides.
>>
>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> After interacting with users during high-fee periods I've come to not
>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>> don't have access to that functionality, because their wallet doesn't
>> support it, or they use a custodial (exchange) wallet etc. Of those that
>> have the feature - only the power users understand how RBF works, and
>> explaining how to do RBF to a non-power-user is just too complex, for the
>> same reason why it's complex for wallets to make sensible non-power-user UI
>> around it. Current equilibrium is that mostly only power users have access
>> to RBF and they know how to handle it, so things are somewhat working. But
>> rolling this out to the broad market is something else and would likely
>> cause more confusion.
>> CPFP is somewhat more viable but also not perfect as it would require
>> lots of edge case code to handle abuse vectors: What if users abuse a
>> generous CPFP policy to unstuck past transactions or consolidate large
>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>> side, but there too are the same UX issues as with RBF.
>> In the end a risk-based approach to decide on which payments are
>> non-trivial to reverse is the easiest, taking account user experience and
>> such. Remember that in the fiat world card payments have up to 5%
>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>> 1 in a million" accepted transactions successfully reversed. These days we
>> have very few support issues related to bitcoin payments. The few that do
>> come in are due to accidental RBF users venting frustration about waiting
>> for their tx to confirm.
>> "In theory, theory and practice are the same. In practice, they are not"
>>
>> All the best,
>> Sergej Kotliar
>> CEO Bitrefill.com
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Sergej Kotliar]

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

On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> wrote:

> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > The
> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> > (it's actually quite easily managed),
>
> You mean "it's quite easily managed, provided the transaction doesn't
> opt-in to rbf", right? At least, that's what I understood you saying last
> time; ie that if the tx signals rbf, then you just don't do zeroconf no
> matter what other trustworthy signals you might see:
>
>   https://twitter.com/ziggamon/status/1435863691816275970
>
> (rbf txs seem to have increased from 22% then to 29% now)
>

Yeah. Our share of RBF is a bit lower than that as many RBF transactions
are something other than consumer purchases, and most consumer purchases
can't do RBF


> > it's FX risk as the merchant must
> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> > some transactions lose money to FX and others earn money - that evens out
> > in the end.
>
> > But if there is an _easily accessible in the wallet_ feature to
> > "cancel transaction" that means it will eventually get systematically
> > abused. A risk of X% loss on many payments that's easy to systematically
> > abuse is more scary than a rare risk of losing 100% of one occasional
> > payment. It's already possible to execute this form of abuse with opt-in
> > RBF,
>
> If someone's going to systematically exploit your store via this
> mechanism, it seems like they'd just find a single wallet with a good
> UX for opt-in RBF and lowballing fees, and go to town -- not something
> where opt-in rbf vs fullrbf policies make any difference at all?
>

Sort of. But yes once this starts being abused systemically we will have to
do something else w RBF payments, such as crediting the amount in BTC to a
custodial account. But this option isn't available to your normal payment
processor type business.

Also worth keeping in mind that sometimes "opportunity makes the thief".
Currently only power-user wallet have that feature and their market share
is relatively small, mainly electrum stands out. But if this is available
to all users everywhere then it will start being abused and we'll have to
then direct all payments to custodial account, or some other convoluted
solution.


> It's not like existing wallets that don't let you set RBF will suddenly
> get a good UX for replacing transactions just because they'd be relayed
> if they did, is it?
>
> > To successfully fool (non-RBF)
> > zeroconf one needs to have access to mining infrastructure and
> probability
> > of success is the % of hash rate controlled.
>
> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
> two conflicting txs in advance, one paying the merchant, one paying
> yourself, connect to many peers, relay the one paying the merchant to
> the merchant, and the other to everyone else.
>
> I'm just basing this off Peter Todd's stuff from years ago:
>
>
> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>
>
> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>
>

Yeah, I know the list still rehashes a single incident from 10 years ago to
declare the entire practice as unsafe, and ignores real-world data that of
the last million transactions we had zero cases of this successfully
abusing us.


> > Currently Lightning is somewhere around 15% of our total bitcoin
> payments.
>
> So, based on last year's numbers, presumably that makes your bitcoin
> payments break down as something like:
>
>    5% txs are on-chain and seem shady and are excluded from zeroconf
>   15% txs are lightning
>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>   60% txs are on-chain and seem fine for zeroconf
>

Numbers are right. Shady is too strong a word, it's mostly transactions
with very low fee, or high purchase amount, or many dependent unconfirmed
transactions, stuff like that. In some cases we do a human assessment of
the support ticket and often just pass them through.


> > This is very much not nothing, and all of us here want Lightning to grow,
> > but I think it warrants a serious discussion on whether we want Lightning
> > adoption to go to 100% by means of disabling on-chain commerce.
>
> If the numbers above were accurate, this would just mean you'd go from 60%
> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>

Point is that RBF transactions are unsafe even when waiting for a
confirmation, which Peter Todd trivially proved in the reply next to this.
The reliable solution is to reject all RBF payments and direct those users
to custodial accounts. There are other variants to solve this with varying
degree of convolutedness. RBF is a strictly worse UX as proven by anyone
accepting bitcoin payments at scale.


> > For me
> > personally it would be an easier discussion to have when Lightning is at
> > 80%+ of all bitcoin transactions.
>
> Can you extrapolate from the numbers you've seen to estimate when that
> might be, given current trends?
>

Not sure, it might be exponential growth, and the next 60% of Lightning
growth happen faster than the first 15%. Hard to tell. But we're likely
talking years here..


>
> > The benefits of Lightning are many and obvious,
> > we don't need to limit onchain to make Lightning more appealing.
>
> To be fair, I think making lightning (and coinjoins) work better is
> exactly what inspired this -- not as a "make on-chain worse so we look
> better in comparison", but as a "making lightning work well is a bunch
> of hard problems, here's the next thing we need in order to beat the
> next problem".
>

In deed. The fact that the largest non-custodial Lightning wallet started
this thread should be an indicator that despite these intentions the
solution harms more than it fixes.
Transactions being evicted from mempool is solved by requiring a minimum
fee rate, which we do and now seems to have become a standard practice.
Theoretically we can imagine them being evicted anyway but now we're
several theoreticals deep again when discussing something that will cause
massive problems right away. In emergency situations CPFP and similar can
of course be done manually in special circumstances.

Cheers
Sergej


On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> wrote:

> On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > The
> > biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> > (it's actually quite easily managed),
>
> You mean "it's quite easily managed, provided the transaction doesn't
> opt-in to rbf", right? At least, that's what I understood you saying last
> time; ie that if the tx signals rbf, then you just don't do zeroconf no
> matter what other trustworthy signals you might see:
>
>   https://twitter.com/ziggamon/status/1435863691816275970
>
> (rbf txs seem to have increased from 22% then to 29% now)
>
> > it's FX risk as the merchant must
> > commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> > some transactions lose money to FX and others earn money - that evens out
> > in the end.
>
> > But if there is an _easily accessible in the wallet_ feature to
> > "cancel transaction" that means it will eventually get systematically
> > abused. A risk of X% loss on many payments that's easy to systematically
> > abuse is more scary than a rare risk of losing 100% of one occasional
> > payment. It's already possible to execute this form of abuse with opt-in
> > RBF,
>
> If someone's going to systematically exploit your store via this
> mechanism, it seems like they'd just find a single wallet with a good
> UX for opt-in RBF and lowballing fees, and go to town -- not something
> where opt-in rbf vs fullrbf policies make any difference at all?
>
> It's not like existing wallets that don't let you set RBF will suddenly
> get a good UX for replacing transactions just because they'd be relayed
> if they did, is it?
>
> > To successfully fool (non-RBF)
> > zeroconf one needs to have access to mining infrastructure and
> probability
> > of success is the % of hash rate controlled.
>
> I thought the "normal" avenue for fooling non-RBF zeroconf was to create
> two conflicting txs in advance, one paying the merchant, one paying
> yourself, connect to many peers, relay the one paying the merchant to
> the merchant, and the other to everyone else.
>
> I'm just basing this off Peter Todd's stuff from years ago:
>
>
> https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
>
>
> https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
>
> > Currently Lightning is somewhere around 15% of our total bitcoin
> payments.
>
> So, based on last year's numbers, presumably that makes your bitcoin
> payments break down as something like:
>
>    5% txs are on-chain and seem shady and are excluded from zeroconf
>   15% txs are lightning
>   20% txs are on-chain but signal rbf and are excluded from zeroconf
>   60% txs are on-chain and seem fine for zeroconf
>
> > This is very much not nothing, and all of us here want Lightning to grow,
> > but I think it warrants a serious discussion on whether we want Lightning
> > adoption to go to 100% by means of disabling on-chain commerce.
>
> If the numbers above were accurate, this would just mean you'd go from 60%
> zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
>
> > For me
> > personally it would be an easier discussion to have when Lightning is at
> > 80%+ of all bitcoin transactions.
>
> Can you extrapolate from the numbers you've seen to estimate when that
> might be, given current trends? Or perhaps when fine-for-zeroconf txs
> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
> work the same in a fullrbf world.
>
> > The benefits of Lightning are many and obvious,
> > we don't need to limit onchain to make Lightning more appealing.
>
> To be fair, I think making lightning (and coinjoins) work better is
> exactly what inspired this -- not as a "make on-chain worse so we look
> better in comparison", but as a "making lightning work well is a bunch
> of hard problems, here's the next thing we need in order to beat the
> next problem".
>
> > Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> > After interacting with users during high-fee periods I've come to not
> > appreciate RBF as a solution to that issue. Most users (80% or so) simply
> > don't have access to that functionality, because their wallet doesn't
> > support it, or they use a custodial (exchange) wallet etc. Of those that
> > have the feature - only the power users understand how RBF works, and
> > explaining how to do RBF to a non-power-user is just too complex, for the
> > same reason why it's complex for wallets to make sensible non-power-user
> UI
> > around it. Current equilibrium is that mostly only power users have
> access
> > to RBF and they know how to handle it, so things are somewhat working.
> But
> > rolling this out to the broad market is something else and would likely
> > cause more confusion.
> > CPFP is somewhat more viable but also not perfect as it would require
> lots
> > of edge case code to handle abuse vectors: What if users abuse a generous
> > CPFP policy to unstuck past transactions or consolidate large wallets.
> Best
> > is for CPFP to be done on the wallet side, not the merchant side, but
> there
> > too are the same UX issues as with RBF.
>
> I think if you're ruling out both merchants and users being able to add
> fees to a tx to get it to confirm, then you're going to lose either way.
> Txs will either expire because they've been stuck for more than a week,
> and be vulnerable to replacement at that point anyway, or they'll be
> dropped from mempools because they've filled up and they were the lowest
> fee tx, and be vulnerable to replacement for that reason. In the expiry
> case, the merchant can rebroadcast the original transaction to keep it
> alive, perhaps with a good chance of beating an attacker to the punch,
> but in the full mempool case, you could only do that if you were also
> CPFPing it, which you already ruled out.
>
> Cheers,
> aj
>


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Anthony Towns]

On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed),

You mean "it's quite easily managed, provided the transaction doesn't
opt-in to rbf", right? At least, that's what I understood you saying last
time; ie that if the tx signals rbf, then you just don't do zeroconf no
matter what other trustworthy signals you might see:

  https://twitter.com/ziggamon/status/1435863691816275970

(rbf txs seem to have increased from 22% then to 29% now)

> it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end.

> But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF,

If someone's going to systematically exploit your store via this
mechanism, it seems like they'd just find a single wallet with a good
UX for opt-in RBF and lowballing fees, and go to town -- not something
where opt-in rbf vs fullrbf policies make any difference at all? 

It's not like existing wallets that don't let you set RBF will suddenly
get a good UX for replacing transactions just because they'd be relayed
if they did, is it?

> To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled.

I thought the "normal" avenue for fooling non-RBF zeroconf was to create
two conflicting txs in advance, one paying the merchant, one paying
yourself, connect to many peers, relay the one paying the merchant to
the merchant, and the other to everyone else.

I'm just basing this off Peter Todd's stuff from years ago:

https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/

https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py

> Currently Lightning is somewhere around 15% of our total bitcoin payments.

So, based on last year's numbers, presumably that makes your bitcoin
payments break down as something like:

   5% txs are on-chain and seem shady and are excluded from zeroconf
  15% txs are lightning
  20% txs are on-chain but signal rbf and are excluded from zeroconf
  60% txs are on-chain and seem fine for zeroconf

> This is very much not nothing, and all of us here want Lightning to grow,
> but I think it warrants a serious discussion on whether we want Lightning
> adoption to go to 100% by means of disabling on-chain commerce.

If the numbers above were accurate, this would just mean you'd go from 60%
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.

> For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions.

Can you extrapolate from the numbers you've seen to estimate when that
might be, given current trends? Or perhaps when fine-for-zeroconf txs
drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
work the same in a fullrbf world.

> The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing. 

To be fair, I think making lightning (and coinjoins) work better is
exactly what inspired this -- not as a "make on-chain worse so we look
better in comparison", but as a "making lightning work well is a bunch
of hard problems, here's the next thing we need in order to beat the
next problem".

> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.

I think if you're ruling out both merchants and users being able to add
fees to a tx to get it to confirm, then you're going to lose either way.
Txs will either expire because they've been stuck for more than a week,
and be vulnerable to replacement at that point anyway, or they'll be
dropped from mempools because they've filled up and they were the lowest
fee tx, and be vulnerable to replacement for that reason. In the expiry
case, the merchant can rebroadcast the original transaction to keep it
alive, perhaps with a good chance of beating an attacker to the punch,
but in the full mempool case, you could only do that if you were also
CPFPing it, which you already ruled out.

Cheers,
aj

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

[Peter Todd]

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

On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> Hi all,
> 
> Chiming in on this thread as I feel like the real dangers of RBF as default
> policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even bigger danger called the
> american call option, which risks endangering the entirety of BIP21 "Scan
> this QR code with your wallet to buy this product" model that I believe
> we've all come to appreciate. Specifically, in a scenario with high
> volatility and many transactions in the mempools (which is where RBF would
> come in handy), a user can make a low-fee transaction and then wait for
> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
> up, user can cancel his transaction and make a new - cheaper one. The

I just checked this, and Bitrefill accepts transactions with RBF enabled.

> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end. But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically

...and I checked this with Electrum on Android, which has a handy "Cancel
Transaction" feature in the UI to easily cancel a payment. Which I did. You
should have a pending payment from this email, and unsurprisingly I don't have
my gift card. :)

The ship has already sailed on this. I'd suggest accepting Lightning, which
drastically shortens the time window involved.

FWIW, fixedfloat.com already deals with this call option risk by charging a
higher fee (1% vs 0.5%) for conversions where the exact destination amount has
been locked in; the default is for the exact destination amount to be picked at
the moment of confirmation.

> abused. A risk of X% loss on many payments that's easy to systematically
> Bitrefill currently processes 1500-2000 onchain payments every day. For us,
> a world where bitcoin becomes de facto RBF by default, means that we would

Electrum is RBF by default. So does Green Wallet, and many other wallets,  as
well as many exchanges. Most of those wallets/exchanges don't even have a way
to send a transaction without RBF. This ship has sailed.

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

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

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

[Antoine Riard]

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

Hi Sergej,

Thanks for the insightful posting, especially highlighting the FX risk
which was far from being evident on my side!

I don't know in details the security architecture of Bitrefill zeroconf
acceptance system, though from what I suppose there is at least a set of
full-nodes well-connected across the p2p network, on top of which some
mempools reconciliation is exercised
and zeroconf candidate sanitize against. While I believe this is a far-more
robust deployment against double-spend attempts, there is still the ability
for a sophisticated attacker to "taint" miner mempools, and from then
partition judiciously the transaction-relay network to game such
distributed mempool monitoring system. There is also the possibility of an
attacker using some "divide-and-conquer" transaction broadcast algorithm to
map Bitrefill monitoring point, though as far as I'm aware such algorithm
has not been discussed. I agree with all of that, easier said than done.

(Which let me think that such distributed mempool monitoring system should
be provide some enhanced security even in a full-rbf world, that they would
require far more resources than the average node from the p2p network as a
whole might be a counter-argument for their social acceptance, however I'm
also thinking that a robust Lightning infrastructure of the future might
require multiple mempool/transaction-relay endpoints, at least to reduce
cross-layer mapping links, though conversation for another day...).

About the FX risk itself, this is far from being isolated from 0conf, as
Lightning payments themselves might still have a time lapse between the
issuance of invoices and the settlement of the HTLC at the payee endpoint.
In fact this volatility concern is endured by anyone using Bitcoin
regularly in interface with the fiats worlds, i.e everyone excepted the
long-term store of wealth crowd. From a merchant perspective, effectively,
the options to cover themselves against this risk are simple. One could
take positions directly in traditional financial derivatives, like doing
participants in international trades, though it would require an educated
manpower on the merchant side. Or leveraging some stablecoins derivatives
system, coming with its own technical complexity and social trust hazards.
Another direction would be to clearly define the responsibility between
merchants or users, on whom is the FX risk. If it's on users, they should
be the one RBFing/CPFPing to increase the merchant address output, beyond
the fact "dynamic pricing" would be a weird UX, it would require liveliness
from the wallets until block confirmation (introducing here many
requirements of a LN wallet). If it's on the merchants, they could be the
ones CPFPing thanks to package relay, though it would come again with some
engineering complexity and overhead blockspace cost (and the first version
of package relay likely won't enable CPFP batching for concerns of
potential bandwidth/CPU DoS).

On the efficacy of RBF, I understand the current approach of assuming
"manual" RBFing by power users ill UX thinking. I hope in the future to
have automatic fee-bumping implemented by user wallets, where a fee-bumping
budget and a confirmation preference are pre-defined for all payments, and
the fee-bumping logic "simply" enforcing the user policy, ideally based on
historical mempool data. True fact: we don't have such logic in consumer
wallets today. Or at least only rudimentary in the backend of LN
implementations, and only for time-sensitive on-chain claims for now (or at
least speaking for LDK). If we take the history of browsers as a
comparison, while we might be out of the Lynx-style phase of wallets, we
might still be more in the late Netscape kind of thing than something like
Chrome today. In other words, there are many directions for improvements
for users' wallets.

All that said, I learn to converge that as a community we would be better
off to weigh deeper the risks/costs between 0confs applications and
contracting protocols in light of full-rbf.

Best,
Antoine

Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hi all,
>
> Chiming in on this thread as I feel like the real dangers of RBF as
> default policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even bigger danger called the
> american call option, which risks endangering the entirety of BIP21 "Scan
> this QR code with your wallet to buy this product" model that I believe
> we've all come to appreciate. Specifically, in a scenario with high
> volatility and many transactions in the mempools (which is where RBF would
> come in handy), a user can make a low-fee transaction and then wait for
> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
> up, user can cancel his transaction and make a new - cheaper one. The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end. But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF, which may lead to us at some point refusing those payments (even with
> confirmation) or cumbersome UX to work around it, such as crediting the
> bitcoin to a custodial account.
>
> To compare zeroconf risk with FX risk: I think we've had one incident in 8
> years of operation where a user successfully fooled our server to accept a
> payment that in the end didn't confirm. To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled. This is simply due to the fact
> that the network currently won't propagage the replacement transaction to
> the miner, which is what's being discussed here. American call option risk
> would however be available to 100% of all users, needs nothing beyond the
> wallet app, and has no cost to the user - only upside.
>
> Bitrefill currently processes 1500-2000 onchain payments every day. For
> us, a world where bitcoin becomes de facto RBF by default, means that we
> would likely turn off the BIP21 model for onchain payments, instruct
> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
> account that we have.
> This option is however not available for your typical
> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
> from other merchants or payment providers how they see this new behavior
> and how they would counteract it.
>
> Currently Lightning is somewhere around 15% of our total bitcoin payments.
> This is very much not nothing, and all of us here want Lightning to grow,
> but I think it warrants a serious discussion on whether we want Lightning
> adoption to go to 100% by means of disabling on-chain commerce. For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions. Currently far too many bitcoin users
> simply don't have access to Lightning, and of those that do and hold their
> own keys Muun is the biggest wallet per our data, not least due to their
> ease-of-use which is under threat per the OP. It's hard to assess how many
> users would switch to Lightning in such a scenario, the communication
> around it would be hard. My intuition says that the majority of the current
> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
> probably shift to an alt. The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing. As an
> anecdote, we did experiment with defaulting to bech32 addresses some years
> back. The result was that simply users of the wallets that weren't able to
> pay to bech32 didn't complete the purchase, no support ticket or anything,
> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
> implemented a wallet selector to allow modern wallets to pay to bech32
> while other wallets can pay to P2SH. This type of thing  is clunky, and
> requires a certain level of scale to be able to do, we certainly wouldn't
> have had the manpower for that when we were starting out. This why I'm
> cautious about introducing more such clunkiness vectors as they are
> centralizing factors.
>
> I'm well aware of the reason for this policy being suggested and the
> potential pinning attack vector for LN and other smart contracts, but I
> think these two risks/costs need to be weighed against eachother first and
> thoroughly discussed because the costs are non-trivial on both sides.
>
> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.
> In the end a risk-based approach to decide on which payments are
> non-trivial to reverse is the easiest, taking account user experience and
> such. Remember that in the fiat world card payments have up to 5%
> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
> 1 in a million" accepted transactions successfully reversed. These days we
> have very few support issues related to bitcoin payments. The few that do
> come in are due to accidental RBF users venting frustration about waiting
> for their tx to confirm.
> "In theory, theory and practice are the same. In practice, they are not"
>
> All the best,
> Sergej Kotliar
> CEO Bitrefill.com
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Greg Sanders]

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

Another downside is that the sender may not opt into a non-pinnable future
format like "V3 transactions", making CPFP difficult. They may spend a lot
of fees to do this however, so maybe we're really reaching here.

On Wed, Oct 19, 2022 at 12:07 PM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It's an interesting idea, presumably it would work w the new package relay.
> Scorched earth bidding war is definitely fine to deter this type of abuse.
> Need to consider it more thoroughly from all sides tho. CPFP on the server
> side generally has a couple of downsides:
> * Requires a hot wallet to receive bitcoin
> * an entity that is reliably known to do CPFP can be abused by people
> looking to consolidate utxos, which can be quite costly. Might be solvable
> with a set of conditionals, and bad UX for abusers is less of a concern :)
>
> Will follow up after more deliberation, thanks!
>
>
> On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin <jeremy.l.rubin@gmail.com>
> wrote:
>
>> If they do this to you, and the delta is substantial, can't you sweep all
>> such abusers with a cpfp transaction replacing their package and giving you
>> the original txn?
>>
>> On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> Chiming in on this thread as I feel like the real dangers of RBF as
>>> default policy aren't sufficiently elaborated here. It's not only about the
>>> zero-conf (I'll get to that) but there is an even bigger danger called the
>>> american call option, which risks endangering the entirety of BIP21 "Scan
>>> this QR code with your wallet to buy this product" model that I believe
>>> we've all come to appreciate. Specifically, in a scenario with high
>>> volatility and many transactions in the mempools (which is where RBF would
>>> come in handy), a user can make a low-fee transaction and then wait for
>>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>>> up, user can cancel his transaction and make a new - cheaper one. The
>>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>>> (it's actually quite easily managed), it's FX risk as the merchant must
>>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>>> some transactions lose money to FX and others earn money - that evens out
>>> in the end. But if there is an _easily accessible in the wallet_ feature to
>>> "cancel transaction" that means it will eventually get systematically
>>> abused. A risk of X% loss on many payments that's easy to systematically
>>> abuse is more scary than a rare risk of losing 100% of one occasional
>>> payment. It's already possible to execute this form of abuse with opt-in
>>> RBF, which may lead to us at some point refusing those payments (even with
>>> confirmation) or cumbersome UX to work around it, such as crediting the
>>> bitcoin to a custodial account.
>>>
>>> To compare zeroconf risk with FX risk: I think we've had one incident in
>>> 8 years of operation where a user successfully fooled our server to accept
>>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>>> zeroconf one needs to have access to mining infrastructure and probability
>>> of success is the % of hash rate controlled. This is simply due to the fact
>>> that the network currently won't propagage the replacement transaction to
>>> the miner, which is what's being discussed here. American call option risk
>>> would however be available to 100% of all users, needs nothing beyond the
>>> wallet app, and has no cost to the user - only upside.
>>>
>>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>>> us, a world where bitcoin becomes de facto RBF by default, means that we
>>> would likely turn off the BIP21 model for onchain payments, instruct
>>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>>> account that we have.
>>> This option is however not available for your typical
>>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>>> from other merchants or payment providers how they see this new behavior
>>> and how they would counteract it.
>>>
>>> Currently Lightning is somewhere around 15% of our total bitcoin
>>> payments. This is very much not nothing, and all of us here want Lightning
>>> to grow, but I think it warrants a serious discussion on whether we want
>>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>>> For me personally it would be an easier discussion to have when Lightning
>>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>>> users simply don't have access to Lightning, and of those that do and hold
>>> their own keys Muun is the biggest wallet per our data, not least due to
>>> their ease-of-use which is under threat per the OP. It's hard to assess how
>>> many users would switch to Lightning in such a scenario, the communication
>>> around it would be hard. My intuition says that the majority of the current
>>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
>>> probably shift to an alt. The benefits of Lightning are many and obvious,
>>> we don't need to limit onchain to make Lightning more appealing. As an
>>> anecdote, we did experiment with defaulting to bech32 addresses some years
>>> back. The result was that simply users of the wallets that weren't able to
>>> pay to bech32 didn't complete the purchase, no support ticket or anything,
>>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
>>> implemented a wallet selector to allow modern wallets to pay to bech32
>>> while other wallets can pay to P2SH. This type of thing  is clunky, and
>>> requires a certain level of scale to be able to do, we certainly wouldn't
>>> have had the manpower for that when we were starting out. This why I'm
>>> cautious about introducing more such clunkiness vectors as they are
>>> centralizing factors.
>>>
>>> I'm well aware of the reason for this policy being suggested and the
>>> potential pinning attack vector for LN and other smart contracts, but I
>>> think these two risks/costs need to be weighed against eachother first and
>>> thoroughly discussed because the costs are non-trivial on both sides.
>>>
>>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>>> After interacting with users during high-fee periods I've come to not
>>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>>> don't have access to that functionality, because their wallet doesn't
>>> support it, or they use a custodial (exchange) wallet etc. Of those that
>>> have the feature - only the power users understand how RBF works, and
>>> explaining how to do RBF to a non-power-user is just too complex, for the
>>> same reason why it's complex for wallets to make sensible non-power-user UI
>>> around it. Current equilibrium is that mostly only power users have access
>>> to RBF and they know how to handle it, so things are somewhat working. But
>>> rolling this out to the broad market is something else and would likely
>>> cause more confusion.
>>> CPFP is somewhat more viable but also not perfect as it would require
>>> lots of edge case code to handle abuse vectors: What if users abuse a
>>> generous CPFP policy to unstuck past transactions or consolidate large
>>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>>> side, but there too are the same UX issues as with RBF.
>>> In the end a risk-based approach to decide on which payments are
>>> non-trivial to reverse is the easiest, taking account user experience and
>>> such. Remember that in the fiat world card payments have up to 5%
>>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>>> 1 in a million" accepted transactions successfully reversed. These days we
>>> have very few support issues related to bitcoin payments. The few that do
>>> come in are due to accidental RBF users venting frustration about waiting
>>> for their tx to confirm.
>>> "In theory, theory and practice are the same. In practice, they are not"
>>>
>>> All the best,
>>> Sergej Kotliar
>>> CEO Bitrefill.com
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill> | Blog
>>> <https://www.bitrefill.com/blog/> | Angellist
>>> <https://angel.co/bitrefill>
>>>
>>>
>>> --
>>>
>>> Sergej Kotliar
>>>
>>> CEO
>>>
>>>
>>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>>
>>>
>>> www.bitrefill.com
>>>
>>> Twitter <https://www.twitter.com/bitrefill> | Blog
>>> <https://www.bitrefill.com/blog/> | Angellist
>>> <https://angel.co/bitrefill>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Sergej Kotliar]

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

It's an interesting idea, presumably it would work w the new package relay.
Scorched earth bidding war is definitely fine to deter this type of abuse.
Need to consider it more thoroughly from all sides tho. CPFP on the server
side generally has a couple of downsides:
* Requires a hot wallet to receive bitcoin
* an entity that is reliably known to do CPFP can be abused by people
looking to consolidate utxos, which can be quite costly. Might be solvable
with a set of conditionals, and bad UX for abusers is less of a concern :)

Will follow up after more deliberation, thanks!


On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin <jeremy.l.rubin@gmail.com> wrote:

> If they do this to you, and the delta is substantial, can't you sweep all
> such abusers with a cpfp transaction replacing their package and giving you
> the original txn?
>
> On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Chiming in on this thread as I feel like the real dangers of RBF as
>> default policy aren't sufficiently elaborated here. It's not only about the
>> zero-conf (I'll get to that) but there is an even bigger danger called the
>> american call option, which risks endangering the entirety of BIP21 "Scan
>> this QR code with your wallet to buy this product" model that I believe
>> we've all come to appreciate. Specifically, in a scenario with high
>> volatility and many transactions in the mempools (which is where RBF would
>> come in handy), a user can make a low-fee transaction and then wait for
>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>> up, user can cancel his transaction and make a new - cheaper one. The
>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> (it's actually quite easily managed), it's FX risk as the merchant must
>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> some transactions lose money to FX and others earn money - that evens out
>> in the end. But if there is an _easily accessible in the wallet_ feature to
>> "cancel transaction" that means it will eventually get systematically
>> abused. A risk of X% loss on many payments that's easy to systematically
>> abuse is more scary than a rare risk of losing 100% of one occasional
>> payment. It's already possible to execute this form of abuse with opt-in
>> RBF, which may lead to us at some point refusing those payments (even with
>> confirmation) or cumbersome UX to work around it, such as crediting the
>> bitcoin to a custodial account.
>>
>> To compare zeroconf risk with FX risk: I think we've had one incident in
>> 8 years of operation where a user successfully fooled our server to accept
>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>> zeroconf one needs to have access to mining infrastructure and probability
>> of success is the % of hash rate controlled. This is simply due to the fact
>> that the network currently won't propagage the replacement transaction to
>> the miner, which is what's being discussed here. American call option risk
>> would however be available to 100% of all users, needs nothing beyond the
>> wallet app, and has no cost to the user - only upside.
>>
>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>> us, a world where bitcoin becomes de facto RBF by default, means that we
>> would likely turn off the BIP21 model for onchain payments, instruct
>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>> account that we have.
>> This option is however not available for your typical
>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>> from other merchants or payment providers how they see this new behavior
>> and how they would counteract it.
>>
>> Currently Lightning is somewhere around 15% of our total bitcoin
>> payments. This is very much not nothing, and all of us here want Lightning
>> to grow, but I think it warrants a serious discussion on whether we want
>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>> For me personally it would be an easier discussion to have when Lightning
>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>> users simply don't have access to Lightning, and of those that do and hold
>> their own keys Muun is the biggest wallet per our data, not least due to
>> their ease-of-use which is under threat per the OP. It's hard to assess how
>> many users would switch to Lightning in such a scenario, the communication
>> around it would be hard. My intuition says that the majority of the current
>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
>> probably shift to an alt. The benefits of Lightning are many and obvious,
>> we don't need to limit onchain to make Lightning more appealing. As an
>> anecdote, we did experiment with defaulting to bech32 addresses some years
>> back. The result was that simply users of the wallets that weren't able to
>> pay to bech32 didn't complete the purchase, no support ticket or anything,
>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
>> implemented a wallet selector to allow modern wallets to pay to bech32
>> while other wallets can pay to P2SH. This type of thing  is clunky, and
>> requires a certain level of scale to be able to do, we certainly wouldn't
>> have had the manpower for that when we were starting out. This why I'm
>> cautious about introducing more such clunkiness vectors as they are
>> centralizing factors.
>>
>> I'm well aware of the reason for this policy being suggested and the
>> potential pinning attack vector for LN and other smart contracts, but I
>> think these two risks/costs need to be weighed against eachother first and
>> thoroughly discussed because the costs are non-trivial on both sides.
>>
>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> After interacting with users during high-fee periods I've come to not
>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>> don't have access to that functionality, because their wallet doesn't
>> support it, or they use a custodial (exchange) wallet etc. Of those that
>> have the feature - only the power users understand how RBF works, and
>> explaining how to do RBF to a non-power-user is just too complex, for the
>> same reason why it's complex for wallets to make sensible non-power-user UI
>> around it. Current equilibrium is that mostly only power users have access
>> to RBF and they know how to handle it, so things are somewhat working. But
>> rolling this out to the broad market is something else and would likely
>> cause more confusion.
>> CPFP is somewhat more viable but also not perfect as it would require
>> lots of edge case code to handle abuse vectors: What if users abuse a
>> generous CPFP policy to unstuck past transactions or consolidate large
>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>> side, but there too are the same UX issues as with RBF.
>> In the end a risk-based approach to decide on which payments are
>> non-trivial to reverse is the easiest, taking account user experience and
>> such. Remember that in the fiat world card payments have up to 5%
>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>> 1 in a million" accepted transactions successfully reversed. These days we
>> have very few support issues related to bitcoin payments. The few that do
>> come in are due to accidental RBF users venting frustration about waiting
>> for their tx to confirm.
>> "In theory, theory and practice are the same. In practice, they are not"
>>
>> All the best,
>> Sergej Kotliar
>> CEO Bitrefill.com
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[Greg Sanders]

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

Isn't the extreme of this that the merchant tries to lock in gains on the
upswing via CPFP, and users on the downswing, both doing scorched earth,
tossing the delta to fees?

Seems like a MAD situation?

On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If they do this to you, and the delta is substantial, can't you sweep all
> such abusers with a cpfp transaction replacing their package and giving you
> the original txn?
>
> On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Chiming in on this thread as I feel like the real dangers of RBF as
>> default policy aren't sufficiently elaborated here. It's not only about the
>> zero-conf (I'll get to that) but there is an even bigger danger called the
>> american call option, which risks endangering the entirety of BIP21 "Scan
>> this QR code with your wallet to buy this product" model that I believe
>> we've all come to appreciate. Specifically, in a scenario with high
>> volatility and many transactions in the mempools (which is where RBF would
>> come in handy), a user can make a low-fee transaction and then wait for
>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
>> up, user can cancel his transaction and make a new - cheaper one. The
>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> (it's actually quite easily managed), it's FX risk as the merchant must
>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> some transactions lose money to FX and others earn money - that evens out
>> in the end. But if there is an _easily accessible in the wallet_ feature to
>> "cancel transaction" that means it will eventually get systematically
>> abused. A risk of X% loss on many payments that's easy to systematically
>> abuse is more scary than a rare risk of losing 100% of one occasional
>> payment. It's already possible to execute this form of abuse with opt-in
>> RBF, which may lead to us at some point refusing those payments (even with
>> confirmation) or cumbersome UX to work around it, such as crediting the
>> bitcoin to a custodial account.
>>
>> To compare zeroconf risk with FX risk: I think we've had one incident in
>> 8 years of operation where a user successfully fooled our server to accept
>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>> zeroconf one needs to have access to mining infrastructure and probability
>> of success is the % of hash rate controlled. This is simply due to the fact
>> that the network currently won't propagage the replacement transaction to
>> the miner, which is what's being discussed here. American call option risk
>> would however be available to 100% of all users, needs nothing beyond the
>> wallet app, and has no cost to the user - only upside.
>>
>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>> us, a world where bitcoin becomes de facto RBF by default, means that we
>> would likely turn off the BIP21 model for onchain payments, instruct
>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>> account that we have.
>> This option is however not available for your typical
>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>> from other merchants or payment providers how they see this new behavior
>> and how they would counteract it.
>>
>> Currently Lightning is somewhere around 15% of our total bitcoin
>> payments. This is very much not nothing, and all of us here want Lightning
>> to grow, but I think it warrants a serious discussion on whether we want
>> Lightning adoption to go to 100% by means of disabling on-chain commerce.
>> For me personally it would be an easier discussion to have when Lightning
>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>> users simply don't have access to Lightning, and of those that do and hold
>> their own keys Muun is the biggest wallet per our data, not least due to
>> their ease-of-use which is under threat per the OP. It's hard to assess how
>> many users would switch to Lightning in such a scenario, the communication
>> around it would be hard. My intuition says that the majority of the current
>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
>> probably shift to an alt. The benefits of Lightning are many and obvious,
>> we don't need to limit onchain to make Lightning more appealing. As an
>> anecdote, we did experiment with defaulting to bech32 addresses some years
>> back. The result was that simply users of the wallets that weren't able to
>> pay to bech32 didn't complete the purchase, no support ticket or anything,
>> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
>> implemented a wallet selector to allow modern wallets to pay to bech32
>> while other wallets can pay to P2SH. This type of thing  is clunky, and
>> requires a certain level of scale to be able to do, we certainly wouldn't
>> have had the manpower for that when we were starting out. This why I'm
>> cautious about introducing more such clunkiness vectors as they are
>> centralizing factors.
>>
>> I'm well aware of the reason for this policy being suggested and the
>> potential pinning attack vector for LN and other smart contracts, but I
>> think these two risks/costs need to be weighed against eachother first and
>> thoroughly discussed because the costs are non-trivial on both sides.
>>
>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> After interacting with users during high-fee periods I've come to not
>> appreciate RBF as a solution to that issue. Most users (80% or so) simply
>> don't have access to that functionality, because their wallet doesn't
>> support it, or they use a custodial (exchange) wallet etc. Of those that
>> have the feature - only the power users understand how RBF works, and
>> explaining how to do RBF to a non-power-user is just too complex, for the
>> same reason why it's complex for wallets to make sensible non-power-user UI
>> around it. Current equilibrium is that mostly only power users have access
>> to RBF and they know how to handle it, so things are somewhat working. But
>> rolling this out to the broad market is something else and would likely
>> cause more confusion.
>> CPFP is somewhat more viable but also not perfect as it would require
>> lots of edge case code to handle abuse vectors: What if users abuse a
>> generous CPFP policy to unstuck past transactions or consolidate large
>> wallets. Best is for CPFP to be done on the wallet side, not the merchant
>> side, but there too are the same UX issues as with RBF.
>> In the end a risk-based approach to decide on which payments are
>> non-trivial to reverse is the easiest, taking account user experience and
>> such. Remember that in the fiat world card payments have up to 5%
>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
>> 1 in a million" accepted transactions successfully reversed. These days we
>> have very few support issues related to bitcoin payments. The few that do
>> come in are due to accidental RBF users venting frustration about waiting
>> for their tx to confirm.
>> "In theory, theory and practice are the same. In practice, they are not"
>>
>> All the best,
>> Sergej Kotliar
>> CEO Bitrefill.com
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Jeremy Rubin]

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

If they do this to you, and the delta is substantial, can't you sweep all
such abusers with a cpfp transaction replacing their package and giving you
the original txn?

On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Chiming in on this thread as I feel like the real dangers of RBF as
> default policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even bigger danger called the
> american call option, which risks endangering the entirety of BIP21 "Scan
> this QR code with your wallet to buy this product" model that I believe
> we've all come to appreciate. Specifically, in a scenario with high
> volatility and many transactions in the mempools (which is where RBF would
> come in handy), a user can make a low-fee transaction and then wait for
> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
> up, user can cancel his transaction and make a new - cheaper one. The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end. But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF, which may lead to us at some point refusing those payments (even with
> confirmation) or cumbersome UX to work around it, such as crediting the
> bitcoin to a custodial account.
>
> To compare zeroconf risk with FX risk: I think we've had one incident in 8
> years of operation where a user successfully fooled our server to accept a
> payment that in the end didn't confirm. To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled. This is simply due to the fact
> that the network currently won't propagage the replacement transaction to
> the miner, which is what's being discussed here. American call option risk
> would however be available to 100% of all users, needs nothing beyond the
> wallet app, and has no cost to the user - only upside.
>
> Bitrefill currently processes 1500-2000 onchain payments every day. For
> us, a world where bitcoin becomes de facto RBF by default, means that we
> would likely turn off the BIP21 model for onchain payments, instruct
> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
> account that we have.
> This option is however not available for your typical
> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
> from other merchants or payment providers how they see this new behavior
> and how they would counteract it.
>
> Currently Lightning is somewhere around 15% of our total bitcoin payments.
> This is very much not nothing, and all of us here want Lightning to grow,
> but I think it warrants a serious discussion on whether we want Lightning
> adoption to go to 100% by means of disabling on-chain commerce. For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions. Currently far too many bitcoin users
> simply don't have access to Lightning, and of those that do and hold their
> own keys Muun is the biggest wallet per our data, not least due to their
> ease-of-use which is under threat per the OP. It's hard to assess how many
> users would switch to Lightning in such a scenario, the communication
> around it would be hard. My intuition says that the majority of the current
> 85% of bitcoin users that pay onchain would just not use bitcoin anymore,
> probably shift to an alt. The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing. As an
> anecdote, we did experiment with defaulting to bech32 addresses some years
> back. The result was that simply users of the wallets that weren't able to
> pay to bech32 didn't complete the purchase, no support ticket or anything,
> just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
> implemented a wallet selector to allow modern wallets to pay to bech32
> while other wallets can pay to P2SH. This type of thing  is clunky, and
> requires a certain level of scale to be able to do, we certainly wouldn't
> have had the manpower for that when we were starting out. This why I'm
> cautious about introducing more such clunkiness vectors as they are
> centralizing factors.
>
> I'm well aware of the reason for this policy being suggested and the
> potential pinning attack vector for LN and other smart contracts, but I
> think these two risks/costs need to be weighed against eachother first and
> thoroughly discussed because the costs are non-trivial on both sides.
>
> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.
> In the end a risk-based approach to decide on which payments are
> non-trivial to reverse is the easiest, taking account user experience and
> such. Remember that in the fiat world card payments have up to 5%
> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
> 1 in a million" accepted transactions successfully reversed. These days we
> have very few support issues related to bitcoin payments. The few that do
> come in are due to accidental RBF users venting frustration about waiting
> for their tx to confirm.
> "In theory, theory and practice are the same. In practice, they are not"
>
> All the best,
> Sergej Kotliar
> CEO Bitrefill.com
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
>
>
> --
>
> Sergej Kotliar
>
> CEO
>
>
> Twitter: @ziggamon <https://twitter.com/ziggamon>
>
>
> www.bitrefill.com
>
> Twitter <https://www.twitter.com/bitrefill> | Blog
> <https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Erik Aronesty]

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

> Currently Lightning is somewhere around 15% of our total bitcoin
payments. This is very much not nothing, and all of us here want Lightning
to grow, but I think it warrants a serious discussion on whether we want
Lightning adoption to go to 100% by means of disabling on-chain commerce.

Is this about disabling "on-chain instant commerce"?

 - Waiting for confirmation on-chain before shipping a product won't
change, normally it's 15 minutes or so.  This doesn't change that.

 - An easy way to cancel/rbf a transaction doesn't exist - like you said,
there's no UX for this now, and I don't anticipate one being broadly used
except by inter-exchange transfers, etc.

So what does this change?

 - In the rare event that an RBF transaction is received where the fee
level means confirmation times will be slow a merchant will have to wait
very long for at least 1 confirmation, the merchant should alert the user
that the transaction may take longer than the BTC FX rate guarantee window,
and may require additional funds if FX rates change.

 - Users with wallets that support RBF can now be encouraged to accelerate
the tx, with help and advice depending on their wallet, in order to lock in
the FX rates

 - 0 conf is still viable strategy for releasing an order, as long as fees
are very high, and it's very likely to be included in the next block.
 More fee analysis is needed to validate 0 conf and mitigate risks, but now
it is, at least, more "honest" to the true risks.

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

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

[Sergej Kotliar]

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

Hi all,

Chiming in on this thread as I feel like the real dangers of RBF as default
policy aren't sufficiently elaborated here. It's not only about the
zero-conf (I'll get to that) but there is an even bigger danger called the
american call option, which risks endangering the entirety of BIP21 "Scan
this QR code with your wallet to buy this product" model that I believe
we've all come to appreciate. Specifically, in a scenario with high
volatility and many transactions in the mempools (which is where RBF would
come in handy), a user can make a low-fee transaction and then wait for
hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
up, user can cancel his transaction and make a new - cheaper one. The
biggest risk in accepting bitcoin payments is in fact not zeroconf risk
(it's actually quite easily managed), it's FX risk as the merchant must
commit to a certain BTCUSD rate ahead of time for a purchase. Over time
some transactions lose money to FX and others earn money - that evens out
in the end. But if there is an _easily accessible in the wallet_ feature to
"cancel transaction" that means it will eventually get systematically
abused. A risk of X% loss on many payments that's easy to systematically
abuse is more scary than a rare risk of losing 100% of one occasional
payment. It's already possible to execute this form of abuse with opt-in
RBF, which may lead to us at some point refusing those payments (even with
confirmation) or cumbersome UX to work around it, such as crediting the
bitcoin to a custodial account.

To compare zeroconf risk with FX risk: I think we've had one incident in 8
years of operation where a user successfully fooled our server to accept a
payment that in the end didn't confirm. To successfully fool (non-RBF)
zeroconf one needs to have access to mining infrastructure and probability
of success is the % of hash rate controlled. This is simply due to the fact
that the network currently won't propagage the replacement transaction to
the miner, which is what's being discussed here. American call option risk
would however be available to 100% of all users, needs nothing beyond the
wallet app, and has no cost to the user - only upside.

Bitrefill currently processes 1500-2000 onchain payments every day. For us,
a world where bitcoin becomes de facto RBF by default, means that we would
likely turn off the BIP21 model for onchain payments, instruct Bitcoin
users to use Lightning or deposit onchain BTC to a custodial account that
we have.
This option is however not available for your typical
BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
from other merchants or payment providers how they see this new behavior
and how they would counteract it.

Currently Lightning is somewhere around 15% of our total bitcoin payments.
This is very much not nothing, and all of us here want Lightning to grow,
but I think it warrants a serious discussion on whether we want Lightning
adoption to go to 100% by means of disabling on-chain commerce. For me
personally it would be an easier discussion to have when Lightning is at
80%+ of all bitcoin transactions. Currently far too many bitcoin users
simply don't have access to Lightning, and of those that do and hold their
own keys Muun is the biggest wallet per our data, not least due to their
ease-of-use which is under threat per the OP. It's hard to assess how many
users would switch to Lightning in such a scenario, the communication
around it would be hard. My intuition says that the majority of the current
85% of bitcoin users that pay onchain would just not use bitcoin anymore,
probably shift to an alt. The benefits of Lightning are many and obvious,
we don't need to limit onchain to make Lightning more appealing. As an
anecdote, we did experiment with defaulting to bech32 addresses some years
back. The result was that simply users of the wallets that weren't able to
pay to bech32 didn't complete the purchase, no support ticket or anything,
just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later
implemented a wallet selector to allow modern wallets to pay to bech32
while other wallets can pay to P2SH. This type of thing  is clunky, and
requires a certain level of scale to be able to do, we certainly wouldn't
have had the manpower for that when we were starting out. This why I'm
cautious about introducing more such clunkiness vectors as they are
centralizing factors.

I'm well aware of the reason for this policy being suggested and the
potential pinning attack vector for LN and other smart contracts, but I
think these two risks/costs need to be weighed against eachother first and
thoroughly discussed because the costs are non-trivial on both sides.

Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
After interacting with users during high-fee periods I've come to not
appreciate RBF as a solution to that issue. Most users (80% or so) simply
don't have access to that functionality, because their wallet doesn't
support it, or they use a custodial (exchange) wallet etc. Of those that
have the feature - only the power users understand how RBF works, and
explaining how to do RBF to a non-power-user is just too complex, for the
same reason why it's complex for wallets to make sensible non-power-user UI
around it. Current equilibrium is that mostly only power users have access
to RBF and they know how to handle it, so things are somewhat working. But
rolling this out to the broad market is something else and would likely
cause more confusion.
CPFP is somewhat more viable but also not perfect as it would require lots
of edge case code to handle abuse vectors: What if users abuse a generous
CPFP policy to unstuck past transactions or consolidate large wallets. Best
is for CPFP to be done on the wallet side, not the merchant side, but there
too are the same UX issues as with RBF.
In the end a risk-based approach to decide on which payments are
non-trivial to reverse is the easiest, taking account user experience and
such. Remember that in the fiat world card payments have up to 5%
chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than
1 in a million" accepted transactions successfully reversed. These days we
have very few support issues related to bitcoin payments. The few that do
come in are due to accidental RBF users venting frustration about waiting
for their tx to confirm.
"In theory, theory and practice are the same. In practice, they are not"

All the best,
Sergej Kotliar
CEO Bitrefill.com


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>


-- 

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

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

[alicexbt]

Hi aj,

> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?

Bitcoin Core contributors and maintainers should provide the options, recommendations etc. about mempool policies. If these policies are kept for users to change based on their needs, why force anything or change defaults ignoring feedback?

> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this.

Why even provide options for users to change RBF policy in that case? Option to disable was already [removed][1] ignoring NACKs and MarcoFalke prefers users try the [workaround][2] if there is ever a need to disable it. Are we going to remove all the options to switch RBF policies in future because fullrbf has been suggested by leading technical experts? Is there a possibility of experts going wrong and has it ever happened in past?

> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either.

To be fair, John Carvalho did [comment][3] about this in a pull request although it was wrong PR and never going to be merged.

> And I mean: all this is only about drawing a line in sand; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.

I think this is the best option for users at this point. Keep running older versions of Core and use Knots or other implementations until technical experts in core repository, other bitcoin projects and users are on the same page.

> And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").

Even I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks.

[1]: https://github.com/bitcoin/bitcoin/pull/16171
[2]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1157846575
[3]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, October 18th, 2022 at 12:30 PM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> 
> > > 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> > > payments indefinitely
> > > 2) Draw a line in the sand now, but give people who are currently
> > > accepting unconfirmed txs time to update their software and business
> > > model
> > > 3) Encourage mainnet miners and relay nodes to support unconditional
> > > RBF immediately, no matter how much that increases the risk to
> > > existing businesses that are still accepting unconfirmed txs
> > > To give more context, the initial approach of enabling full RBF through
> > > #25353 + #25600 wasn't making the assumption the enablement itself would
> > > reach agreement of the economic majority or unanimity.
> 
> 
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
> 
> Having a majority of nodes/hashrate support it makes the upsides better,
> but doesn't change the downsides to the people who are relying on it
> not being available.
> 
> > Without denying that such equilibrium would be unstable, it was designed to
> > remove the responsibility of the Core project itself to "draw a hard line"
> > on the subject.
> 
> 
> Removing responsibility from core developers seems like it's very much
> optimising for the wrong thing to me.
> 
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
> 
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.
> 
> At that point, the technical experts should be coming up with a
> specific recommendation, and, personally, I think that's exactly what
> happened with [0] [1] and [2].
> 
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1] https://github.com/bitcoin/bitcoin/pull/25353
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
> 
> That did draw hard line in the sand: it said "hey, opt-in RBF had a good
> run, but it's time to switch over to full RBF, for these reasons".
> 
> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").
> 
> [3] https://bitcoinops.org/en/newsletters/2022/06/22/
> [4] https://bitcoinops.org/en/newsletters/2022/07/13/
> 
> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
> 
> And I mean: all this is only about drawing a line in sand; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.
> 
> > Moreover, relying on node operators turning on the setting
> > provides a smoother approach offering time to zero-conf services to react
> > in consequence.
> 
> 
> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.
> 
> > So the current path definitely belongs more to a 3) approach.
> 
> > > 3) Encourage mainnet miners and relay nodes to support unconditional
> > > RBF immediately, no matter how much that increases the risk to
> > > existing businesses that are still accepting unconfirmed txs
> 
> 
> Yes, that's how it appears to me, too. It's not my preference (giving
> people clear warning of changes seems much better to me), but I can
> certainly live with it.
> 
> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems very disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks.
> 
> That is, it seems to me that Dario was exactly right in titling this
> thread "Zero-conf apps in immediate danger", and our co-developers who
> are dismissing the risk by saying things along the lines of "probably
> nothing will change anytime soon" are exactly wrong.
> 
> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)
> 
> > While this
> > way cannot be denied to be a zero-risk deployment for business accepting
> > unconfirmed transactions, it should be weighed in face of multi-party
> > contracting protocols encumbering an annoying pinning vector.
> 
> 
> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?
> 
> > Since Dario's mail, I think we have learnt new data points, a) on the long
> > term full RBF to align miner incentives is acknowledged and b) a clear
> > timeline based on e.g a block height is favored over the pollination
> > deployment.
> 
> 
> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").
> 
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.
> 
> Slowing that down from January-ish to May seems like it ought to be a
> big win for anyone who has been doing zeroconf, and having it be easy
> to find a path to miners when it is supported seems like a big win even
> given a cost of a few months delay.
> 
> OTOH, if we're really not expecting full rbf to be available for many
> months, then I would have expected the "disable this for mainnet,
> reconsider after the release" PR (#26287) to have gone ahead already.
> 
> > Tie-breaking between
> > both, I believe I would favor something like #26323 though only post 24.0
> > to avoid introducing a bikeshedding precedent in terms of release process,
> 
> 
> Doing something like #26323 only after 24.0 is out does nothing to
> mitigate whatever immediate risk there is to bitcoin businesses/users...
> 
> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?
> 
> I mean, if you think the feedback is wrong, that's different: maybe we
> shouldn't care that zeroconf apps are in immediate danger, and maybe
> bitcoin would be better if any that don't adapt immediately all die
> horribly as a lesson to others not to make similarly bad assumptions.
> 
> But saying "we don't want them to be in danger" and also refusing to do
> anything to avoid it?
> 
> Cheers,
> aj
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Antoine Riard]

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

> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.

Yes, this has been the crux of the conceptual discussion in #25600.

> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
>
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.

In the present case, I don't think there is a real concern of a frivolous
or half-baked lawsuit. My concern is rather the pretension to omniscience
that we would adopt as Core devs w.r.t policy changes, as far from being a
more closed, hermetic system like the p2p stack, it's interfacing with the
operations of a number of Bitcoin applications and second-layer contracting
protocols. As of today, I think this is still a relatively short process to
analyze the implications of any policy changes on the major Bitcoin
applications
flows and L2s of the day (i.e mainly Lightning and coinjoins). I'm not sure
this statement will stay true in a future with a growing fauna of L2s (i.e
vaults, DLC-over-channel, peerswaps, etc), each presenting unique
characteristics.

How do we minimize the odds of policy-based disruptions for current Bitcoin
softwares and users ? I don't have strong ideas, though I wish for the Core
project to adopt a more open-ended and smooth approach to release
context-rich policy changes. I aimed with #25353 and #25600 to experiment
with such a smoother approach advocated for (rather than the last year
proposal of turning on by default full-rbf, that was a wrong and missing
context). I hope at least one good outcome of this gradual process has been
to give time to Dario to publish a thoughtful standpoint for 0conf
operators, of which at least I learnt a few interesting elements on the UX
of such applications.

> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").

Yeah, I'm still valuing the mailing list as a kind of "broadcast-all"
communication channel towards all the community stakeholders, though this
is the perspective of a developer and I'm not sure business/services
operators have the same communication habits. There is definitely a
reflection to hold, if we, as Core devs, we should follow a better
communication standard when we propose significant policy changes. And go
the full-tour of Reddit AMA, podcasts and newsletters as suggested in my
reply to Dario. It's hard to know if lack of vocal reactions on the mailing
list or to the publication of optech newsletter signifies a lack of
opposition, a lack of negatively impacted users or lack of interest from
the wider community. Maybe we should have a formalized, bulletpoints -based
for future policy changes, with clear time buffers and actions items, I
don't know.

> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
>
> And I mean: all this is only about drawing a line in *sand*; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.

In the present case, it's more a lack of feedback showing up until we start
doing rcs, rather than a pretty closed-off way of doing things. That we
should amend expected and already-merged changes in the function of
feedback, I'm all for it in principle. The hard question is the set of
decision heuristics to converge on to qualify such feedback as worthy to
react on. Again in this case, we're doing some risk arbitrage (which I
really dislike as a situation) between 0conf applications and multi-party
funding flows of contracting protocols. Correcting our release process
isn't free of implications as we're removing the risk burden on some class
of use-case to pour it on a second class, in my opinion. Moreover, assuming
we have to bind to reasonable communication standards which is an open
question, I'm also worried we would also normalize the publication of very
late feedback from community stakeholders.

> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.

First, without more visibility brought back on the 0confs operations
necessary to adapt their operations, two months might be considered as
enough. 8 weeks is sensibly the release schedule followed by few
open-source projects in the ecosystem. Second, the communication machine
behind softforks activation sounds to be far more fine-tuned, or at least
gather spontaneously community self-coordination than policy changes, and
it would be reasonable to expect things to be slower with policy changes.
However, I would agree you can have a quick adoption a day from another
with one single well-crafted meme buzzing on Twitter. Social phenomenas
don't offer the same degree of predictability than system engineering. How
we cope up with that, as core devs, I don't know.

> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems *very* disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks.

I'm not sure if it has been established clearly, though as I announced on
IRC two weeks ago, Dario reached out to me offline before publishing his
mail. My recommendation to him have been immediately to adjoin 0confs
services examples impacted, if possible with numbers on users affected and
evaluation of engineering and operational effort if would request to adapt
their use-cases, and inviting to publish on this venue, as business
operators might not be used to with open-source process (I can disclose the
correspondence if requested and with Dario approval).

Goal was to collect the maximum of data points in our community
decision-making process about full-rbf. Now this doesn't relieve us of
finding a common ground on what should be a minimal bar to accept those
points, how to value those data
points, if we should take operators on their raw numbers or request the
publication of "light" proofs like on-chain transactions, lightning
invoices (everyone in business would take the happy measure showing the
most active users possible). The question of what signals we should
collect, and how we process them is a hard question in a decentralized and
trust-minimized process like the Bitcoin development one, from my
perspective. I don't have strong ideas there.

Though speaking for myself, and not for other contributors, I've raised the
warnings about potential impacts of full-rbfs in both my June 2021 [0] and
June 2022 [1] mails, so I find the qualification of disingenuous is a bit
ungrounded. Overall, I would remind all that it's better to keep patience
in face of complex changes in Core, rather than to fall quickly in a blame
ascription position.

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

(I don't deny "blame-and-reward" assignments can be worthy a posteriori,
once we're out of the "hot" discussion phase, especially to introspect on
how we can improve our engineering process, though in the middle of a
discussion... I don't know, it sounds premature and noisy).

> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)

I can share the sentiment about mainstream economics and the way
risk-management impacts large-range of human beings is completely shrug
on... Though again in the present case, I think it would be more productive
to describe what engineering
needs or standards expectations of you are not fulfilled rather than to
fallback on the pure expression of an uncomfortableness and how as a
community of contributors we could improve on that. Though to object,
speaking of risk appreciation, not hardening the funding phase of
multi-party funding protocols also lets the door open to DoS attacks by
deanonymizing attackers targeting things like coinjoin.

> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?

I agree. I would like to observe that "reasonable time to react" and
"adequate risk statement" is more an art than a science.

> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").

About John Carvalho disagreeing about full-rbf, I think he voiced a concern
during the summer on one of the PR introducing a full-rbf setting and I did
invite to voice his concerns on the ML, invitation stayed without follow-up
until the recent days [2] [3]. I would have loved to spend time back then
arguing on the full-rbf and miners incentives compatibility.

[2] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654
[3] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163815017

I know we all have busy agendas and a short timeline to react to all the
changes happening in the Bitcoin ecosystem... I think I replied to John
Carvalho answer on this thread, inviting him to develop his argumentation
further and I'm staying available to discuss with any full-rbf opponents,
in a calm and respectful fashion [4].

[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021027.html

> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.

Yeah I mean this could have been a forward process before Dario published
his thoughts. Achieving 5%-20% hashpower and full-rbf relay paths would
have assumed landing #25600 _and_ actually reach out to few mining pools to
inform them about the potential economic benefits. Now, I think the best
process is to keep listening to more feedback from the community, lay out
all the deployment options in code we have done and think more before
committing to something.

> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?

I think this might be the point where I could say we're diverging. In
principle, I agree we should listen to negative feedback raising harmful
disruptions risks for users and services. The more open, practical question
to me is more how we collect, qualify and sanitize such negative feedback
in a way which is acceptable for the community at large. Giving concrete
bounds to the immediate dangers in a consensual way, and asserting this
danger results from a lack of communication of the Core project, I'm still
wondering on those subjects. And note again, I didn't deny the option 3)
approach as you laid out was zero-risk for 0conf operators.

All that said, if we think as a project we should offer a "zero-risk"
process towards 0conf operators w.r.t full-rbf, at the detriment of the
risk encumbered by contracting protocols, I think it can be wise to
resurrect #26287.

Best,
Antoine

Le mar. 18 oct. 2022 à 03:00, Anthony Towns <aj@erisian.com.au> a écrit :

> On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > >  1) Continue supporting and encouraging accepting unconfirmed
> "on-chain"
> > >     payments indefinitely
> > >  2) Draw a line in the sand now, but give people who are currently
> > >     accepting unconfirmed txs time to update their software and
> business
> > >     model
> > >  3) Encourage mainnet miners and relay nodes to support unconditional
> > >     RBF immediately, no matter how much that increases the risk to
> > >     existing businesses that are still accepting unconfirmed txs
> > To give more context, the initial approach of enabling full RBF through
> > #25353 + #25600 wasn't making the assumption the enablement itself would
> > reach agreement of the economic majority or unanimity.
>
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
>
> Having a majority of nodes/hashrate support it makes the upsides better,
> but doesn't change the downsides to the people who are relying on it
> not being available.
>
> > Without denying that such equilibrium would be unstable, it was designed
> to
> > remove the responsibility of the Core project itself to "draw a hard
> line"
> > on the subject.
>
> Removing responsibility from core developers seems like it's very much
> optimising for the wrong thing to me.
>
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a whole
> are avoiding that responsibility?
>
> Core devs are supposedly top technical experts at bitcoin -- which means
> they're the ones that should have the best understanding of all the
> implications of policy changes like this. Is opt-in RBF only fine? If
> you look at the network today, it sure seems like it; it takes a pretty
> good technical understanding to figure out what problems it has, and
> an even better one to figure out whether those problems can be solved
> while keeping an opt-in RBF regime, or if full RBF is needed.
>
> At that point, the technical experts *should* be coming up with a
> specific recommendation, and, personally, I think that's exactly what
> happened with [0] [1] and [2].
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1] https://github.com/bitcoin/bitcoin/pull/25353
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
>
> That did draw hard line in the sand: it said "hey, opt-in RBF had a good
> run, but it's time to switch over to full RBF, for these reasons".
>
> It's a bit disappointing that the people that's a problem for didn't
> engage earlier -- though looking back, I guess there wasn't all that
> much effort made to reach out, either. There were two mentions in the
> optech newsletter [3] [4] but it wasn't called out as an "action item"
> (maybe those aren't a thing anymore), so it may have been pretty missable,
> especially given RBF has been discussed on and off for so long. And the
> impression I got from the PR review club discussion more seemed like
> devs making assumptions about businesses rather than having talked to
> them (eg "[I] think there are fewer and fewer businesses who absolutely
> cannot survive without relying on zeroconf. Or at least hope so").
>
> [3] https://bitcoinops.org/en/newsletters/2022/06/22/
> [4] https://bitcoinops.org/en/newsletters/2022/07/13/
>
> If we're happy to not get feedback until we start doing rcs, that's fine;
> but if we want to say "oops, we're into release candidates, you should
> have something earlier, it's too late now", that's a pretty closed-off
> way of doing things.
>
> And I mean: all this is only about drawing a line in *sand*; if people
> think core devs are wrong, they can still let that line blow away in
> the wind, by running different software, configuring core differently,
> patching core, or whatever else.
>
> > Moreover, relying on node operators turning on the setting
> > provides a smoother approach offering time to zero-conf services to react
> > in consequence.
>
> I don't think that's remotely true: take a look at taproot activation:
> it took two months between releasing code that supported signalling and
> having 98% of hashrate signalling; with 40% of blocks signalling within
> the first two weeks.
>
> > So the current path definitely belongs more to a 3) approach.
>
> > >  3) Encourage mainnet miners and relay nodes to support unconditional
> > >     RBF immediately, no matter how much that increases the risk to
> > >     existing businesses that are still accepting unconfirmed txs
>
> Yes, that's how it appears to me, too. It's not my preference (giving
> people clear warning of changes seems much better to me), but I can
> certainly live with it.
>
> But if the line in the sand is "we're doing this, no matter how much that
> increases the risk to existing businesses that weren't expecting it" then
> it seems *very* disingenuous not to make those risks very clear so that
> people who weren't expecting it actually take action to avoid those risks.
>
> That is, it seems to me that Dario was exactly right in titling this
> thread "Zero-conf apps in immediate danger", and our co-developers who
> are dismissing the risk by saying things along the lines of "probably
> nothing will change anytime soon" are exactly wrong.
>
> (More generally, that's similar to one of the things I've hated
> watching in mainstream economics over the past few years: "doing this
> will cause massive inflation" "no it won't, there's no inflation risk"
> "oops, inflation magically appeared, how did that happen? oh well, too
> bad, we have to live with it now". This looks pretty similar to me: "do
> something risky, deny the risk, make sure nobody can hold us accountable
> when the risk eventuates later" so it makes me really uncomfortable)
>
> > While this
> > way cannot be denied to be a zero-risk deployment for business accepting
> > unconfirmed transactions, it should be weighed in face of multi-party
> > contracting protocols encumbering an annoying pinning vector.
>
> Sure; that's a fine reason to draw the line in the sand. But it's not
> a good reason to have it happen immediately, rather than giving people
> time to react, and it's not a good reason to understate the risk of
> it happening now. Maybe there are good reasons for either or both of
> those, though?
>
> > Since Dario's mail, I think we have learnt new data points, a) on the
> long
> > term full RBF to align miner incentives is acknowledged and b) a clear
> > timeline based on e.g a block height is favored over the pollination
> > deployment.
>
> Using the passive voice there doesn't seem helpful. Who learnt these
> things? You, I and Dario all seem to agree with (a), but John Carvalho
> certainly appears not to, for instance. I'm not sure who agrees with
> (b) -- I know I do, and I think Dario does; but multiple people seem
> opposed to the clear timeline offered in #26323, and your #26305 seems
> more likely to encourage a "pollination" approach rather than discourage
> it ("oh, this will be the default option for 25.0, might as well enable
> it now like all the cool kids are").
>
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.
>
> Slowing that down from January-ish to May seems like it ought to be a
> big win for anyone who has been doing zeroconf, and having it be easy
> to find a path to miners when it is supported seems like a big win even
> given a cost of a few months delay.
>
> OTOH, if we're really not expecting full rbf to be available for many
> months, then I would have expected the "disable this for mainnet,
> reconsider after the release" PR (#26287) to have gone ahead already.
>
> > Tie-breaking between
> > both, I believe I would favor something like #26323 though only post 24.0
> > to avoid introducing a bikeshedding precedent in terms of release
> process,
>
> Doing something like #26323 only after 24.0 is out does nothing to
> mitigate whatever immediate risk there is to bitcoin businesses/users...
>
> And if the choice is between "bikeshedding" and "merge a PR, then ignore
> feedback that it's harmful", I'd much rather the bikeshedding. What's
> the point of having rcs if you're going to ignore negative feedback?
>
> I mean, if you think the feedback is wrong, that's different: maybe we
> shouldn't care that zeroconf apps are in immediate danger, and maybe
> bitcoin would be better if any that don't adapt immediately all die
> horribly as a lesson to others not to make similarly bad assumptions.
>
> But saying "we don't want them to be in danger" and also refusing to do
> anything to avoid it?
>
> Cheers,
> aj
>
>

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

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

[Anthony Towns]

On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote:
> >  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
> >     payments indefinitely
> >  2) Draw a line in the sand now, but give people who are currently
> >     accepting unconfirmed txs time to update their software and business
> >     model
> >  3) Encourage mainnet miners and relay nodes to support unconditional
> >     RBF immediately, no matter how much that increases the risk to
> >     existing businesses that are still accepting unconfirmed txs
> To give more context, the initial approach of enabling full RBF through
> #25353 + #25600 wasn't making the assumption the enablement itself would
> reach agreement of the economic majority or unanimity. 

Full RBF doesn't need a majority or unanimity to have an impact; it needs
adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
a 10MvB mempool can be replaced before being mined naturally), and some
way of finding a working path to relay txs to that hashrate.

Having a majority of nodes/hashrate support it makes the upsides better,
but doesn't change the downsides to the people who are relying on it
not being available.

> Without denying that such equilibrium would be unstable, it was designed to
> remove the responsibility of the Core project itself to "draw a hard line"
> on the subject.

Removing responsibility from core developers seems like it's very much
optimising for the wrong thing to me.

I mean, I guess I can understand wanting to reduce that responsibility
for maintainers of the github repo, even if for no other reason than to
avoid frivolous lawsuits, but where do you expect people to find better
advice about what things are a good/bad idea if core devs as a whole
are avoiding that responsibility?

Core devs are supposedly top technical experts at bitcoin -- which means
they're the ones that should have the best understanding of all the
implications of policy changes like this. Is opt-in RBF only fine? If
you look at the network today, it sure seems like it; it takes a pretty
good technical understanding to figure out what problems it has, and
an even better one to figure out whether those problems can be solved
while keeping an opt-in RBF regime, or if full RBF is needed.

At that point, the technical experts *should* be coming up with a
specific recommendation, and, personally, I think that's exactly what
happened with [0] [1] and [2].

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[1] https://github.com/bitcoin/bitcoin/pull/25353
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

That did draw hard line in the sand: it said "hey, opt-in RBF had a good
run, but it's time to switch over to full RBF, for these reasons".

It's a bit disappointing that the people that's a problem for didn't
engage earlier -- though looking back, I guess there wasn't all that
much effort made to reach out, either. There were two mentions in the
optech newsletter [3] [4] but it wasn't called out as an "action item"
(maybe those aren't a thing anymore), so it may have been pretty missable,
especially given RBF has been discussed on and off for so long. And the
impression I got from the PR review club discussion more seemed like
devs making assumptions about businesses rather than having talked to
them (eg "[I] think there are fewer and fewer businesses who absolutely
cannot survive without relying on zeroconf. Or at least hope so").

[3] https://bitcoinops.org/en/newsletters/2022/06/22/
[4] https://bitcoinops.org/en/newsletters/2022/07/13/

If we're happy to not get feedback until we start doing rcs, that's fine;
but if we want to say "oops, we're into release candidates, you should
have something earlier, it's too late now", that's a pretty closed-off
way of doing things.

And I mean: all this is only about drawing a line in *sand*; if people
think core devs are wrong, they can still let that line blow away in
the wind, by running different software, configuring core differently,
patching core, or whatever else.

> Moreover, relying on node operators turning on the setting
> provides a smoother approach offering time to zero-conf services to react
> in consequence.

I don't think that's remotely true: take a look at taproot activation:
it took two months between releasing code that supported signalling and
having 98% of hashrate signalling; with 40% of blocks signalling within
the first two weeks.

> So the current path definitely belongs more to a 3) approach.

> >  3) Encourage mainnet miners and relay nodes to support unconditional
> >     RBF immediately, no matter how much that increases the risk to
> >     existing businesses that are still accepting unconfirmed txs

Yes, that's how it appears to me, too. It's not my preference (giving
people clear warning of changes seems much better to me), but I can
certainly live with it.

But if the line in the sand is "we're doing this, no matter how much that
increases the risk to existing businesses that weren't expecting it" then
it seems *very* disingenuous not to make those risks very clear so that
people who weren't expecting it actually take action to avoid those risks.

That is, it seems to me that Dario was exactly right in titling this
thread "Zero-conf apps in immediate danger", and our co-developers who
are dismissing the risk by saying things along the lines of "probably
nothing will change anytime soon" are exactly wrong.

(More generally, that's similar to one of the things I've hated
watching in mainstream economics over the past few years: "doing this
will cause massive inflation" "no it won't, there's no inflation risk"
"oops, inflation magically appeared, how did that happen? oh well, too
bad, we have to live with it now". This looks pretty similar to me: "do
something risky, deny the risk, make sure nobody can hold us accountable
when the risk eventuates later" so it makes me really uncomfortable)

> While this
> way cannot be denied to be a zero-risk deployment for business accepting
> unconfirmed transactions, it should be weighed in face of multi-party
> contracting protocols encumbering an annoying pinning vector.

Sure; that's a fine reason to draw the line in the sand. But it's not
a good reason to have it happen immediately, rather than giving people
time to react, and it's not a good reason to understate the risk of
it happening now. Maybe there are good reasons for either or both of
those, though?

> Since Dario's mail, I think we have learnt new data points, a) on the long
> term full RBF to align miner incentives is acknowledged and b) a clear
> timeline based on e.g a block height is favored over the pollination
> deployment.

Using the passive voice there doesn't seem helpful. Who learnt these
things? You, I and Dario all seem to agree with (a), but John Carvalho
certainly appears not to, for instance. I'm not sure who agrees with
(b) -- I know I do, and I think Dario does; but multiple people seem
opposed to the clear timeline offered in #26323, and your #26305 seems
more likely to encourage a "pollination" approach rather than discourage
it ("oh, this will be the default option for 25.0, might as well enable
it now like all the cool kids are").

For what it's worth, my guess is that releasing core with full rbf
support and having you and Murch and others advocating for people to
try it out, will mean that full RBF is usable on mainnet within two
or three months, supported by perhaps 5%-20% hashpower, but probably
still requiring special effort to actually find a peer that can relay
full rbf txs to that hashpower (probably doing an addnode, despite the
privacy implications). Even if that happens, I'm not super confident
that it would mean people would actively steal from zeroconf businesses
in any volume, though. It's not something I'd risk happening to me,
but accepting zeroconf from strangers isn't something I'd risk anyway.

Slowing that down from January-ish to May seems like it ought to be a
big win for anyone who has been doing zeroconf, and having it be easy
to find a path to miners when it is supported seems like a big win even
given a cost of a few months delay.

OTOH, if we're really not expecting full rbf to be available for many
months, then I would have expected the "disable this for mainnet,
reconsider after the release" PR (#26287) to have gone ahead already.

> Tie-breaking between
> both, I believe I would favor something like #26323 though only post 24.0
> to avoid introducing a bikeshedding precedent in terms of release process,

Doing something like #26323 only after 24.0 is out does nothing to
mitigate whatever immediate risk there is to bitcoin businesses/users...

And if the choice is between "bikeshedding" and "merge a PR, then ignore
feedback that it's harmful", I'd much rather the bikeshedding. What's
the point of having rcs if you're going to ignore negative feedback?

I mean, if you think the feedback is wrong, that's different: maybe we
shouldn't care that zeroconf apps are in immediate danger, and maybe
bitcoin would be better if any that don't adapt immediately all die
horribly as a lesson to others not to make similarly bad assumptions.

But saying "we don't want them to be in danger" and also refusing to do
anything to avoid it?

Cheers,
aj

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

[Antoine Riard]

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

Hi John,

I hear your worry about RBF issuing concerns for 0conf acceptance
merchants. I don't think it has been denied in the first communication of
this opt-in rbf proposal back in June. Merchants/0confs builders have been
invited to bring voices to the surface at that time [0]. So this new
full-RBF proposal has at least tried to bind to best communication
standards towards the community at large. If you think about more community
venues (Reddit, podcast, newsletter, ...) that developers may weigh in when
proposing Core policy changes, we can improve for next time.

About the kernel of the concern I understand, I think the whole discussion
would benefit from clarifications in precising zero-conf security bounds.
Relying only on first-seen and lack of RBF as a solo ground to estimate the
safety of an incoming transaction isn't that robust in a distributed system
like the p2p network. However, building management risks framework on top,
as additional security layers sound a far more compelling approach from a
developer perspective. A year ago, when I initially proposed full-rbf, I
noted a few ideas that could be implemented such as double-spend monitoring
or staked reputation to enhance zero-conf security [1]. For sure, there is
a wide solution space to explore and build on to improve the 0conf flows,
and it would marginally benefit LN, as we have now zero-conf channels [2].

That said, saying RBF causes more problems than it resolves sounds hard to
hold as a line from my perspective. As LN security relies on a reactive
model, where time-sensitive transactions must be included before a given
height to ensure funds safety, the ability to replace-by-fee previous bids
and have them propagating well on the network is fundamental. While I think
this is correct to say that today 0conf might be still a more significant
economic traffic than Lightning, the bitcoin user of tomorrow is likely to
expect both 0conf and Lightning, without caring that much about the
quibbles of the security mechanisms backing them.

Overall, RBF is far from being a "black-and-white" thing, dependending of
the perspective you're coming from, and thanks to everyone for patience in
this discussion.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
[2] https://github.com/lightning/bolts/pull/910

Le ven. 7 oct. 2022 à 12:43, Dario Sneidermanis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For
> the past
> few days we've been reviewing the latest bitcoin core release candidate,
> and we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed
> addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF
> flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to
> the new policies. However, when reviewing the 24.0 release candidate just
> a few
> days ago, we realized that zero-conf apps (like Muun) must *immediately
> turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can
> delay the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue
> fixing
> the remaining relay policy problems, such as package relay and the RBF
> rules.
> Maybe we could go straight to an opt-out deployment locked by code at a
> certain
> height in the future to give time to everyone and, at the same time, avoid
> a
> huge mempool divergence event?
>
> Below is our analysis of how zero-conf apps break with opt-in full-RBF. I
> hope
> it helps.
>
> Cheers,
> Dario
>
>
> # How do zero-conf apps work
>
> While the workings and trade-offs of zero-conf applications might be known
> by
> many in this list, it's useful to define precisely how they work to
> understand
> how they break.
>
> We call zero-conf applications to entities that accept on-chain payments
> from
> *untrusted parties* and will sometimes deliver the paid-for product or
> service
> without waiting for the transaction to be included in a block.
>
> Some examples of zero-conf apps:
>
> - Muun's submarine swaps for outgoing lightning payments
> - Bitrefill's on-chain payments for gift cards and phone top-ups
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at
> least
>   the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
>   General Byte)
>
> All of these applications are receiving incoming on-chain transactions for
> which
> they don't control the inputs, and performing a risk analysis to decide
> whether
> they are ok with accepting the payment without confirmation.
>
> In practice, this works because once the bitcoin P2P network has fully
> propagated a non-RBF transaction, you need the collaboration of a miner to
> replace it, which isn't easy to get today. Even though many of the biggest
> miners offer off-band transaction broadcasting services, they currently
> won't
> process conflicting transactions.
>
> Roughly, the risk analysis goes like this:
>
> 1. if an incoming transaction is RBF (direct or inherited)
>    --> too risky, wait for 1 conf (or more) since it can be replaced at
> any time
> 2. if the payment is for an amount greater than X
>    --> too risky, wait for 1 conf (or more), since the amount is worthy of
> a
>        sophisticated attacker
> 3. wait for full(ish) propagation of the incoming transaction
> 4. if there's no double-spend attempt
>    --> accept 0-conf
>
> As with any other risk analysis, there's always a false-negative detection
> rate,
> leading to an expected loss, which the zero-conf app should be willing to
> bear.
> Notice that the expected loss is tunable via the amount X in the above
> analysis.
>
>
> # Why are zero-conf apps not protected with an opt-in deployment
>
> Full-RBF adoption works on three different layers:
>
> - The transaction application layer
> - The transaction relaying layer
> - The transaction mining layer
>
> If an application wants to replace with full-RBF an *outgoing*
> transaction, it
> will need:
>
> - An upgraded node that opted into full-RBF, from which it can broadcast
> the
>   replacement transaction
> - A connected component of upgraded nodes that opted into full-RBF, that
> can
>   relay the replacement transaction
> - A miner in that connected component with an upgraded node that opted into
>   full-RBF, that can mine the replacement transaction
>
> However, an application cannot control whether a replacement to an
> *incoming*
> transaction is relayed via full-RBF. As soon as a single application can
> generate replacements easily via full-RBF, all other applications have to
> assume
> that any incoming transaction from an untrusted party might be replaced via
> full-RBF. That is, for the application layer this is a forced upgrade.
>
> As soon as an unsophisticated attacker can use opt-in full-RBF, the risk
> analysis performed by zero-conf applications stops working because the
> transactions to analyze are all incoming transactions from untrusted
> parties.
> Since some wallets already implement cancel functionality for opt-in RBF
> transactions, enabling the same functionality for every transaction
> wouldn't
> require much work, making canceling any unconfirmed transaction a one-click
> experience. After this, the security model of zero-conf applications goes
> from
> "susceptible to attacks from miners" to "anyone can perform an attack,
> with an
> easy-to-use interface".
>
> That is, the opt-in deployment of full-RBF doesn't protect zero-conf
> applications from having to turn off their zero-conf features very soon
> after
> the initial deployment. All mitigations are mostly ineffective against
> untrusted parties.
>
>
> # Other things we have to fix
>
> While it's clear how full-RBF breaks zero-conf applications, other more
> subtle
> things break in *many* wallets (Muun included). If given the opportunity,
> we
> would like to fix them before deployment. One could argue that these things
> were already broken, but they get considerably worse as the network adopts
> full-RBF (even with an opt-in deployment), so we should fix them.
>
> ## Mental model for unconfirmed incoming transactions
>
> Many wallets with support for on-chain payments (Muun included) show
> incoming
> external transactions in some way to their users before they confirm. This
> is a
> common practice because not showing them leads users to worry that their
> money
> disappeared (exchanges doing this is the #1 issue we have to deal with in
> our
> customer support channels).
>
> With full-RBF, wallets should make it extremely clear to users that
> unconfirmed
> funds are not theirs (yet). Otherwise, protocol-unaware users that are
> transacting on-chain with untrusted parties can be easily scammed if they
> don't
> know they have to wait for a confirmation. Eg. in Argentina, it's pretty
> common
> to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
>
> ## Block explorers as payment receipts
>
> Most wallets with support for on-chain payments (Muun included) use the
> transaction view of a block explorer as a shareable payment receipt. The
> sender
> of an on-chain transaction usually shares this link with the receiver to
> let
> them know they made a payment. Protocol-unaware receivers sometimes take
> this
> link as proof of payment.
>
> Most explorers currently don't track payment replacements and, more
> importantly,
> don't warn users that unconfirmed funds are not theirs (yet). With
> full-RBF,
> wallets should either stop relying on explorers for this functionality or
> wait
> for them to support it explicitly.
>
>
> # Impact at Muun
>
> Work to transition Muun from using zero-conf submarine swaps to using
> payment
> channels is ongoing, but we are still several months away from being
> production
> ready. This means we would have to turn off outgoing lightning payments for
> +100k monthly active users, which is a good chunk of all users making
> non-custodial lightning payments today.
>
> Furthermore, the more subtle fixes imply non-trivial amounts of product
> work
> that we cannot reasonably deploy before they start affecting users.
>
> While I cannot talk for other applications, there are many impacted in one
> way
> or another, and none of the ones I checked with were aware of this change,
> or
> its implications.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Antoine Riard]

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

Hi AJ,

>  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
>     payments indefinitely
>
>  2) Draw a line in the sand now, but give people who are currently
>     accepting unconfirmed txs time to update their software and business
>     model
>
>  3) Encourage mainnet miners and relay nodes to support unconditional
>     RBF immediately, no matter how much that increases the risk to
>     existing businesses that are still accepting unconfirmed txs

To give more context, the initial approach of enabling full RBF through
#25353 + #25600 wasn't making the assumption the enablement itself would
reach agreement of the economic majority or unanimity. Rather, it would
give the tools to node operators to build full-rbf relay paths and as such
to fulfill their applications requirements (e.g lightning dual-funding).
Without denying that such equilibrium would be unstable, it was designed to
remove the responsibility of the Core project itself to "draw a hard line"
on the subject. Moreover, relying on node operators turning on the setting
provides a smoother approach offering time to zero-conf services to react
in consequence.

So the current path definitely belongs more to a 3) approach. While this
way cannot be denied to be a zero-risk deployment for business accepting
unconfirmed transactions, it should be weighed in face of multi-party
contracting protocols encumbering an annoying pinning vector. It sounds to
me that an adequate way to resolve such a "split-risk" situation has been
to adopt a "micro" release practice rather than a "macro" one, namely offer
the options to node operators and let them vote with their respective
economic traffics.

Since Dario's mail, I think we have learnt new data points, a) on the long
term full RBF to align miner incentives is acknowledged and b) a clear
timeline based on e.g a block height is favored over the pollination
deployment.

As such, I think it makes sense to revise the full RBF deployment approach,
concentrating the discussion on the reasonable time buffer we should adopt
before activating full RBF on mainet. A time buffer realistic with respect
to the engineering,
operational and vendoring needs of the zero-conf businesses/applications. I
hope both #26305 and #26323 answer those criterias. Tie-breaking between
both, I believe I would favor something like #26323 though only post 24.0
to avoid introducing a bikeshedding precedent in terms of release process,
and with a longer timeline to be sure we ship 25.0 before the activation
day. Though listening to more feedback and decision factors, if we have
more things to consider.

> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.

Concerning my statement only, it should be re-contextualize with the other
statements calling the zero-conf operators to adapt their services, or
raise concerns, or be proactive at least [0]. On the other hand, from my
perspective, a status quo situation is also unsafe, as we left things like
multi-party coinjoins being DoSed by deanonymizing attackers. So in case of
risk arbitrage situation, as developers, best we can do is be vocal about
it and if possible find a common ground among all stakeholders. And I think
this is what this current thread aims to achieve, which I would say is a
healthy release process.

Best,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

Le dim. 16 oct. 2022 à 04:09, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev
> wrote:
> > > In my view, it is just what I said: a step towards getting full RBF
> > > on the network, by allowing experimentation and socializing the notion
> > > that developers believe it is time.
> > We "believe it is time" for what exactly, though? (a) To start
> > deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> > 18 months; or (b) to start switching mainnet mining and relay nodes over
> > to full RBF?
>
> For what it's worth, that was a serious question: I don't feel like I
> know what other people's answer to it is.
>
> Seems to me like there's fundamentally maybe three approaches:
>
>  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
>     payments indefinitely
>
>  2) Draw a line in the sand now, but give people who are currently
>     accepting unconfirmed txs time to update their software and business
>     model
>
>  3) Encourage mainnet miners and relay nodes to support unconditional
>     RBF immediately, no matter how much that increases the risk to
>     existing businesses that are still accepting unconfirmed txs
>
> I think Antoine gave a pretty decent rationale for why we shouldn't
> indefinitely continue with conditional RBF in [0] [1] -- it makes it
> easy to disrupt decentralised pooling protocols, whether that be for
> establishing lightning channels or coinjoins or anything else.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
>
> It's also an unstable equilibrium -- if everyone does first-seen-is-final
> at the mempool level, everything is fine; but it only takes a few
> defectors to start relaying and mining full RBF txs to spoil zeroconf
> for everyone -- so even if it were desirable to maintain it forever,
> it's probably not actually possible to maintain it indefinitely.
>
> If so, that leaves the choice between (2) and (3). You might argue
> that there's a 4th option: ignore the problem and think about it later;
> but to me that seems like it will just eventually result in outcome (3).
>
>
> At least a few people are already running full RBF relay nodes [2] [3]
> [4], and there's a report that non-signalling RBF txs are now getting
> mined [5] when they weren't a few months ago [6]. I wasn't able to
> confirm the latter to my satisfaction: looking at mempool.observer, the
> non-RBF signalling conflicting txs don't seem to have been consistently
> paying a higher feerate, so I couldn't rule out the possibility that
> the difference might just be due to inconsistent relaying.
>
> [2] https://twitter.com/murchandamus/status/1552488955328831492
> [3] https://twitter.com/LukeDashjr/status/977211607947317254
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
>
> It seems to me that the best approach for implementing (3) would be
> to change the default for -mempoolfullrbf to true immediately, which
> is both what Knots has been doing for years, and what #26305 proposes
> [7].  So from seeing what people are actually *doing*, I could easily
> be convinced that (3) is the goal people are actually working towards.
>
> [7] https://github.com/bitcoin/bitcoin/pull/26305
>
> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.
>
> [8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
> [9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043
> [10]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html
>
> Personally, I prefer an approach like (2) -- commit to doing something
> first, give people time to prepare for it, and then do it, and outside
> of Knots, I don't think there's been any clear commitment to deprecating
> zeroconf txs up until now. But what we're currently doing is suboptimal
> for that in two ways:
>
>  - there's no real commitment that the change will actually happen
>  - even if it does, there's no indication when that will be
>  - it's not easy to test your apps against the new world order, because
>    it's not well supported on either testnet or signet, being disabled
>    by default on both those networks
>
> Dario suggested an approach [12] that seems like it would resolve all
> these issues:
>
> ] This could be one such proposal:
> ] 1. We activate [..] full-RBF on testnet now.
> ] 2. We commit now (in the code) to a block height in the future at
> ]    which [..] full-RBF will activate on mainnet.
>
> (I've delted the words "opt-in" and "opt-out" from the quote above,
> because they didn't make sense to me)
>
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html
>
> I've made up a patch along these lines [13]; it's easy to use a timestamp
> rather than a block height, so I've arbitrarily picked 1st May (slightly
> over 6 months away) as the changeover time. If people are willing to
> give zeroconf businesses some time to adapt, including something along
> those lines in 24.0 seems a better approach to me:
>
>  * it gives a clear deadline for businesses to adapt, so that they don't
>    defer it and suddenly complain "oh no, we didn't think you were
>    serious, please give us more time" later
>
>  * it gives plenty(?) of time to update your code and test it, as well
>    as teach customers and customer support about the new behaviour
>
>  * when the deadline hits, presumably plenty of nodes and miners will
>    immediately start supporting the new behaviour on mainnet, so that
>    protocols can quickly start relying on that method of tx pinning no
>    longer being applicable
>
>  * nodes on signet and testnet will quickly adopt the new behaviour,
>    well before it's available on mainnet, making testing easier
>
> [13] https://github.com/bitcoin/bitcoin/pull/26323
>
> To me, this seems like a good way of achieving what I said previously:
>
> > If we're trying to socialise the idea that zeroconf deprecation is
> > happening and that your business now has a real deadline for migrating
> > away from accepting unconfirmed txs if the risk of being defrauded
> > concerns you, then enabling experimentation on test nets and not touching
> > mainnet until a later release seems fairly fine to me -- similar to
> > activating soft forks on test nets prior to activating it on mainnet.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Antoine Riard]

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

Hi Dario,

Sorry for the latency in reply to the reaction about the full-rbf setting
I've initially pushed in 0.24, TABConf week has been a busy one.

From my understanding, there is no disagreement from Muun wallet about the
gradual deployment of full-rbf by Bitcoin Core nodes, this is more a
question of timeline to allow the zero-conf apps ecosystem to do the
overhaul required.

To recall, my initial motivation to deprecate opt-in RBF over the whole
network is to mitigate a low-cost and easy DoS vector affecting the funding
phase of multi-party contracting protocols:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

As of current, upcoming Bitcoin Core 0.24 release, a `mempoolfullrbf`
setting is introduced defaulting to false. This option allows a node to
accept transaction replace-by-fee without requiring replaceability
signaling. If we assume a reasonable social inertia among Bitcoin Core node
operators, full-rbf transaction-relay paths should be rare. To palliate to
this concern, the introduction of a temporary `NODE_FULL_RBF` service bit
and automated preferential peering is proposed with:

https://github.com/bitcoin/bitcoin/pull/25600

This PR doesn't make the assumption that full-rbf is wished by the majority
of the network of node operators and rather favors an opt-in full-rbf
deployment. The existence of few full-rbf transaction-relay paths and
mining hashrate is sufficient to achieve mitigation of the DoS vector.

As #25600 boosts the deployment of full-rbf transaction-relay paths, and
induces a side-effect of a weakening of zero-conf apps, I can understand
this is not the approach offering the more visibility and predictability to
zero-conf operators.

Since then two more approaches have been proposed, a 1st one turning on by
default `mempoolsetting`, at best to land in 25.0, i.e ~6 months now
following the usual Core release schedule:

https://github.com/bitcoin/bitcoin/pull/26305

A 2nd one making full-rbf by default at a flag day target, 1st May 2023,
aimed to land in 0.24, and as such giving a clear time point to zero-conf
node operators now.

A third option proposed has been to withdraw `mempoolfullrbf` setting for
0.24, now withdrawn by its author:

https://github.com/bitcoin/bitcoin/pull/26287

While in theory, the release process about new policy changes should stay
flexible to correct the unforeseen impacts of policy changes, in the
present case the implications on zero-conf services have been raised early
on when the changes were brought in Bitcoin Core, i.e 4 months ago.
Communication has been posted on this venue to invite zero-conf node
operators to express concerns at that time:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

On a procedural point, I think this is a reasonable standard, navigating in
an area where there are not that many precedents about the deprecation of a
Core policy rule.

Asking to the wider community of zero-conf node operators, among all the
approaches, what has the most likes and what other decision-making factors
should be considered. It is especially interesting if a 6 month time buffer
from now is sufficient for the zero-conf applications to upgrade, and if
not what are the concrete engineering or operational bottlenecks.

Best,
Antoine

Le ven. 7 oct. 2022 à 12:43, Dario Sneidermanis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For
> the past
> few days we've been reviewing the latest bitcoin core release candidate,
> and we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed
> addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF
> flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to
> the new policies. However, when reviewing the 24.0 release candidate just
> a few
> days ago, we realized that zero-conf apps (like Muun) must *immediately
> turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can
> delay the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue
> fixing
> the remaining relay policy problems, such as package relay and the RBF
> rules.
> Maybe we could go straight to an opt-out deployment locked by code at a
> certain
> height in the future to give time to everyone and, at the same time, avoid
> a
> huge mempool divergence event?
>
> Below is our analysis of how zero-conf apps break with opt-in full-RBF. I
> hope
> it helps.
>
> Cheers,
> Dario
>
>
> # How do zero-conf apps work
>
> While the workings and trade-offs of zero-conf applications might be known
> by
> many in this list, it's useful to define precisely how they work to
> understand
> how they break.
>
> We call zero-conf applications to entities that accept on-chain payments
> from
> *untrusted parties* and will sometimes deliver the paid-for product or
> service
> without waiting for the transaction to be included in a block.
>
> Some examples of zero-conf apps:
>
> - Muun's submarine swaps for outgoing lightning payments
> - Bitrefill's on-chain payments for gift cards and phone top-ups
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at
> least
>   the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
>   General Byte)
>
> All of these applications are receiving incoming on-chain transactions for
> which
> they don't control the inputs, and performing a risk analysis to decide
> whether
> they are ok with accepting the payment without confirmation.
>
> In practice, this works because once the bitcoin P2P network has fully
> propagated a non-RBF transaction, you need the collaboration of a miner to
> replace it, which isn't easy to get today. Even though many of the biggest
> miners offer off-band transaction broadcasting services, they currently
> won't
> process conflicting transactions.
>
> Roughly, the risk analysis goes like this:
>
> 1. if an incoming transaction is RBF (direct or inherited)
>    --> too risky, wait for 1 conf (or more) since it can be replaced at
> any time
> 2. if the payment is for an amount greater than X
>    --> too risky, wait for 1 conf (or more), since the amount is worthy of
> a
>        sophisticated attacker
> 3. wait for full(ish) propagation of the incoming transaction
> 4. if there's no double-spend attempt
>    --> accept 0-conf
>
> As with any other risk analysis, there's always a false-negative detection
> rate,
> leading to an expected loss, which the zero-conf app should be willing to
> bear.
> Notice that the expected loss is tunable via the amount X in the above
> analysis.
>
>
> # Why are zero-conf apps not protected with an opt-in deployment
>
> Full-RBF adoption works on three different layers:
>
> - The transaction application layer
> - The transaction relaying layer
> - The transaction mining layer
>
> If an application wants to replace with full-RBF an *outgoing*
> transaction, it
> will need:
>
> - An upgraded node that opted into full-RBF, from which it can broadcast
> the
>   replacement transaction
> - A connected component of upgraded nodes that opted into full-RBF, that
> can
>   relay the replacement transaction
> - A miner in that connected component with an upgraded node that opted into
>   full-RBF, that can mine the replacement transaction
>
> However, an application cannot control whether a replacement to an
> *incoming*
> transaction is relayed via full-RBF. As soon as a single application can
> generate replacements easily via full-RBF, all other applications have to
> assume
> that any incoming transaction from an untrusted party might be replaced via
> full-RBF. That is, for the application layer this is a forced upgrade.
>
> As soon as an unsophisticated attacker can use opt-in full-RBF, the risk
> analysis performed by zero-conf applications stops working because the
> transactions to analyze are all incoming transactions from untrusted
> parties.
> Since some wallets already implement cancel functionality for opt-in RBF
> transactions, enabling the same functionality for every transaction
> wouldn't
> require much work, making canceling any unconfirmed transaction a one-click
> experience. After this, the security model of zero-conf applications goes
> from
> "susceptible to attacks from miners" to "anyone can perform an attack,
> with an
> easy-to-use interface".
>
> That is, the opt-in deployment of full-RBF doesn't protect zero-conf
> applications from having to turn off their zero-conf features very soon
> after
> the initial deployment. All mitigations are mostly ineffective against
> untrusted parties.
>
>
> # Other things we have to fix
>
> While it's clear how full-RBF breaks zero-conf applications, other more
> subtle
> things break in *many* wallets (Muun included). If given the opportunity,
> we
> would like to fix them before deployment. One could argue that these things
> were already broken, but they get considerably worse as the network adopts
> full-RBF (even with an opt-in deployment), so we should fix them.
>
> ## Mental model for unconfirmed incoming transactions
>
> Many wallets with support for on-chain payments (Muun included) show
> incoming
> external transactions in some way to their users before they confirm. This
> is a
> common practice because not showing them leads users to worry that their
> money
> disappeared (exchanges doing this is the #1 issue we have to deal with in
> our
> customer support channels).
>
> With full-RBF, wallets should make it extremely clear to users that
> unconfirmed
> funds are not theirs (yet). Otherwise, protocol-unaware users that are
> transacting on-chain with untrusted parties can be easily scammed if they
> don't
> know they have to wait for a confirmation. Eg. in Argentina, it's pretty
> common
> to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
>
> ## Block explorers as payment receipts
>
> Most wallets with support for on-chain payments (Muun included) use the
> transaction view of a block explorer as a shareable payment receipt. The
> sender
> of an on-chain transaction usually shares this link with the receiver to
> let
> them know they made a payment. Protocol-unaware receivers sometimes take
> this
> link as proof of payment.
>
> Most explorers currently don't track payment replacements and, more
> importantly,
> don't warn users that unconfirmed funds are not theirs (yet). With
> full-RBF,
> wallets should either stop relying on explorers for this functionality or
> wait
> for them to support it explicitly.
>
>
> # Impact at Muun
>
> Work to transition Muun from using zero-conf submarine swaps to using
> payment
> channels is ongoing, but we are still several months away from being
> production
> ready. This means we would have to turn off outgoing lightning payments for
> +100k monthly active users, which is a good chunk of all users making
> non-custodial lightning payments today.
>
> Furthermore, the more subtle fixes imply non-trivial amounts of product
> work
> that we cannot reasonably deploy before they start affecting users.
>
> While I cannot talk for other applications, there are many impacted in one
> way
> or another, and none of the ones I checked with were aware of this change,
> or
> its implications.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Greg Sanders]

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

 AJ,

Thanks for the latest PR and discussion, even if we know we're all (very,
very, very) tired of it running almost 10 years now. I think we're close to
a resolution, (2), or (3) as you note.

As ariard notes in
https://github.com/bitcoin/bitcoin/pull/26323#issuecomment-1280071572 we
seem to have sketched out the sane design space for the transition, so now
it's time to choose how we want to spend our energy and time on this.

I do think patch complexity is a real concern, which
means fullrbf-signalling PR has a harder road to deployment and gets push
back from fullrbf-default-now folks who correctly argue this. It seems
useful to "prove a point" on the nature of these schemes, but not much else.

Personally I have no qualms with kicking back flag-day-fullrbf another
release cycle and 6 additional months to obviate the need for a 24.0
backport(however small!) and to give a bit more time to weigh choices.
People can begin testing with their node software on an opt-in basis(but
not the required ~10% of nodes), 25.0+ nodes will flag-day, then a year
from now the community can start testing if miners have picked up said
changes.

Speaking to no one in particular, there's no virtue in dragging on the
discussion to "prove a point" to "merchants"/"Core devs" when we could be
spending our time more wisely fixing the many other issues with our mempool
and wallet ecosystem.

Best,
Greg

On Sun, Oct 16, 2022 at 4:09 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev
> wrote:
> > > In my view, it is just what I said: a step towards getting full RBF
> > > on the network, by allowing experimentation and socializing the notion
> > > that developers believe it is time.
> > We "believe it is time" for what exactly, though? (a) To start
> > deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> > 18 months; or (b) to start switching mainnet mining and relay nodes over
> > to full RBF?
>
> For what it's worth, that was a serious question: I don't feel like I
> know what other people's answer to it is.
>
> Seems to me like there's fundamentally maybe three approaches:
>
>  1) Continue supporting and encouraging accepting unconfirmed "on-chain"
>     payments indefinitely
>
>  2) Draw a line in the sand now, but give people who are currently
>     accepting unconfirmed txs time to update their software and business
>     model
>
>  3) Encourage mainnet miners and relay nodes to support unconditional
>     RBF immediately, no matter how much that increases the risk to
>     existing businesses that are still accepting unconfirmed txs
>
> I think Antoine gave a pretty decent rationale for why we shouldn't
> indefinitely continue with conditional RBF in [0] [1] -- it makes it
> easy to disrupt decentralised pooling protocols, whether that be for
> establishing lightning channels or coinjoins or anything else.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
>
> It's also an unstable equilibrium -- if everyone does first-seen-is-final
> at the mempool level, everything is fine; but it only takes a few
> defectors to start relaying and mining full RBF txs to spoil zeroconf
> for everyone -- so even if it were desirable to maintain it forever,
> it's probably not actually possible to maintain it indefinitely.
>
> If so, that leaves the choice between (2) and (3). You might argue
> that there's a 4th option: ignore the problem and think about it later;
> but to me that seems like it will just eventually result in outcome (3).
>
>
> At least a few people are already running full RBF relay nodes [2] [3]
> [4], and there's a report that non-signalling RBF txs are now getting
> mined [5] when they weren't a few months ago [6]. I wasn't able to
> confirm the latter to my satisfaction: looking at mempool.observer, the
> non-RBF signalling conflicting txs don't seem to have been consistently
> paying a higher feerate, so I couldn't rule out the possibility that
> the difference might just be due to inconsistent relaying.
>
> [2] https://twitter.com/murchandamus/status/1552488955328831492
> [3] https://twitter.com/LukeDashjr/status/977211607947317254
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
>
> It seems to me that the best approach for implementing (3) would be
> to change the default for -mempoolfullrbf to true immediately, which
> is both what Knots has been doing for years, and what #26305 proposes
> [7].  So from seeing what people are actually *doing*, I could easily
> be convinced that (3) is the goal people are actually working towards.
>
> [7] https://github.com/bitcoin/bitcoin/pull/26305
>
> But if (3) *is* what we're really trying to do, I think it's a bit
> disingenuous to assume that that effort will fail, and tell people that
> nothing's going to change on mainnet in the near future [8] [9] [10]
> [11]. If pools are starting to allow replacements of txs that didn't
> signal according to BIP 125 and mine blocks including those replacements,
> then it's true that zero-conf apps are in much more immediate danger
> than they were a month ago, and as far as I can see, we shouldn't be
> pretending otherwise.
>
> [8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
> [9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043
> [10]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html
>
> Personally, I prefer an approach like (2) -- commit to doing something
> first, give people time to prepare for it, and then do it, and outside
> of Knots, I don't think there's been any clear commitment to deprecating
> zeroconf txs up until now. But what we're currently doing is suboptimal
> for that in two ways:
>
>  - there's no real commitment that the change will actually happen
>  - even if it does, there's no indication when that will be
>  - it's not easy to test your apps against the new world order, because
>    it's not well supported on either testnet or signet, being disabled
>    by default on both those networks
>
> Dario suggested an approach [12] that seems like it would resolve all
> these issues:
>
> ] This could be one such proposal:
> ] 1. We activate [..] full-RBF on testnet now.
> ] 2. We commit now (in the code) to a block height in the future at
> ]    which [..] full-RBF will activate on mainnet.
>
> (I've delted the words "opt-in" and "opt-out" from the quote above,
> because they didn't make sense to me)
>
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html
>
> I've made up a patch along these lines [13]; it's easy to use a timestamp
> rather than a block height, so I've arbitrarily picked 1st May (slightly
> over 6 months away) as the changeover time. If people are willing to
> give zeroconf businesses some time to adapt, including something along
> those lines in 24.0 seems a better approach to me:
>
>  * it gives a clear deadline for businesses to adapt, so that they don't
>    defer it and suddenly complain "oh no, we didn't think you were
>    serious, please give us more time" later
>
>  * it gives plenty(?) of time to update your code and test it, as well
>    as teach customers and customer support about the new behaviour
>
>  * when the deadline hits, presumably plenty of nodes and miners will
>    immediately start supporting the new behaviour on mainnet, so that
>    protocols can quickly start relying on that method of tx pinning no
>    longer being applicable
>
>  * nodes on signet and testnet will quickly adopt the new behaviour,
>    well before it's available on mainnet, making testing easier
>
> [13] https://github.com/bitcoin/bitcoin/pull/26323
>
> To me, this seems like a good way of achieving what I said previously:
>
> > If we're trying to socialise the idea that zeroconf deprecation is
> > happening and that your business now has a real deadline for migrating
> > away from accepting unconfirmed txs if the risk of being defrauded
> > concerns you, then enabling experimentation on test nets and not touching
> > mainnet until a later release seems fairly fine to me -- similar to
> > activating soft forks on test nets prior to activating it on mainnet.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Anthony Towns]

On Thu, Oct 13, 2022 at 02:35:22PM +1000, Anthony Towns via bitcoin-dev wrote:
> On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
> > In my view, it is just what I said: a step towards getting full RBF
> > on the network, by allowing experimentation and socializing the notion
> > that developers believe it is time.
> We "believe it is time" for what exactly, though? (a) To start
> deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
> 18 months; or (b) to start switching mainnet mining and relay nodes over
> to full RBF?

For what it's worth, that was a serious question: I don't feel like I
know what other people's answer to it is.

Seems to me like there's fundamentally maybe three approaches:

 1) Continue supporting and encouraging accepting unconfirmed "on-chain"
    payments indefinitely

 2) Draw a line in the sand now, but give people who are currently
    accepting unconfirmed txs time to update their software and business
    model

 3) Encourage mainnet miners and relay nodes to support unconditional
    RBF immediately, no matter how much that increases the risk to
    existing businesses that are still accepting unconfirmed txs

I think Antoine gave a pretty decent rationale for why we shouldn't
indefinitely continue with conditional RBF in [0] [1] -- it makes it
easy to disrupt decentralised pooling protocols, whether that be for
establishing lightning channels or coinjoins or anything else.

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

It's also an unstable equilibrium -- if everyone does first-seen-is-final
at the mempool level, everything is fine; but it only takes a few
defectors to start relaying and mining full RBF txs to spoil zeroconf
for everyone -- so even if it were desirable to maintain it forever,
it's probably not actually possible to maintain it indefinitely.

If so, that leaves the choice between (2) and (3). You might argue
that there's a 4th option: ignore the problem and think about it later;
but to me that seems like it will just eventually result in outcome (3).


At least a few people are already running full RBF relay nodes [2] [3]
[4], and there's a report that non-signalling RBF txs are now getting
mined [5] when they weren't a few months ago [6]. I wasn't able to
confirm the latter to my satisfaction: looking at mempool.observer, the
non-RBF signalling conflicting txs don't seem to have been consistently
paying a higher feerate, so I couldn't rule out the possibility that
the difference might just be due to inconsistent relaying.

[2] https://twitter.com/murchandamus/status/1552488955328831492
[3] https://twitter.com/LukeDashjr/status/977211607947317254
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
[6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html

It seems to me that the best approach for implementing (3) would be
to change the default for -mempoolfullrbf to true immediately, which
is both what Knots has been doing for years, and what #26305 proposes
[7].  So from seeing what people are actually *doing*, I could easily
be convinced that (3) is the goal people are actually working towards.

[7] https://github.com/bitcoin/bitcoin/pull/26305

But if (3) *is* what we're really trying to do, I think it's a bit
disingenuous to assume that that effort will fail, and tell people that
nothing's going to change on mainnet in the near future [8] [9] [10]
[11]. If pools are starting to allow replacements of txs that didn't
signal according to BIP 125 and mine blocks including those replacements,
then it's true that zero-conf apps are in much more immediate danger
than they were a month ago, and as far as I can see, we shouldn't be
pretending otherwise.

[8] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1274953204
[9] https://github.com/bitcoin/bitcoin/pull/26287#issuecomment-1276682043
[10] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020981.html
[11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021006.html

Personally, I prefer an approach like (2) -- commit to doing something
first, give people time to prepare for it, and then do it, and outside
of Knots, I don't think there's been any clear commitment to deprecating
zeroconf txs up until now. But what we're currently doing is suboptimal
for that in two ways:

 - there's no real commitment that the change will actually happen
 - even if it does, there's no indication when that will be
 - it's not easy to test your apps against the new world order, because
   it's not well supported on either testnet or signet, being disabled
   by default on both those networks

Dario suggested an approach [12] that seems like it would resolve all
these issues:

] This could be one such proposal:
] 1. We activate [..] full-RBF on testnet now.
] 2. We commit now (in the code) to a block height in the future at
]    which [..] full-RBF will activate on mainnet.

(I've delted the words "opt-in" and "opt-out" from the quote above,
because they didn't make sense to me)

[12] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021007.html

I've made up a patch along these lines [13]; it's easy to use a timestamp
rather than a block height, so I've arbitrarily picked 1st May (slightly
over 6 months away) as the changeover time. If people are willing to
give zeroconf businesses some time to adapt, including something along
those lines in 24.0 seems a better approach to me:

 * it gives a clear deadline for businesses to adapt, so that they don't
   defer it and suddenly complain "oh no, we didn't think you were
   serious, please give us more time" later

 * it gives plenty(?) of time to update your code and test it, as well
   as teach customers and customer support about the new behaviour

 * when the deadline hits, presumably plenty of nodes and miners will
   immediately start supporting the new behaviour on mainnet, so that
   protocols can quickly start relying on that method of tx pinning no
   longer being applicable

 * nodes on signet and testnet will quickly adopt the new behaviour,
   well before it's available on mainnet, making testing easier

[13] https://github.com/bitcoin/bitcoin/pull/26323

To me, this seems like a good way of achieving what I said previously:

> If we're trying to socialise the idea that zeroconf deprecation is
> happening and that your business now has a real deadline for migrating
> away from accepting unconfirmed txs if the risk of being defrauded
> concerns you, then enabling experimentation on test nets and not touching
> mainnet until a later release seems fairly fine to me -- similar to
> activating soft forks on test nets prior to activating it on mainnet.

Cheers,
aj

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

[Peter Todd]

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

On Fri, Oct 14, 2022 at 02:44:04AM +0000, alicexbt via bitcoin-dev wrote:
> > Relay of fullrbf transactions works reasonable well
> > already, unless you get unlucky with your selected peers. The only
> > missing piece is a few percent of hashrate that will accept fullrbf
> > replacement transactions. 
> 
> I don't believe relay of fullrbf transactions works well right now. The missing piece you mentioned is important and a real need for all full node users to try fullrbf.

Relay of full-rbf transactions works well right now precisely because a few
implementations exist of preferential rbf peering. I'm personally running four
nodes with it enabled, two using my own custom patches, and another two using
ariad's patch:

https://github.com/bitcoin/bitcoin/pull/25600

I haven't seen a lot of non-opt-in doublespends get mined. But I have seen a
few now via my Alice OTS calendar. This can of course increase dramatically as
miners turn on full-rbf.

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

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

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

[alicexbt]

Hi cndm1,

> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.

Lightning is only used for 4% payments compared to 32% on-chain payments according to a [tweet][1] from Jan 2022 by Sergej Kotliar and stats are similar based on the slides shared in a [presentation][2] in Pizza Day Prague 2022.

By EUR:

onchain - 30%
lightning - 5%

By unique users:

onchain - 40%
lightning - 9%

> Relay of fullrbf transactions works reasonable well
> already, unless you get unlucky with your selected peers. The only
> missing piece is a few percent of hashrate that will accept fullrbf
> replacement transactions. 

I don't believe relay of fullrbf transactions works well right now. The missing piece you mentioned is important and a real need for all full node users to try fullrbf.

> While this will certainly happen if a
> Bitcoin Core release ships with the flag on by default, it still may
> happen at any time even if Bitcoin Core doesn't ship with the flag at
> all.

Changing default at this moment does not make sense as v24.0 could give some insights about usage of fullrbf and we could wait for a few months before changing default for users that run latest version of bitcoin core.

I will quote Antoine Riard's comment from PR [#25353][3]:

"_I know I've advocated in the past to turn RBF support by default in the past. Though after gathering a lot of feedbacks, this approach of offering the policy flexiblity to the interested users only and favoring a full-rbf gradual deployment sounds better to me. As a follow-up, if we add p2p logic to connect to few "full-rbf" service-bit signaling peers and recommend to the ~17000 LN nodes operators, likely (hopefully!) running bitcoind as a backend, that should be okay to guarantee a good propagation to miners (and yes reaching out to few mining pools ops to explain the income increase brought by full-rbf). Unless we observe a significant impact on compact blocks reconstruction, personally I'm really fine waiting another multi-years development cycle before to propose a default change, or even let opt-in forever the default as it is._"

"_Once again, the proposed change is only targeting educated users aiming to deploy full RBF for their application specific needs. If the majority of Bitcoin users is not interested, that's okay. It's a policy rule, not a consensus one._"

Although Antoine has opened another [pull request][4] to make fullrbf default a few hours ago, so I am not sure what is the new motivation or discussion that I am missing.

[1]: https://twitter.com/ziggamon/status/1481307334068641795
[2]: https://youtu.be/bkjEcSmZKfc?t=463
[3]: https://github.com/bitcoin/bitcoin/pull/25353
[4]: https://github.com/bitcoin/bitcoin/pull/26305

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, October 13th, 2022 at 9:37 PM, linuxfoundation.cndm1--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> > - Bitrefill's on-chain payments for gift cards and phone top-ups
> 
> 
> Bitrefill already supports lightning, so for them it would be easy to
> solve by displaying the lightning transfer by default and only show
> the on-chain payment as a fallback. Currently the on-chain payment at
> Bitrefill and other similar providers is really a drop-down where you
> select your wallet and then they display a tutorial to you on how to
> create the on-chain transaction (fee rate, RBF flag, etc). I don't
> have insights into Bitrefill, but one might suspect that encouraging a
> lightning payment might be a win-win situation for them and their
> users.
> 
> It would be interesting to know if there are any obstacles that
> Bitrefill and other services face, or if they don't agree that
> lightning is an improvement over accepting unconfirmed on-chain
> transactions from untrusted parties.
> 
> > - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least
> 
> 
> I haven't tried them yet, but I suspect they could benefit in a
> similar by showing lightning transfers more prominently. Moreover, any
> UX improvement they can offer to users that intentionally or
> accidentally selected RBF opt-in, will also benefit users once fullrbf
> is widespread. To give an example, ATMs could immediately give out a
> voucher for the cash amount that can be redeemed as soon as the
> transaction is confirmed on-chain, to allow (untrusted) users to leave
> the ATM and go for a walk in the meantime.
> 
> > With full-RBF, wallets should make it extremely clear to users that unconfirmed
> > funds are not theirs (yet). Otherwise, protocol-unaware users that are
> > transacting on-chain with untrusted parties can be easily scammed if they don't
> > know they have to wait for a confirmation. Eg. in Argentina, it's pretty common
> > to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
> 
> 
> This is easy to solve, because a wallet can simply display all
> unconfirmed transactions as if they signalled for RBF. Your suggested
> solution to "activate" fullrbf at a specific block height might be
> counter productive, because educating users that unconfirmed
> transactions are unsafe takes longer than a single block. So the
> earlier users are educated that unconfirmed transactions from
> untrusted parties are unsafe, the better.
> 
> > # Impact at Muun
> > 
> > Work to transition Muun from using zero-conf submarine swaps to using payment
> > channels is ongoing, but we are still several months away from being production
> > ready. This means we would have to turn off outgoing lightning payments for
> > +100k monthly active users, which is a good chunk of all users making
> > non-custodial lightning payments today.
> 
> 
> It would be unfortunate for those users, but I think that the risk
> exists today. Relay of fullrbf transactions works reasonable well
> already, unless you get unlucky with your selected peers. The only
> missing piece is a few percent of hashrate that will accept fullrbf
> replacement transactions. While this will certainly happen if a
> Bitcoin Core release ships with the flag on by default, it still may
> happen at any time even if Bitcoin Core doesn't ship with the flag at
> all.
> 
> Best,
> cndm1
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[linuxfoundation.cndm1]

> - Bitrefill's on-chain payments for gift cards and phone top-ups

Bitrefill already supports lightning, so for them it would be easy to
solve by displaying the lightning transfer by default and only show
the on-chain payment as a fallback. Currently the on-chain payment at
Bitrefill and other similar providers is really a drop-down where you
select your wallet and then they display a tutorial to you on how to
create the on-chain transaction (fee rate, RBF flag, etc). I don't
have insights into Bitrefill, but one might suspect that encouraging a
lightning payment might be a win-win situation for them and their
users.

It would be interesting to know if there are any obstacles that
Bitrefill and other services face, or if they don't agree that
lightning is an improvement over accepting unconfirmed on-chain
transactions from untrusted parties.

> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least

I haven't tried them yet, but I suspect they could benefit in a
similar by showing lightning transfers more prominently. Moreover, any
UX improvement they can offer to users that intentionally or
accidentally selected RBF opt-in, will also benefit users once fullrbf
is widespread. To give an example, ATMs could immediately give out a
voucher for the cash amount that can be redeemed as soon as the
transaction is confirmed on-chain, to allow (untrusted) users to leave
the ATM and go for a walk in the meantime.

> With full-RBF, wallets should make it extremely clear to users that unconfirmed
> funds are not theirs (yet). Otherwise, protocol-unaware users that are
> transacting on-chain with untrusted parties can be easily scammed if they don't
> know they have to wait for a confirmation. Eg. in Argentina, it's pretty common
> to meet someone in person to buy bitcoin P2P for cash, even for newcomers.

This is easy to solve, because a wallet can simply display all
unconfirmed transactions as if they signalled for RBF. Your suggested
solution to "activate" fullrbf at a specific block height might be
counter productive, because educating users that unconfirmed
transactions are unsafe takes longer than a single block. So the
earlier users are educated that unconfirmed transactions from
untrusted parties are unsafe, the better.

> # Impact at Muun
>
> Work to transition Muun from using zero-conf submarine swaps to using payment
> channels is ongoing, but we are still several months away from being production
> ready. This means we would have to turn off outgoing lightning payments for
> +100k monthly active users, which is a good chunk of all users making
> non-custodial lightning payments today.

It would be unfortunate for those users, but I think that the risk
exists today. Relay of fullrbf transactions works reasonable well
already, unless you get unlucky with your selected peers. The only
missing piece is a few percent of hashrate that will accept fullrbf
replacement transactions. While this will certainly happen if a
Bitcoin Core release ships with the flag *on* by default, it still may
happen at any time even if Bitcoin Core doesn't ship with the flag at
all.

Best,
cndm1

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

[Anthony Towns]

On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
> In my view, it is just what I said: a step towards getting full RBF
> on the network, by allowing experimentation and socializing the notion
> that developers believe it is time.

We "believe it is time" for what exactly, though? (a) To start
deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
18 months; or (b) to start switching mainnet mining and relay nodes over
to full RBF?

As far as experimentation goes, I don't really see this option as being
very likely to help: the default for this option is still false, so it's
likely going to be difficult to get non-opt-in RBF txs relayed or mined
anywhere, even on testnet or signet, no? (Maybe that's a difficulty that's
resolved by an addnode, but it's still a difficulty) If experimentation's
the goal, making the default be true for testnet/signet at least seems
like it would be pretty useful at least. Meaningful experimentation is
probably kind of difficult in the first place while fees are low and
there's often no backlog in the mempool, as well; something that perhaps
applies more to test nets than mainnet even.

If we're trying to socialise the idea that zeroconf deprecation is
happening and that your business now has a real deadline for migrating
away from accepting unconfirmed txs if the risk of being defrauded
concerns you, then enabling experimentation on test nets and not touching
mainnet until a later release seems fairly fine to me -- similar to
activating soft forks on test nets prior to activating it on mainnet.

> So I have a hard time imagining how it
> would change anything *immediately* on the network at large (without
> things like default on and/or preferential peering, ...), but I still
> believe it's an important step.

If we're instead trying to socialise the idea that relaying and mining
full RBF txs on mainnet should be starting now, then I think that's
exactly how this *would* change things almost immediately on the network
at large.

I think all it would take in practice to be able to repeatedly defraud
businesses accepting unconfirmed txs is perhaps 5% or 10% of blocks
to include full RBF txs [0] [1], and knowing some IP addresses to
addnode so that your txs relayed to those miners. And if core devs are
advocating that full RBF is ready now [2], and a patch to easily enable
it is included in a bitcoin core release, why wouldn't some small pools
start trying it out, leading to exactly that situation?

If most of the network doesn't relay your full-rbf txs, then that's
annoying for protocol developers who'd like to rely on it, but it's fine
for an attacker: it just means the business you're trying to trick has
less chance of noticing the attack before it's too late, because they'll
be less likely to see the conflicting tx via both their own node or
public explorers.

Cheers,
aj

[0] A few months ago, Peter Todd reported switching an OTS calendar to do
    non-opt-in RBF, and didn't observe bumped txs being mined, which seems
    to indicate there's not much hash power currently mining full RBF.
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html

[1] Also why I remain surprised that accepting zeroconf is safe enough
    in practice for anyone to do it. I suppose 5% of hashpower is perhaps
    $100M+ investment in ASICs and $900k/day in revenue, and perhaps
    all the current ways of enabling full RBF are considered too risky
    to mess around with at that level.

[2] Antoine Riard's mail from June (that Peter's mail above was in reply
    to) announced such a public node, and encouraged miners to start
    adoption: "If you're a mining operator looking to increase your
    income, you might be interested to experiment with full-rbf
    as a policy." Presuming the IRC channel "##uafrbf" stands
    for "user-activated full rbf", that also seems in line with
    the goal being to socialise doing full RBF on mainnet immediately...
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html

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

[Dario Sneidermanis]

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

Hello Pieter,

Thanks for taking the time to comment! I'll answer inline.

On Wed, Oct 12, 2022 at 2:51 PM Pieter Wuille <bitcoin-dev@wuille.net>
wrote:
> I certainly recognize that adding the flag is a likely step towards, over
> time, the full RBF policy becoming more widely adopted on the network.
That is
> presumably the reason why people are in favor of having the flag, even
default
> off - including me. I believe that policy's adoption is inevitable
eventually,
> but the speed at which that is achieved is certainly a function of
> availability and adopted of software which provides the option.

As stated in the original posting, I believe too that a full-RBF network is
not
only inevitable but also desirable. Miner incentives will eventually win,
so we
should address them before they fully kick in (ie. before transaction fees
become a meaningful portion of the block reward).

> So I have a hard time imagining how it would change anything
*immediately* on
> the network at large (without things like default on and/or preferential
> peering, ...), but I still believe it's an important step.

Notice that I'm not saying this changes anything immediately on the network
at
large. In fact, it is unlikely that the opt-in flag alone would be enough to
migrate the network at large to full-RBF.

There's a real possibility that, after deployment of the opt-in flag,
either no
meaningful hashing power adopts it or no connected component of
transaction-relaying nodes adopts it. If that's the case, the deployment
won't
help nodes participating in multi-party funded transactions protect against
the
class of attacks described in [1] (which was, as I understand, the original
intention of #25353).

If that's not the case, it means that at least some meaningful hashing power
adopted it and that there exist some connected components of
transaction-relaying nodes that adopted it. This is certainly far from
having
wide adoption of full-RBF in the network at large. However, once we reach
that
minimal level of adoption in the mining and relaying layers, any node on a
full-RBF connected component can send an on-chain payment to an application
and
then get a replacement mined. That is, applications that accept incoming
on-chain payments from untrusted parties can be immediately exposed to
full-RBF
transaction replacements, even if they didn't opt into full-RBF in their
nodes.

In an adversarial setting, such as the one for zero-conf applications (as
defined in the original posting), this increases the risk of an attack
substantially, making the entire strategy moot.

> In my view, it is just what I said: a step towards getting full RBF on the
> network, by allowing experimentation and socializing the notion that
> developers believe it is time.

Those are worthy goals. I believe we can design a deployment strategy for
full-RBF that takes them into account and, at the same time, gives a clear
timeline for any affected application to adapt.

This could be one such proposal:

1. We activate opt-in full-RBF on testnet now.
2. We commit now (in the code) to a block height in the future at which
opt-out
   full-RBF will activate on mainnet.

The first point will allow for experimentation and give a testing ground to
all
affected applications. The second point socializes the notion that
developers
believe it is time, giving a clear message and timeline for anyone affected
to
adapt. It also has the benefit that many more nodes will have upgraded by
the
time we reach the activation block height, making the transition to a
full-RBF
network much more predictable and easy to reason about.

There's an argument to be made that the miner incentive incompatibility
problem
of a non-full-RBF network gets measurably worse at the time of the next
halving.
To fix this, we could choose any block height before that, giving a clear
and
predictable transition timeline.

[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html

On Wed, Oct 12, 2022 at 1:11 PM Pieter Wuille <bitcoin-dev@wuille.net>
wrote:

> On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <
> aj@erisian.com.au> wrote:
>
> > On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev
> wrote:
> >
> > > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via
> bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > >
> > > > Thanks for the fast answer! It seems I missed the link to the PR,
> sorry for the
> > > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > > It is not clear to me why you believe the merging of this particular
> pull request poses an immediate risk to you.
> >
> >
> > Did you see the rest of Dario's reply, bottom-posted after the quoted
> > text? Namely:
>
> Oh, my mail client for some reason chose to hide all that. Dario, I'm
> sorry for missing this; I see now that you were certainly aware of what the
> PR under consideration did.
>
> Further comments inline.
>
> > On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via
>
> > > The question then is whether an opt-in flag for full-RBF will have
> enough
> > > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > > objective of allowing nodes participating in multi-party funding
> protocols
> > > to assume that they can rely on full-RBF. If it is, then zero-conf
> applications
> > > will be at severe risk (per the logic in the initial email).
>
> >
> >
> > That logic seems reasonably sound to me:
> >
> > - if adding the option does nothing, then there's no point adding it,
> > and no harm in restricting it to test nets only
> >
> > - if adding the option does do something, then businesses using zero-conf
> > need to react immediately, or will go from approximately zero risk of
> > losing funds, to substantial risk
> >
> > (I guess having the option today may allow you to manually switch your
> > node over to supporting fullrbf in future when the majority of the
> network
> > supports it, without needing to do an additional upgrade in the meantime;
> > but that seems like a pretty weak benefit)
>
> I certainly recognize that adding the flag is a likely step towards, over
> time, the full RBF policy becoming more widely adopted on the network. That
> is presumably the reason why people are in favor of having the flag, even
> default off - including me. I believe that policy's adoption is inevitable
> eventually, but the speed at which that is achieved is certainly a function
> of availability and adopted of software which provides the option.
>
> That said, I think it's a bit of a jump to conclude that the only two
> options are that either the existence of the flag either has no effect at
> all, or poses an immediate threat to those relying on its absence. In my
> view, it is just what I said: a step towards getting full RBF on the
> network, by allowing experimentation and socializing the notion that
> developers believe it is time. So I have a hard time imagining how it would
> change anything *immediately* on the network at large (without things like
> default on and/or preferential peering, ...), but I still believe it's an
> important step.
>
> Cheers,
>
> --
> Pieter
>
>

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

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

[Pieter Wuille]

On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <aj@erisian.com.au> wrote:

> On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
> 
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > 
> > > Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.
> 
> 
> Did you see the rest of Dario's reply, bottom-posted after the quoted
> text? Namely:

Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry for missing this; I see now that you were certainly aware of what the PR under consideration did.

Further comments inline.

> On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via

> > The question then is whether an opt-in flag for full-RBF will have enough
> > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > objective of allowing nodes participating in multi-party funding protocols
> > to assume that they can rely on full-RBF. If it is, then zero-conf applications
> > will be at severe risk (per the logic in the initial email).

> 
> 
> That logic seems reasonably sound to me:
> 
> - if adding the option does nothing, then there's no point adding it,
> and no harm in restricting it to test nets only
> 
> - if adding the option does do something, then businesses using zero-conf
> need to react immediately, or will go from approximately zero risk of
> losing funds, to substantial risk
> 
> (I guess having the option today may allow you to manually switch your
> node over to supporting fullrbf in future when the majority of the network
> supports it, without needing to do an additional upgrade in the meantime;
> but that seems like a pretty weak benefit)

I certainly recognize that adding the flag is a likely step towards, over time, the full RBF policy becoming more widely adopted on the network. That is presumably the reason why people are in favor of having the flag, even default off - including me. I believe that policy's adoption is inevitable eventually, but the speed at which that is achieved is certainly a function of availability and adopted of software which provides the option.

That said, I think it's a bit of a jump to conclude that the only two options are that either the existence of the flag either has no effect at all, or poses an immediate threat to those relying on its absence. In my view, it is just what I said: a step towards getting full RBF on the network, by allowing experimentation and socializing the notion that developers believe it is time. So I have a hard time imagining how it would change anything *immediately* on the network at large (without things like default on and/or preferential peering, ...), but I still believe it's an important step.

Cheers,

-- 
Pieter

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

[Anthony Towns]

On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
> On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > (https://github.com/bitcoin/bitcoin/pull/25353).
> It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.

Did you see the rest of Dario's reply, bottom-posted after the quoted
text? Namely:

On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via bitcoin-dev wrote:
> The "activation" of full-RBF after deployment works in a pretty interesting
> way:
> 
> 1. If no miner is running full-RBF or there aren't easily accessible
> connected components of nodes running full-RBF connected to the miners, then
> full-RBF is mostly ineffective since replacements aren't relayed and/or mined.
> 2. There's a middle ground where *some* connected components of full-RBF
>    nodes can relay and mine replacements, where some full-RBF nodes will be
>    able to replace via full-RBF and some won't (depending on their peers).
> 3. With high enough adoption, the relay graph has enough density of full-RBF
>    nodes that almost all full-RBF nodes can replace transactions via
>    full-RBF.
> 
> While there have been forks of Bitcoin Core (like Bitcoin Knots) running
> full-RBF for a while, today most nodes (by far) are running Bitcoin Core.
> So,
> Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to
> be
> picked up by most node operators. Making the flag opt-out (ie. on by
> default)
> would make it easier still. We are dealing with a gradient going from hard
> enough that we are still in 1, to easy enough that we get to 3.
> 
> The question then is whether an opt-in flag for full-RBF will have enough
> adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> objective of allowing nodes participating in multi-party funding protocols
> to assume that they can rely on full-RBF. If it is, then zero-conf applications
> will be at severe risk (per the logic in the initial email).

That logic seems reasonably sound to me:

 - if adding the option does nothing, then there's no point adding it,
   and no harm in restricting it to test nets only

 - if adding the option does do something, then businesses using zero-conf
   need to react immediately, or will go from approximately zero risk of
   losing funds, to substantial risk

(I guess having the option today may allow you to manually switch your
node over to supporting fullrbf in future when the majority of the network
supports it, without needing to do an additional upgrade in the meantime;
but that seems like a pretty weak benefit)

Cheers,
aj

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

[Pieter Wuille]

On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Hello David,
> 
> Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> confusion. I'm referring to the opt-in flag for full-RBF from #25353
> (https://github.com/bitcoin/bitcoin/pull/25353).

Hello Dario,

It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.

As explained by others, it's only a configuration option that is default off, and the possibility of running rull-RBF policy nodes on the network have been trivial for anyone who wanted to for a long time on the network.

I don't want to sound dismissive of your concerns, but at this point I'm not convinced you're actually aware of what this PR does and doesn't do.

Cheers,

-- 
Pieter

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

[alicexbt]

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

Hi Dario,

There aren't any risks with latest release of bitcoin core. However its not just munn or other things mentioned, even other bitcoin projects could be affected if [#25600][1] is merged.

Anyway I cannot comment anymore, neither in the PR or repository. I tried my best. Peter Todd has ACKed it and it would affect his favorite coinjoin implementation that works with governments.

Replacement policies are a per-node decision as Luke Dashjr said and projects should build upon it.

[1]: https://github.com/bitcoin/bitcoin/pull/25600

/dev/fd0

Sent with [Proton Mail](https://proton.me/) secure email.

------- Original Message -------
On Friday, October 7th, 2022 at 9:50 PM, Dario Sneidermanis via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello list,
>
> I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the past
> few days we've been reviewing the latest bitcoin core release candidate, and we
> found some troubling facts related to the opt-in full-RBF deployment.
>
> We first learned about the opt-in full-RBF proposal last June when it was
> announced on the mailing list. Closing the gap between the protocol's relay
> policies and the miner incentives is inevitable, so it was a welcomed addition.
> Furthermore, allowing transaction replacements that remove the opt-in RBF flag
> was deeply problematic.
>
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun to
> the new policies. However, when reviewing the 24.0 release candidate just a few
> days ago, we realized that zero-conf apps (like Muun) must *immediately turn
> off* their zero-conf features.
>
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can delay the
> opt-in deployment and find a safer way to deploy full-RBF?
>
> It'd be great for this deployment to be a success so that we can continue fixing
> the remaining relay policy problems, such as package relay and the RBF rules.
> Maybe we could go straight to an opt-out deployment locked by code at a certain
> height in the future to give time to everyone and, at the same time, avoid a
> huge mempool divergence event?
>
> Below is our analysis of how zero-conf apps break with opt-in full-RBF. I hope
> it helps.
>
> Cheers,
> Dario
>
> # How do zero-conf apps work
>
> While the workings and trade-offs of zero-conf applications might be known by
> many in this list, it's useful to define precisely how they work to understand
> how they break.
>
> We call zero-conf applications to entities that accept on-chain payments from
> *untrusted parties* and will sometimes deliver the paid-for product or service
> without waiting for the transaction to be included in a block.
>
> Some examples of zero-conf apps:
>
> - Muun's submarine swaps for outgoing lightning payments
> - Bitrefill's on-chain payments for gift cards and phone top-ups
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least
> the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
> General Byte)
>
> All of these applications are receiving incoming on-chain transactions for which
> they don't control the inputs, and performing a risk analysis to decide whether
> they are ok with accepting the payment without confirmation.
>
> In practice, this works because once the bitcoin P2P network has fully
> propagated a non-RBF transaction, you need the collaboration of a miner to
> replace it, which isn't easy to get today. Even though many of the biggest
> miners offer off-band transaction broadcasting services, they currently won't
> process conflicting transactions.
>
> Roughly, the risk analysis goes like this:
>
> 1. if an incoming transaction is RBF (direct or inherited)
> --> too risky, wait for 1 conf (or more) since it can be replaced at any time
> 2. if the payment is for an amount greater than X
> --> too risky, wait for 1 conf (or more), since the amount is worthy of a
> sophisticated attacker
> 3. wait for full(ish) propagation of the incoming transaction
> 4. if there's no double-spend attempt
> --> accept 0-conf
>
> As with any other risk analysis, there's always a false-negative detection rate,
> leading to an expected loss, which the zero-conf app should be willing to bear.
> Notice that the expected loss is tunable via the amount X in the above analysis.
>
> # Why are zero-conf apps not protected with an opt-in deployment
>
> Full-RBF adoption works on three different layers:
>
> - The transaction application layer
> - The transaction relaying layer
> - The transaction mining layer
>
> If an application wants to replace with full-RBF an *outgoing* transaction, it
> will need:
>
> - An upgraded node that opted into full-RBF, from which it can broadcast the
> replacement transaction
> - A connected component of upgraded nodes that opted into full-RBF, that can
> relay the replacement transaction
> - A miner in that connected component with an upgraded node that opted into
> full-RBF, that can mine the replacement transaction
>
> However, an application cannot control whether a replacement to an *incoming*
> transaction is relayed via full-RBF. As soon as a single application can
> generate replacements easily via full-RBF, all other applications have to assume
> that any incoming transaction from an untrusted party might be replaced via
> full-RBF. That is, for the application layer this is a forced upgrade.
>
> As soon as an unsophisticated attacker can use opt-in full-RBF, the risk
> analysis performed by zero-conf applications stops working because the
> transactions to analyze are all incoming transactions from untrusted parties.
> Since some wallets already implement cancel functionality for opt-in RBF
> transactions, enabling the same functionality for every transaction wouldn't
> require much work, making canceling any unconfirmed transaction a one-click
> experience. After this, the security model of zero-conf applications goes from
> "susceptible to attacks from miners" to "anyone can perform an attack, with an
> easy-to-use interface".
>
> That is, the opt-in deployment of full-RBF doesn't protect zero-conf
> applications from having to turn off their zero-conf features very soon after
> the initial deployment. All mitigations are mostly ineffective against
> untrusted parties.
>
> # Other things we have to fix
>
> While it's clear how full-RBF breaks zero-conf applications, other more subtle
> things break in *many* wallets (Muun included). If given the opportunity, we
> would like to fix them before deployment. One could argue that these things
> were already broken, but they get considerably worse as the network adopts
> full-RBF (even with an opt-in deployment), so we should fix them.
>
> ## Mental model for unconfirmed incoming transactions
>
> Many wallets with support for on-chain payments (Muun included) show incoming
> external transactions in some way to their users before they confirm. This is a
> common practice because not showing them leads users to worry that their money
> disappeared (exchanges doing this is the #1 issue we have to deal with in our
> customer support channels).
>
> With full-RBF, wallets should make it extremely clear to users that unconfirmed
> funds are not theirs (yet). Otherwise, protocol-unaware users that are
> transacting on-chain with untrusted parties can be easily scammed if they don't
> know they have to wait for a confirmation. Eg. in Argentina, it's pretty common
> to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
>
> ## Block explorers as payment receipts
>
> Most wallets with support for on-chain payments (Muun included) use the
> transaction view of a block explorer as a shareable payment receipt. The sender
> of an on-chain transaction usually shares this link with the receiver to let
> them know they made a payment. Protocol-unaware receivers sometimes take this
> link as proof of payment.
>
> Most explorers currently don't track payment replacements and, more importantly,
> don't warn users that unconfirmed funds are not theirs (yet). With full-RBF,
> wallets should either stop relying on explorers for this functionality or wait
> for them to support it explicitly.
>
> # Impact at Muun
>
> Work to transition Muun from using zero-conf submarine swaps to using payment
> channels is ongoing, but we are still several months away from being production
> ready. This means we would have to turn off outgoing lightning payments for
> +100k monthly active users, which is a good chunk of all users making
> non-custodial lightning payments today.
>
> Furthermore, the more subtle fixes imply non-trivial amounts of product work
> that we cannot reasonably deploy before they start affecting users.
>
> While I cannot talk for other applications, there are many impacted in one way
> or another, and none of the ones I checked with were aware of this change, or
> its implications.

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

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

[Dario Sneidermanis]

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

Hello David,

Thanks for the fast answer! It seems I missed the link to the PR, sorry for
the
confusion. I'm referring to the opt-in flag for full-RBF from #25353
(https://github.com/bitcoin/bitcoin/pull/25353).

On Fri, Oct 7, 2022 at 2:21 PM David A. Harding <dave@dtrt.org> wrote:

> On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> > Hello list,
> >
> > I'm Dario, from Muun wallet [...] we've been reviewing the latest
> > bitcoin core release
> > candidate [...] we understood we had at least a year from the initial
> > opt-in  deployment until opt-out was deployed, giving us enough time to
> > adapt
> > Muun to the new policies. However, when reviewing the 24.0 release
> > candidate
> > just a few  days ago, we realized that zero-conf apps (like Muun) must
> > *immediately turn off* their zero-conf features.
>
> Hi Dario,
>
> I'm wondering if there's been some confusion.  There are two RBF-related
> items in the current release notes draft:[1]
>
> 1. "A new mempoolfullrbf option has been added, which enables the
> mempool to accept transaction replacement without enforcing BIP125
> replaceability signaling. (#25353)"
>
> 2. "The -walletrbf startup option will now default to true. The wallet
> will now default to opt-in RBF on transactions that it creates.
> (#25610)"
>
> The first item (from PR #25353) does allow a transaction without a
> BIP125 signal to be replaced, but this configuration option is set to
> disabled by default.[2]  There have been software forks of Bitcoin Core
> since at least 2015 which have allowed replacement of non-signaling
> transactions, so this option just makes that behavior a little bit more
> accessible to users of Bitcoin Core.


The "activation" of full-RBF after deployment works in a pretty interesting
way:

1. If no miner is running full-RBF or there aren't easily accessible
connected
   components of nodes running full-RBF connected to the miners, then
full-RBF
   is mostly ineffective since replacements aren't relayed and/or mined.
2. There's a middle ground where *some* connected components of full-RBF
nodes
   can relay and mine replacements, where some full-RBF nodes will be able
to
   replace via full-RBF and some won't (depending on their peers).
3. With high enough adoption, the relay graph has enough density of full-RBF
   nodes that almost all full-RBF nodes can replace transactions via
full-RBF.

While there have been forks of Bitcoin Core (like Bitcoin Knots) running
full-RBF for a while, today most nodes (by far) are running Bitcoin Core.
So,
Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to
be
picked up by most node operators. Making the flag opt-out (ie. on by
default)
would make it easier still. We are dealing with a gradient going from hard
enough that we are still in 1, to easy enough that we get to 3.

The question then is whether an opt-in flag for full-RBF will have enough
adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
objective of allowing nodes participating in multi-party funding protocols
to
assume that they can rely on full-RBF. If it is, then zero-conf applications
will be at severe risk (per the logic in the initial email).

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

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

[Luke Dashjr]

On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote:
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to the new policies.

Policies are a per-node decision, and cannot be relied on in general.
Full RBF has been the default in Bitcoin Knots for years, and de facto viable 
for use on the network even longer.

> However, when reviewing the 24.0 release candidate just 
> a few days ago, we realized that zero-conf apps (like Muun) must
> *immediately turn off* their zero-conf features.

RBF deals with UNconfirmed transactions, not zero-confirmed (Lightning).

> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can delay
> the opt-in deployment and find a safer way to deploy full-RBF?

Full RBF has been available for users on an opt-in basis since at least 2013, 
long before BIP 125 was even conceived of.

> We call zero-conf applications to entities that accept on-chain payments
> from
> *untrusted parties* and will sometimes deliver the paid-for product or
> service
> without waiting for the transaction to be included in a block.

This is unsafe period. RBF does not make it any less unsafe.

> All of these applications are receiving incoming on-chain transactions for
> which
> they don't control the inputs, and performing a risk analysis to decide
> whether
> they are ok with accepting the payment without confirmation.

This is nothing but a false sense of security.

Luke

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

[Greg Sanders]

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

David, Dario,

The only other effort I'm aware of is
https://github.com/bitcoin/bitcoin/pull/25600 , which as you can see, has
no consensus yet, isn't in 24.0, so at earliest would be 25.0, even if
somehow immediate resolution to the discussions were found.

Cheers,
Greg

On Fri, Oct 7, 2022 at 1:21 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> > Hello list,
> >
> > I'm Dario, from Muun wallet [...] we've been reviewing the latest
> > bitcoin core release
> > candidate [...] we understood we had at least a year from the initial
> > opt-in  deployment until opt-out was deployed, giving us enough time to
> > adapt
> > Muun to the new policies. However, when reviewing the 24.0 release
> > candidate
> > just a few  days ago, we realized that zero-conf apps (like Muun) must
> > *immediately turn off* their zero-conf features.
>
> Hi Dario,
>
> I'm wondering if there's been some confusion.  There are two RBF-related
> items in the current release notes draft:[1]
>
> 1. "A new mempoolfullrbf option has been added, which enables the
> mempool to accept transaction replacement without enforcing BIP125
> replaceability signaling. (#25353)"
>
> 2. "The -walletrbf startup option will now default to true. The wallet
> will now default to opt-in RBF on transactions that it creates.
> (#25610)"
>
> The first item (from PR #25353) does allow a transaction without a
> BIP125 signal to be replaced, but this configuration option is set to
> disabled by default.[2]  There have been software forks of Bitcoin Core
> since at least 2015 which have allowed replacement of non-signaling
> transactions, so this option just makes that behavior a little bit more
> accessible to users of Bitcoin Core.  Some developers have announced
> their intention to propose enabling this option by default in a future
> release, which I think is the behavior you're concerned about, but
> that's not planned for the release of 24.0 to the best of my knowledge.
>
> The second item (from PR #25610) only affects Bitcoin Core's wallet, and
> in particular transactions created with it through the RPC interface.
> Those transactions will now default to signaling BIP125 replacability.
> This option has been default false for many years for the RPC, but for
> the GUI it's been default true since Bitcoin Core 0.16, released in
> early 2018[3].  It's no different than another popular wallet beginning
> to signal BIP125 support by default.
>
> In short, I don't think anything in Bitcoin Core 24.0 RC1 significantly
> changes the current situation related to transaction replacability.  All
> it does is give Bitcoin Core RPC users by default the same settings long
> used for GUI users and introduce an option that those who object to
> non-signalled RBF will later be able to use to disable their relay of
> non-signalled replacements.
>
> Does the above information resolve your concerns?
>
> Thanks,
>
> -Dave
>
> [1]
>
> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft
>
> [2] $ bin/bitcoind -help | grep -A3 mempoolfullrbf
>    -mempoolfullrbf
>         Accept transaction replace-by-fee without requiring
> replaceability
>         signaling (default: 0)
>
> [3]
>
> https://bitcoincore.org/en/2018/02/26/release-0.16.0/#replace-by-fee-by-default-in-gui
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[David A. Harding]

On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> Hello list,
> 
> I'm Dario, from Muun wallet [...] we've been reviewing the latest 
> bitcoin core release
> candidate [...] we understood we had at least a year from the initial
> opt-in  deployment until opt-out was deployed, giving us enough time to 
> adapt
> Muun to the new policies. However, when reviewing the 24.0 release 
> candidate
> just a few  days ago, we realized that zero-conf apps (like Muun) must
> *immediately turn off* their zero-conf features.

Hi Dario,

I'm wondering if there's been some confusion.  There are two RBF-related 
items in the current release notes draft:[1]

1. "A new mempoolfullrbf option has been added, which enables the 
mempool to accept transaction replacement without enforcing BIP125 
replaceability signaling. (#25353)"

2. "The -walletrbf startup option will now default to true. The wallet 
will now default to opt-in RBF on transactions that it creates. 
(#25610)"

The first item (from PR #25353) does allow a transaction without a 
BIP125 signal to be replaced, but this configuration option is set to 
disabled by default.[2]  There have been software forks of Bitcoin Core 
since at least 2015 which have allowed replacement of non-signaling 
transactions, so this option just makes that behavior a little bit more 
accessible to users of Bitcoin Core.  Some developers have announced 
their intention to propose enabling this option by default in a future 
release, which I think is the behavior you're concerned about, but 
that's not planned for the release of 24.0 to the best of my knowledge.

The second item (from PR #25610) only affects Bitcoin Core's wallet, and 
in particular transactions created with it through the RPC interface.  
Those transactions will now default to signaling BIP125 replacability.  
This option has been default false for many years for the RPC, but for 
the GUI it's been default true since Bitcoin Core 0.16, released in 
early 2018[3].  It's no different than another popular wallet beginning 
to signal BIP125 support by default.

In short, I don't think anything in Bitcoin Core 24.0 RC1 significantly 
changes the current situation related to transaction replacability.  All 
it does is give Bitcoin Core RPC users by default the same settings long 
used for GUI users and introduce an option that those who object to 
non-signalled RBF will later be able to use to disable their relay of 
non-signalled replacements.

Does the above information resolve your concerns?

Thanks,

-Dave

[1] 
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Notes-draft

[2] $ bin/bitcoind -help | grep -A3 mempoolfullrbf
   -mempoolfullrbf
        Accept transaction replace-by-fee without requiring 
replaceability
        signaling (default: 0)

[3] 
https://bitcoincore.org/en/2018/02/26/release-0.16.0/#replace-by-fee-by-default-in-gui

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

[Dario Sneidermanis]

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

Hello list,

I'm Dario, from Muun wallet, a mobile non-custodial bitcoin wallet. For the
past
few days we've been reviewing the latest bitcoin core release candidate,
and we
found some troubling facts related to the opt-in full-RBF deployment.

We first learned about the opt-in full-RBF proposal last June when it was
announced on the mailing list. Closing the gap between the protocol's relay
policies and the miner incentives is inevitable, so it was a welcomed
addition.
Furthermore, allowing transaction replacements that remove the opt-in RBF
flag
was deeply problematic.

At the time, we understood we had at least a year from the initial opt-in
deployment until opt-out was deployed, giving us enough time to adapt Muun
to
the new policies. However, when reviewing the 24.0 release candidate just a
few
days ago, we realized that zero-conf apps (like Muun) must *immediately turn
off* their zero-conf features.

I understand this wasn't the intention when designing the opt-in deployment
mechanism. Given this new information, do you see a path where we can delay
the
opt-in deployment and find a safer way to deploy full-RBF?

It'd be great for this deployment to be a success so that we can continue
fixing
the remaining relay policy problems, such as package relay and the RBF
rules.
Maybe we could go straight to an opt-out deployment locked by code at a
certain
height in the future to give time to everyone and, at the same time, avoid a
huge mempool divergence event?

Below is our analysis of how zero-conf apps break with opt-in full-RBF. I
hope
it helps.

Cheers,
Dario


# How do zero-conf apps work

While the workings and trade-offs of zero-conf applications might be known
by
many in this list, it's useful to define precisely how they work to
understand
how they break.

We call zero-conf applications to entities that accept on-chain payments
from
*untrusted parties* and will sometimes deliver the paid-for product or
service
without waiting for the transaction to be included in a block.

Some examples of zero-conf apps:

- Muun's submarine swaps for outgoing lightning payments
- Bitrefill's on-chain payments for gift cards and phone top-ups
- Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at
least
  the two biggest bitcoin ATM manufacturers support this: Genesis Coin and
  General Byte)

All of these applications are receiving incoming on-chain transactions for
which
they don't control the inputs, and performing a risk analysis to decide
whether
they are ok with accepting the payment without confirmation.

In practice, this works because once the bitcoin P2P network has fully
propagated a non-RBF transaction, you need the collaboration of a miner to
replace it, which isn't easy to get today. Even though many of the biggest
miners offer off-band transaction broadcasting services, they currently
won't
process conflicting transactions.

Roughly, the risk analysis goes like this:

1. if an incoming transaction is RBF (direct or inherited)
   --> too risky, wait for 1 conf (or more) since it can be replaced at any
time
2. if the payment is for an amount greater than X
   --> too risky, wait for 1 conf (or more), since the amount is worthy of a
       sophisticated attacker
3. wait for full(ish) propagation of the incoming transaction
4. if there's no double-spend attempt
   --> accept 0-conf

As with any other risk analysis, there's always a false-negative detection
rate,
leading to an expected loss, which the zero-conf app should be willing to
bear.
Notice that the expected loss is tunable via the amount X in the above
analysis.


# Why are zero-conf apps not protected with an opt-in deployment

Full-RBF adoption works on three different layers:

- The transaction application layer
- The transaction relaying layer
- The transaction mining layer

If an application wants to replace with full-RBF an *outgoing* transaction,
it
will need:

- An upgraded node that opted into full-RBF, from which it can broadcast the
  replacement transaction
- A connected component of upgraded nodes that opted into full-RBF, that can
  relay the replacement transaction
- A miner in that connected component with an upgraded node that opted into
  full-RBF, that can mine the replacement transaction

However, an application cannot control whether a replacement to an
*incoming*
transaction is relayed via full-RBF. As soon as a single application can
generate replacements easily via full-RBF, all other applications have to
assume
that any incoming transaction from an untrusted party might be replaced via
full-RBF. That is, for the application layer this is a forced upgrade.

As soon as an unsophisticated attacker can use opt-in full-RBF, the risk
analysis performed by zero-conf applications stops working because the
transactions to analyze are all incoming transactions from untrusted
parties.
Since some wallets already implement cancel functionality for opt-in RBF
transactions, enabling the same functionality for every transaction wouldn't
require much work, making canceling any unconfirmed transaction a one-click
experience. After this, the security model of zero-conf applications goes
from
"susceptible to attacks from miners" to "anyone can perform an attack, with
an
easy-to-use interface".

That is, the opt-in deployment of full-RBF doesn't protect zero-conf
applications from having to turn off their zero-conf features very soon
after
the initial deployment. All mitigations are mostly ineffective against
untrusted parties.


# Other things we have to fix

While it's clear how full-RBF breaks zero-conf applications, other more
subtle
things break in *many* wallets (Muun included). If given the opportunity, we
would like to fix them before deployment. One could argue that these things
were already broken, but they get considerably worse as the network adopts
full-RBF (even with an opt-in deployment), so we should fix them.

## Mental model for unconfirmed incoming transactions

Many wallets with support for on-chain payments (Muun included) show
incoming
external transactions in some way to their users before they confirm. This
is a
common practice because not showing them leads users to worry that their
money
disappeared (exchanges doing this is the #1 issue we have to deal with in
our
customer support channels).

With full-RBF, wallets should make it extremely clear to users that
unconfirmed
funds are not theirs (yet). Otherwise, protocol-unaware users that are
transacting on-chain with untrusted parties can be easily scammed if they
don't
know they have to wait for a confirmation. Eg. in Argentina, it's pretty
common
to meet someone in person to buy bitcoin P2P for cash, even for newcomers.

## Block explorers as payment receipts

Most wallets with support for on-chain payments (Muun included) use the
transaction view of a block explorer as a shareable payment receipt. The
sender
of an on-chain transaction usually shares this link with the receiver to let
them know they made a payment. Protocol-unaware receivers sometimes take
this
link as proof of payment.

Most explorers currently don't track payment replacements and, more
importantly,
don't warn users that unconfirmed funds are not theirs (yet). With full-RBF,
wallets should either stop relying on explorers for this functionality or
wait
for them to support it explicitly.


# Impact at Muun

Work to transition Muun from using zero-conf submarine swaps to using
payment
channels is ongoing, but we are still several months away from being
production
ready. This means we would have to turn off outgoing lightning payments for
+100k monthly active users, which is a good chunk of all users making
non-custodial lightning payments today.

Furthermore, the more subtle fixes imply non-trivial amounts of product work
that we cannot reasonably deploy before they start affecting users.

While I cannot talk for other applications, there are many impacted in one
way
or another, and none of the ones I checked with were aware of this change,
or
its implications.

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