Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-17 📝 Original message:Hi John, I hear your worry ...
📅 Original date posted:2022-10-17
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/28add9f9/attachment.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/28add9f9/attachment.html>;