From decker.christian at gmail.com Thu May 4 17:53:29 2017 From: decker.christian at gmail.com (Christian Decker) Date: Thu, 4 May 2017 19:53:29 +0200 Subject: [Lightning-dev] Channel top-up In-Reply-To: References: <20170504103930.GA27668@nex> Message-ID: <20170504175329.GA4125@nex> Hi ZmnSCPxj, thanks for the clarification, I think I understand the proposal a bit better now. > I'm not sure why it's complicated apparently. > > Actually, this reuses the same mechanism as onion routing. The only > difference is that the first "hop" of the route is performed via an > on-chain transaction. > > Once the usual onion-routing mechanims has settled with > update_fulfill_htlc, the channel state settles to a new topped-up > state. The "side funds" are definitely in the possession of Bob, and > do not affect the channel state and are not considered in the > channel state. I see, so you're not actually modifying the total amount in the channel, Alice is just buying back some capacity on the channel using an on-chain transaction. > >At the Scaling Bitcoin workshop I proposed a mechanism that I called > >splice-in/-out that would also solve the top-up problem, but I never > >got around to write it up, mea culpa. Splicing is just a clever way of > >closing a channel and reopening a new one right from the settlement, > >and the new one does not need to be confirmed before we can perform > >further updates. > > I'd considered something similar at first, but realized that some > risks were involved. I don't think we are incurring in any exceptional risks, and we are actually reusing the same machinery we already have for the initial establishment of the channel. > >Splice-in > >--------- > >So let's say that Alice would like to top-up here channel with > >Bob. She will take some of her funds and create a new 2-of-2 output > >with requiring both Alice and Bob's signature, this is preparing funds > >to be added to the channel. We let the transaction creating that > >2-of-2 output confirm. Once that output is securely confirmed Alice > >asks Bob to splice-in, > > Bob then creates the following message: "Heya Alice! I see you made > a 0.25 btc output requiring a 2-of-2 multisig. One of the signatures > on that multisig happens to be my signature. Because of this > unauthorized requirement of my signature, I want you to make another > transaction spending that transaction, sending 0.13 btc to > 18X5NsJrrqgjprXucYTTshjHm3ETYgqk8z. You can transfer 0.12btc minus > transaction fees to someone else if you like. Please sign that > transaction and send it to me. Love, kisses, hope that helps, Bob." > Bob then cryptographically signs the message and sends it > off-channel to Alice. Bob then refuses to cooperate with the rest of > the splice-in protocol. This is not different from how we are establishing channels initially. Alice would only ever lock in the funds with a guarantee that she can retrieve the funds if Bob decides not to cooperate. We can implement this with locktimes or CSV, and disarm that mechanism later using a re-anchor. So the script is (A+B || A+timeout) if the splice goes well we re-anchor, and the righthand side of the || is disarmed. > >so they collaboratively close the channel by > >spending the funding TX output and the prepared top-up output into a > >new 2-of-2 output. On that final 2-of-2 output we will create the new > >channel, i.e., the settlement transaction is automatically the funding > >transaction of the new channel. > > > >Alice and Bob can use the existing channel right up to the splice-in > >operation, Alice may just be pre-allocating some funds in > >parallel. During the splice-in we need to stop forwarding HTLCs for a > >few seconds, so we can settle cleanly. Directly after the splice-in > >the channel is functional again, no need to let the settlement/funding > >transaction confirm. That is because the funds in the channel never > >touched an unconfirmed singlesig output, hence they can never be > >doublespent without the collaboration of the counterparty. > > ^^ counterparty hostage risk, Bob didn't follow it ^^ Counterparty hostage risk disarmed ^^ > >Splice-out > >---------- > > In the above, it's safe to abort at any time, with the money > remaining in the channel. > > Note however a potential hostage situation: Alice wants to move > money out of the channel expeditiously without closing the > channel. Bob may refuse to cooperate on a splice-out. Thus, this is > the same risk as Alice requesting to close the channel and Bob not > cooperating, forcing Alice to use her commitment transaction, which > has a time delay. > > Thus, it's not safe to think of the channel's fund as anything but > locked in, since uncooperation means the channel's funds are > returned to you after a timeout. Right, there remains that risk, but hopefully that wouldn't happen too often ;-) > >We might even go a step further and not need to drain the HTLCs from a > >channel before performing a splice operation, assuming we can get the > >setup procedure to include all HTLCs that were present before the > >splice operation. > > Sorry, the interaction of CSV (in commitment transaction timeouts) > and CLTV (in HTLC's) still escapes me. If we are able to recreate the same HTLCs on the re-anchored channel in a safe way then we can avoid draining them off of the channel before splicing. Even if we don't do that we may simply hold back on adding new HTLCs, drain, re-anchor and then add the held back HTLCs once the splice is completed. And finally this could allow us to perform a partial drop to the chain, splicing out just the HTLCs which are about to expire and maintaining the rest of the channel intact. > >I'd love feedback and comparisons of both proposals :-) > > As for my top-up proposal, I realized also, that it's actually an > onion route where part of the hop is done on-chain rather than > on-Lightning. > > Thus, while the top-up procedure is expected to be used by Alice to > top up her channel funds, it's actually the first hop of an onion > route. The onion route just happens to route from off-LN Alice, to > on-LN Bob, to on-LN Alice. > > This may be used by someone off-LN to pay into an LN node without > committing funds to open a channel, for example for a one-off > transaction to a Lightning node. That someone may use onion routing > to ensure that it becomes untraceable on LN. Alternatively, a > non-Lightning user can claim he or she did an off-LN onion route, > but actually just sent the funds to himself/herself to throw off > trackers. That's very clever, I like the combination of on-chain and off-chain payments. I still like my splicing approach better (yes, I'm pretty biased in this case ^^) but being able to combine on-chain and off-chain is a great feature, let's see how far we can push it. Cheers, Christian