alicexbt [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-08 📝 Original message:Hi Dario, There aren't any ...
📅 Original date posted:2022-10-08
📝 Original message: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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221008/1ee7b850/attachment-0001.html>;
📝 Original message: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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221008/1ee7b850/attachment-0001.html>;