From ZmnSCPxj at protonmail.com Thu May 4 15:30:34 2017 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Thu, 04 May 2017 11:30:34 -0400 Subject: [Lightning-dev] Channel top-up In-Reply-To: <20170504103930.GA27668@nex> References: <20170504103930.GA27668@nex> Message-ID: Good morning Christian, >thanks for proposing this, it looks quite interesting, and the top-up >problem is definitely worth looking into. Thank you very much your kindness. >However, I think there are a >few problems with your proposal: it is rather complicated and needs to >track funds in the channel as well as "side-stashed" funds, 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. Here is concrete example. 1. First, the channel has state: Alice=0.0, Bob=1.0 2. Alice requests a top-up to Bob. She makes an HTLC(3days, topupsecret) on-chain (written, signed, confirmed) worth 0.25, which Bob can redeem once Alice provides the secret. 3. Bob changes the channel state using update_add_htlc, so the channel now has state: Alice=0.0, Alice+HTLC(1day, topupsecret)=0.25, Bob=0.75. 4. Alice changes the channel state using update_fulfill_htlc, so the channel now has state: Alice=0.25, Bob=0.75. Bob now knows the secret to the HTLC that Alice prepared on-chain. 5. Bob performs an on-chain transaction to recover the 0.25Btc from the on-chain HTLC by Alice. There is no need to keep track of side funds once the HTLC update_fullfill_htlc command is sent by Alice. At this point, Bob has access to the money. The limitation here is that the total channel funds limits the amount that Alice can top-up the channel. >also the >HTLCs in the channel cannot possibly make use of the topped up funds >since they are not spending them, they'd need to be aggregated first. Sorry, maybe my explanation isn't clear. Alice's side is depleted, but Bob's side isn't depleted. So Bob can offer an on-channel HTLC to Alice using Bob's funds on the channel. >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. >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. >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 ^^ >Splice-out >---------- >The opposite problem of moving funds out of a channel can also be >addressed with this trick. So we can actually perform on-chain t>ransactions directly from funds that are locked into a channel >(that's why I don't think "locked in" is the right word to describe >this situation). So let's assume Alice would like to perform an >on-chain payment using some funds (x satoshi) that are currently >assigned to a channel with Bob. She creates a settlement transactions >that spend x satoshi to the desired destination/address, and the >remainder is paid back to a 2-of-2 output owned by Alice and Bob. They >will then build the new version of the channel on top of this new >2-of-2 output and be able to continue performing transfers right >away. Again, this works because the funds that remain in the channel >never touch a singlesig, so there is no need to confirm it first. I see. This seems feasible. The order needs to be specified exactly, though. In this case, to splice out 1. Alice generates a new funding transaction, inputting only the previous funding transaction. It outputs a 2-of-2 multisig Alice+Bob, and another output P2PKH of Alice's selection. 2. Alice sends the splice-out funding transaction to Bob, who checks that the P2PKH of Alice plus the tx fee of the splice-out funding transaction is less than Alice's money on the channel. 3. Alice and Bob create and sign new commitment transactions based on the splice-out funding transaction, checking that the balances are correct, with Alice's balances spliced out correctly. 4. Alice and Bob sign the splice-out funding transaction, and broadcast the tx without waiting for confirmation. 5. Alice and Bob exchange revocation keys for their previous commitment transactions (which were based on the previous funding transaction). 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. >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. >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. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: