# Zero-conf channels ## The Zeroconf Trust Model To simplify analysis we take a look at 'vanilla' zeroconf: i.e. accepting zeroconf channels without any extra-protocol mitigations. We look specifically at a case where a user is accepting zeroconf txns from a specific LSP, not of businesses accepting zeroconf channels from anyone on the network (which is obviously unsafe) - Side note: Accepting zeroconf channels from anyone is obviously unsafe because an attacker A could send a payment to themselves C through the vulnerable zeroconf channel acceptor B. A payment is complete over the zeroconf channel A->B->C. The zeroconf channel's funding tx is then double spent. All that remains is the settlement of payment B->C. Thus, the attacker A has extracted funds from the victim B, with the fruits of their effort collected in their second node C. ### An example attack - A merchant is selling digital goods on their online store, and does not have any channels open. - This merchant has an LSP which they rely upon for managing liquidity, etc. They accept zeroconf channels from this LSP. - The operator of the LSP spins up another Lightning node (let's call it 'Eve'), pretending to be a customer interested in the merchant's products. - Eve purchases the merchant's digital item via a Lightning payment. - The LSP, seeing that the merchant does not have a channel open, initiates a zeroconf channel to the merchant. The merchant accepts because this is normal, expected behavior. The HTLC to the merchant is cleared and settled, and the merchant delivers the digital good. - To be clear: at this point HTLCs representing payments from Eve -> LSP and LSP -> merchant have been clear and settled. - However, instead of broadcasting the funding tx, the LSP double spends the output the funding tx is spending from, broadcasting this double-spend tx to the broader Bitcoin network. The channel is invalidated - The result of this is that the LSP -> merchant HTLC has effectively been reverted, while the Eve -> LSP HTLC has still gone through. In other words, the LSP's operators made a payment to themselves, spending nothing, while the merchant delivered a good and was not paid for it. - More seriously, imagine that the 'merchant' using the LSP is a custodial exchange - the deposit into the exchange is double-spent but the account balance is still credited, and can then be immediately withdrawn. ### No accountability for LSPs that double-spend - In the Lightning protocol, the channel responder never sees the funding transaction, so they can't ensure that it is broadcasted. - Thus, an untrustworthy LSP could initiate a zeroconf channel with a user and not even broadcast the funding tx - instead only propagating the double spend tx. - 3rd party full nodes in the network would not notice that a double spend attempt succeeded, even if they were modified to track possible double-spend attempts (like [[Blockcypher]]'s). This is because of the point above - the funding tx does not even need to be broadcasted. - Side point: Remember, the mempool is not a monolith - every full node has its own view of the mempool. Just because one node observes a double spend does not mean that another one will. - Thus, a double-spend attempt by an LSP is not necessarily observable by the broader network. - Furthermore, as [[Matt Corallo]] points out, the channel responder does not have access to any cryptographic signature on a funding outpoint, so there is no way for them to transferably prove to someone else that a channel open request was made and later double-spent. ### The risk is not limited to the initial channel open. LSPs can systematically siphon away funds coming from 3rd party donors and tippers. - An untrustworthy LSP could not only steal the funds from the initial channel open, but also from all subsequent payments as well. - Suppose Bob has already established a channel with the LSP, which has been fully confirmed. - Suppose a legitimate donor Alice wants to send a donation to Bob. Alice initiates an payment using an Alice -> LSP HTLC. - The LSP receives the HTLC, and instead of sending the HTLC on the channel it already has with Bob, the LSP instead requests Bob to open up a new (zeroconf) channel. - The LSP -> Bob HTLC is cleared and settled on the zeroconf channel. - The LSP double spends the channel. - The result is that only the effects of the Alice -> LSP HTLC remain. So effectively, the LSP has stolen a payment from Alice that was originally meant for Bob. ### Current mitigations - One common mitigation for accepting zeroconf transactions, used by well-capitalized companies like [[Blockcypher]], is to run modified nodes that connect to a large number of peers to see which transactions it receives and estimate the probability that a particular tx is going to be confirmed (which they dub the [confidence factor](https://www.blockcypher.com/dev/bitcoin/#confidence-factor)). This is antisocial behavior, and requiring everyone to do this is a centralizing force. - [[Dario Sneidermanis]] also notes a few other mitigations that [[Muun]] wallet uses in his [October 2022 bitcoin-dev mailing list post](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020980.html) (ctrl+f for `Roughly, the risk analysis goes like this:`) - Checking if a tx is RBF or not - If the payment amount is large or not - If the funding tx has been fully propagated or not, and whether any double-spend attempts have been observed - [[Matt Corallo]] and Tony [note](https://discord.com/channels/915026692102316113/978829624635195422/1034656541976039545) in the LDK Discord that you could limit your LSP to only opening a zeroconf channel if it "needs to", i.e. referring to whether the amount of available inbound liquidity is sufficient to cover the incoming payment amount. It is worth noting, however, that this mitigation only works in the case that current inbound liquidity is sufficient to cover the payment in question - in all other cases, the LSP's behavior during this initial interaction (requesting to open a zeroconf channel to the recipient) is the same no matter whether the LSP is being honest or malicious. ### Possible further mitigations: "fraud proofs"? - Before accepting a zeroconf channel, the channel responder could require that they receive the funding tx first, persisting it somewhere. Then, if the funding tx is later double-spent, they *could* prove to the world that it was, by the specific party that did it. At least this way there is some transparency / accountability in this process, and untrustworthy LSPs can slowly be rooted out of the ecosystem. - All payments that a user has received over a zeroconf channel should be persisted and saved somewhere. Combined with the above proof-of-funding-tx, a user could then prove to the world that not only did (1) the LSP initiate a zeroconf channel which was double spent, (2) an HTLC was also forwarded across that channel. This should be sufficient proof of malice. ### "Pending" vs "Finalized" channel balances Another mitigation that could be applied, but which wouldn't work in all cases, is to expose balances and inbound payments on zero-conf channels as "pending," just as would be done in a typical on-chain wallet. A security-conscious end user could then be careful not to render any goods or services before the payment has been "finalized" - i.e. the channel the payment was made on has received a few confirmations. It's probably worth examining different real-world payment scenarios to see how far this distinction could make in practice: - **In person, point-of-sale transaction (e.g. in El Zonte)**. In this case, it is not acceptable to wait for the payment to "finalize" as the customer expects to receive their good immediately. The merchant must trust that their LSP won't defraud them, but can still hold on to the above "fraud proofs" in case something goes wrong. - It's worth noting, however, that if an LSP wants to double-spend a merchant in a point-of-sale scenario, they have to show up and pay the victim in person - a strange premise if they want to keep their theft inconspicuous. - Payment amounts may also be small enough that the theft of a singular payment doesn't matter - an LSP could also pick much better targets. - **Online store, physical goods.** In this case, it is probably an acceptable UX for the customer to immediately be notified that their payment was received, while the merchant actually waits for the payment to "finalize" before shipping their good. It is likely that by the time the online merchant has noticed that they've completed a sale and need to ship something, the zeroconf channel has already confirmed and this analysis is irrelevant. If the payment was reverted / double-spent by the LSP, the merchant can simply cancel the order. - **Online store, digital goods.** This is the case with the highest level of risk for the merchant. Treating "pending" payments as finalized (i.e., immediately rendering the digital good or service) effectively means that their LSP can steal anything that they sell, albeit with provable consequences. If the merchant is an exchange that allows instant deposits and withdrawals via Lightning, this could have disastrous consequences. Waiting for "finalized" transactions is best. If the merchant chooses to render the digital goods (which have high value), they must choose their LSP carefully, and ensure that they have some means of recourse (possibly legal) in the case that fraud does occur. **Summarizing - key considerations when deciding whether to accept pending payments:** - Do you trust your LSP? Do you have means of legal recourse against them if they defraud you? (Which you could also irrefutably prove in court) - Are you selling things of high value? Or is it alright to render goods and services for payments over unconfirmed channels until your LSP defrauds you? (upon which event you would immediately terminate your relationship with your LSP, and find a different provider) - Does your good or service have to be delivered immediately, or do you have some flexibility to wait for the occasional channel confirm? ## Technical Resources ### [Bitcoin Optech page](https://bitcoinops.org/en/topics/zero-conf-channels/) Zero-conf channels, also called turbo channels, are new single-funded channels where the funder gives some or all of their initial funds to the acceptor. Those funds are not secure until the channel open transaction receives a sufficient number of confirmations, so there’s no risk to the acceptor spending some of those funds back through the funder using the standard LN protocol. ### (lightning-dev) [Turbo channels spec?](https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html) Post by [[Rusty Russell]] > Here's a strawman proposal: > > 1. Assign a new feature bit "I accept zeroconf channels". > 2. If both negotiate this, you can send update_add_htlc (etc) *before* funding_locked without the peer getting upset. > 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel unless they have explicit reason to trust that node (they can still send *out* that channel, because that's not their problem!). ### (lnd docs in repo) [Setting up zero-conf channels in LND](https://github.com/lightningnetwork/lnd/blob/master/docs/zero_conf_channels.md) ### (LDK PR#1401) [Zero Conf Channels](https://github.com/lightningdevkit/rust-lightning/pull/1401) ### (LDK PR#1505) [Support `ZeroConf` Channel Type](https://github.com/lightningdevkit/rust-lightning/pull/1505) ### (Video) [Sensei / LDK: Adding support for 0-conf channels](https://www.youtube.com/watch?v=JjuN6aVv9DI) By [[John Cantrell]]. Links: [[Sensei]] ## Non-technical resources ### (LDK blog) [Zero-Confirmation Channels](https://lightningdevkit.org/blog/zero-confirmation-channels/) By [[John Cantrell]] ### ([[Muun]] blog) [Turbo channels](https://blog.muun.com/turbo-channels/) > It really depends on your preferences. When transactions require the use of turbo channels, there is a limited window of time where you trust Muun. Specifically, during that window of time, you trust Muun will not execute a - very public![1] - double-spend attack. If you are not okay with this, you should disable turbo channels. - How is this "very public"? AFAICT the funding transaction doesn't even need to be broadcast by the channel initiator if the channel responder isn't check a lot of mempools to see that it's actually being propagated ### (Medium) [Instant channels enable safe Lightning payments with unconfirmed funding](https://medium.com/@akumaigorodski/instant-channels-enable-safe-lightning-payments-with-unconfirmed-funding-8d640defa183) Older post from [[2019-02-10]] - A little bit more specific, but still doesn't fully cover the threat model ### (Random Blog) [What Are Turbo Channels?](# What Are Turbo Channels?) [[2022-04-09]] - Does not go into specifics ### (Fanis Michalakis Blog) [What Are Turbo Channels](https://fanismichalakis.fr/posts/turbo-channels/) [[2021-12-04]] ## Related resources ### (bolts#565) [Allow payments from unconfirmed push_amount](https://github.com/lightning/bolts/issues/565) - Not exactly zeroconf channels - still completely trustless