Re: [Lightning-dev] Proposal for skip channel confirmation.
Hi Zeeman, > i.e. I send my high-fee RBF-enabled channel funding to you, at the same time I send a conflicting low-fee RBF-disabled transaction (that pays the entire channel amount to myself) to all the miners I can find. Mapping miners mempools will be a cost in spying infrastructure and thus make the malicious routing node job harder, providing a security improvement for zero-conf channels. I used "lower trust" intentionally, it's not binary (what about opening a channel with a reorg-powerful counterparty ?). > And your fullnode will not see the conflicting low-fee RBF-disabled tx either because it is lower fee than what you have in your mempool and you will reject it. I was assuming a no-mempool mobile LN client, thus not going to be blind by your high-fee RBF. But still able to speak with the p2p network thus you can actively seek that your transaction has been accepted by ~100 peers. Overall, I don't think this scheme is worthy to work on unless double-spend of zero-conf chans become a real issue, just to mention we have potential solutions in this case. > There Ain't No Such Thing As A Global Mempool! I know :) Le mar. 25 août 2020 à 03:38, ZmnSCPxj a écrit : > Good morning Antoine, > > > Hi Roei, > > You might have a mechanism to lower trust in zero-conf channel opener. > Actually the local party can be in charge of broadcasting the funding > transaction, thus ensuring it's well-propagated across network mempools and > then start to accept incoming payment on the zero-conf channel. Per BIP 125 > rules, a malicious funder/opener would have to pay a higher fee to replace > the channel funding tx and thus double-spend the HTLC. A local party may > require a higher fee funding transaction than it is necessary wrt ongoing > congestion to increase level of protection. And I think it's okay on the > economic-side, you will amortize this fee premium on the channel lifecycle. > Until the transaction gets confirmed you might only accept HTLC under this > fee. So you have game-theory security for your zero-conf channels as it > would cost more in fees than a HTLC double-spend win for the malicious > opener, under the assumption of non-miner-collusion with the attacker. > > Since RBF is opt-in for Bitcoin Core nodes, and I believe most miners are > running Bitcoin Core, it is trivial to double-broadcast. > i.e. I send my high-fee RBF-enabled channel funding to you, at the same > time I send a conflicting low-fee RBF-disabled transaction (that pays the > entire channel amount to myself) to all the miners I can find. > > Since the miners received an RBF-disabled tx, they will not evict it even > if they see a higher-fee RBF-enabled tx. > And your fullnode will not see the conflicting low-fee RBF-disabled tx > either because it is lower fee than what you have in your mempool and you > will reject it. > > You really have to trust that I do not do this when I offer a channel to > you. > > There Ain't No Such Thing As A Global Mempool! > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Witness asymmetric payment channels
Good morning Lloyd, I think this is excellent work overall. With that said... > - It is more elegant as there are half the number of possible transactions. > I > expect this will follow through to reduced implementation complexity and > maybe > make it easier to explain as well. I am not sure the complexity will be reduced all that much. Currently: * We provide a partial signature for the other side for their commitment transaction. * We keep our own commitment transaction and the partial signature we receive from the other side. The node never has to retain the commitment transaction of the other side. With this setup: * We provide a partial signature for the other side for their asymmetric signature. * We keep a copy of the shared commitment transaction and the partial signature we received for our own asymmetric signature from the other side. So storage complexity is still the same. An issue is that with asymmetric transactions, it is fairly easy to use TCP to communicate changes to the commitment txes. We send a bunch of HTLC changes we want to apply to the other side commitment tx, then send a signature for those changes. Since what we send applies to *their* transaction only, we do not have to consider what they sent to us, we just have to consider what we sent to them. Conversely, when keeping track of what our commitment transaction is, we only have to consider what they sent to us, in order, and then when we receive a signature we know it is for the commitment transaction with all the updates the other side sent. (This arguably just moves the complexity higher, however: we cannot forward an HTLC until both us and the other side have revoked the transactions that do not contain it i.e. the "irrevocably committed" state.) When we have "the same" transaction on both sides, however, we need to synchronize between the two sides. Suppose both participants want to forward HTLCs to one another. Without any kind of locking, both participants could send network packets containing the HTLCs they want to add to each other, and it becomes ambiguous whether the signature they *should* send contains one, or both. Basically, TCP only assures a global order for *one* direction of the communications, once we have two network nodes talking simultaneously, the order in which one writes and then reads is a lot more ambiguous. This issue also exists for Decker-Russell-Osuntokun, incidentally. One way to solve this would be to have a "token" that is passed alternately between the participants. At initial connection, they run a secure multiparty coinflip that indicates which one gets the token. Then, the one that holds the token can add more HTLCs, then tell the other "okay, now we sign" and they exchange signatures for a new version that involves only the HTLCs from the token-holder. Then the token-holder passes the token to the other side. If the current token-holder does not have any HTLCs it wants to send, it can wait for some time (in case it receives a request to forward), then if there are still no HTLCs, it can pass the token to the other side by sending a token-passing message. This solution requires a good amount of bandwidth in such token-passing messages, which can multiply with the number of channels a single node has. If token-passing is not done in short time frames (sub-second) then it potentially increases the latency of forwarding, thus this represents a latency vs bandwidth tradeoff. There may be better solutions for this race-condition problem. For example, it seems to me that we can still have different histories for both sides of the channel, i.e. different transactions on both sides, the same as in current Poon-Dryja BOLT. After all, the witnesses are asymmetric anyway. But that completely negates the stated goal of removing the different transactions on both sides and the hoped-for reduction in complexity, so an exercise in futility. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Witness asymmetric payment channels
# Abstract This is a proposal for a new channel symmetric channel construction that uses the key idea from a recent paper called "Generalized Bitcoin-Compatible Channels"[1] and tries to practically apply it to lightning. If you prefer, you can read the rendered markdown version here: https://github.com/LLFourn/witness-asymmetric-channel The purpose of this post is to get feedback to see if it's worth doing a PoC implementation. # Background As presently specified the two parties in a lightning channel are assigned different commitment transactions. This _transaction asymmetry_ is logically necessary for the protocol to identify which party broadcasted a commitment transaction and potentially punish them if the other party provides proof it has been revoked (i.e. knows the revocation key). Wouldn't it be nice if we could identify the broadcasting party without assigning them different transactions? Riard first considered this problem in [8] while trying to add a punishment mechanism to eltoo[9] style channel updates. They proposed that you could identify the broadcasting party using _witness asymmetry_ i.e. both parties broadcast the same transaction but have different witnesses. Unfortunately, the solution proposed is rather convoluted. More recently in [1], Aumayr et al. introduced a much more elegant witness asymmetric solution using adaptor signatures. Instead of being assigned different transactions, the parties are assigned different adaptor signatures as witnesses for the _same_ transaction. The adaptor signatures force the party broadcasting a commitment transaction to reveal a "publishing secret" to the other party. The honest party can then use this publishing secret along with knowledge of the usual revocation secret to punish the malicious party for broadcasting an old commitment transaction. Aumayr et al. combine this idea with a "punish-then-split" mechanism similar to the original eltoo proposal. Unfortunately, it therefore inherits the same issue with staggering time-locks. BOLT 3 [4] describes why it avoids this problem as a design choice: > The reason for the separate transaction stage for HTLC outputs is so that > HTLCs can timeout or be fulfilled even though they are within the > to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is > lengthened by this delay, causing longer timeouts for HTLCs traversing the > network. There is further background discussion to this choice in [2] and Towns proposes a solution for eltoo in [3]. In short, the problem is that it creates a risk for the party that needs to fulfill an HTLC with the secret in time. The only known way of accounting for this risk is to increase the difference between the time-locks on each hop. There could be situations where this trade off makes sense but it seems undesirable for a general purpose payment channel network. # Proposal I propose a channel protocol which steals the main idea from Aumayr et al. while retaining the time-lock precedence of BOLT 3 transactions. That is, absolute time-locks are settled before relative time-locks to avoid having to account for relative time-locks when calculating absolute time-locks. The guiding principle is to keep commitment transactions symmetric but to use the asymmetric knowledge of the parties to simulate the way lightning works right now. The main benefits of this seem to be: - It is more elegant as there are half the number of possible transactions. I expect this will follow through to reduced implementation complexity and maybe make it easier to explain as well. - Every output can just be a 2-of-2 multi-sig (which could be a single key with MuSig or OP_CHECKMULTISIG with ECDSA etc). This makes the transactions a little smaller even when using 2-of-2 with ECDSA on balance, The space saving comes from avoiding explicit revocation keys in the commitment transaction outputs and using PTLCs rather than HTLCs. - The design works today and easily transitions into a post-taproot world although there is still a bit to explore there [5]. ## Notation I describe the protocol with respect to two parties Alice and Bob. 2-of-2(Xa,Xb) refers to a multi-signature output that supports adaptor signatures and requires the owners of Xa (Alice) and Xb (Bob) to authorize it (e.g. `OP_CHECKMULTISIG` with ECDSA [6], or MuSig with Schnorr etc [7]). ## The Fund transaction The structure of channel funding does not change from the current BOLT spec. The Fund transaction spends from the funding party's (or funding _parties_) outputs to an output of 2-of-2(Fa,Fb) where Fa and Fb are public keys owned by Alice and Bob respectively. These keys are generated and exchanged once per channel. ## Commitment transactions All commitment transactions spend from the 2-of-2 on the Fund transaction and each represents a "state" of the channel. A commitment transaction has two balance outputs and zero or more PTLC outputs. Before creating a commitment transaction the pa
Re: [Lightning-dev] Proposal for skip channel confirmation.
Hi Matt and thanks for your notes. On Mon, 24 Aug 2020 at 22:22, Matt Corallo wrote: > > A few notes. > > Given gossip messages will be rejected by many nodes if no such on-chain > transaction exists, I don't think you can > "re-broadcast" gossip messages at that time, instead I believe you simply > need to not gossip until the funding > transaction has some confirmations. Still, this shouldn't prevent receiving > payments, as invoices carrying a last-hop > hint should be able to indicate any short_channel_id value and have it be > accepted. You are right. They really should be broadcasted once after the funding transaction is sufficiently deep. I confused that with the exchange of channel_update privately between them before the channel is confirmed so they both will be able to relay payments using this channel. > > It may make sense to reuse some "private short channel ID negotiation" > feature for the temporary 0-conf short channel id > value. > > One thing this protocol doesn't capture is unidirectional 0-conf - maybe the > channel initiator is happy to receive > payments (since its their funds which opened the channel, this is > reasonable), but the channel initie-ee (?) isn't > (which, again, is reasonable). This leaves only the push_msat value pay-able, > and only once, but is a perfectly > reasonable trust model and I believe some wallets use this today. Although this proposal addresses the bi-directional zero-conf channel both parties are able to "hold" any payment. When the payee decides not to release the preimage based on some policy (total funds at risk, wait for confirmation) the channel becomes unidirectional. Implementing a unidirectional channel this way also has some advantages such as: 1. It gives you the ability to increase trust on an existing zero-conf channel. Sometimes this is preferable because it saves the need to open additional channels and it shortens the trust period (waiting for confirmation for a previously opened channel). 2. The funds sent to the channel acceptor can be a result of a lightning payment, including proof of payment for the payer. Roei > > Matt > > On 8/24/20 4:16 AM, Roei Erez wrote: > > Hello everyone, > > > > I would like to discuss the ability to skip a channel funding > > transaction confirmation, making the channel fully operational before > > its on-chain confirmation (aka a zero-conf channel). > > Till confirmation, this channel requires trust between its two parties > > and in the case of a remote initiator, it puts the received funds of > > the local party at risk. > > Nevertheless, there are cases where it makes sense to support this > > behavior. For example, in cases both parties decide to trust each > > other. Or, in cases where trust between the parties already exists > > (buying a pre-loaded channel from a service like Bitrefill). > > > > The motivation is gained from the "Immediate on-boarding" use case: > > * Bob is connected to a routing node and issues an invoice with a > > routing hint that points to a fake channel between Bob and that node. > > * When Alice pays Bob's invoice, the routing node intercepts the HTLC > > and holds it. > > * Then, the routing node does the following: > >* Opens a channel to Bob where Bob has a choice of skipping funding > > confirmation (channel is open and active). > >* Pays Bob the original Alices' invoice (potentially, minus a service > > fee) > > > > From Bob perspective it is his choice on whether to agree for the > > payment via this channel (and by that increase the trust) or disagree > > and wait for confirmation. > > Another practical way for Bob is to skip confirmation and "hold" the > > payment by not providing the pre-image. > > > > Right now different implementations support zero-conf channels in > > different ways. These implementations have defined their own way on > > how to agree on a short_channel_id (fake one) before the transaction > > is confirmed. > > > > The following suggests some changes to the funding flow to support that: > >1. accept_channel message - in case the fundee wants to skip > >confirmation he sends minimum_depth=0 > >2. funding_signed message - no change. > >3. funding_locked message - if fundee has sent minimum_depth=0, then > >both parties send funding_locked while the channel_id is derived > > using a > >convention agreed on both. One proposal for such convention is to > > take it > >from the temporary_channel_id provided in previous open_channel > >message as follows: > > * Use the first 8 bytes to initialize an unsigned integer, > > call it shortID > > * Apply this transformation: shortID / 2^6 + 100,000 > > * The above transformation ensures the block height falls in the > > range of 100,000 - 2^18+100,000. The rationale is that the id > > will > > never point to a valid mined transaction and the f
