<unnamed>

Public Key

npub1c3j2v4ws7hf9sj2xkr4dale0z4htw7lup37qeh2wxll4pcvlg03qe2aw73

Profile Code

nprofile1qqsvge9x2hg0t5jcf9rtp6k7luh32m4h007qclqvm48r0l6sux058cspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgj3n3nq

Publishing to

relay.nostr.band

Last Notes

2023-06-07 23:14:19 UTC

- reply

📅 Original date posted:2022-10-12
📝 Original message: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 at 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 at wuille.net>
wrote:
> On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <
> aj at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221012/5280640b/attachment-0001.html>

2023-06-07 23:14:18 UTC

- reply

📅 Original date posted:2022-10-07
📝 Original message: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 at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221007/a17e3454/attachment.html>

2023-06-07 23:14:16 UTC

- reply

📅 Original date posted:2022-10-07
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221007/d8b61478/attachment.html>