From ZmnSCPxj at protonmail.com Thu May 4 22:00:36 2017 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Thu, 04 May 2017 18:00:36 -0400 Subject: [Lightning-dev] Channel top-up In-Reply-To: <20170504175329.GA4125@nex> References: <20170504103930.GA27668@nex> <20170504175329.GA4125@nex> Message-ID: Good morning, >> 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. That's correct. Of course, proper splice-in and splice-out operations would allow channel maximum capacity to be controlled by the counterparties, based on their financial situation and growing/shrinking trust in their counterparty. >> >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. Ah, I see. However, we need to ensure the new funding transaction can be confirmed before the pre-splice-in transaction times out. This is especially true if we continue to use the channel, based on the new funding transaction, in an asynchronous (i.e. operating the channel before the splice-in funding transaction is confirmed) manner. So the timeout needs to be rather longish, to ensure that the splice-in funding transaction can get on-chain before the pre-splice-in transaction times out. Needless to say, asynchronous splice-in would require malleability fix, and in the back of my mind I'm forming a contingency plan if Bitcoin really can't deploy a malleability fix in two years (or half a year when I'm feeling particularly excited about LN). At least the off-to-on-LN routing (using an on-chain HTLC to "buy back" some capacity on your side of a channel) could work without malleability fix. >> ^^ counterparty hostage risk, Bob didn't follow it ^^ > >Counterparty hostage risk disarmed ^^ Yes ^^ About synchrony/asynchrony; perhaps it's possible to also offer a synchronous splice-in. For example, Alice knows she will route a larger-than-normal payment to Bob in the future, but will not be sending micropayments now. Then perhaps the counterparties can use a splice-in funding transaction directly spending from Alice's inputs (rather than from a pre-splice-in that Alice prepares to reassure Bob she won't suddenly invalidate an unconfirmed splice-in funding transaction). This is slightly less costly, but channel operations would have to be suspended while the splice-in funding transaction is confirmed. This reduces on-chain load. Although I suppose to the rest of the network, the unusable channel waiting for a synchronous splice-in would be no different from closing a channel, then opening a new one in its place, so maybe not. >> >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 ;-) Yes, but if there is hostility against LN (as I suspect), it may happen too often T.T Personally, I think, it's safer to tell our users that indeed, channel funds are locked in, rather than some attacker running a bad LN node suddenly causing a behavior that honest but naive users did not expect. >> 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'll have to defer to you on this one. While I can understand the revocable transactions and the HTLC's in isolation, I haven't understood well yet the ramifications of their interactions. >> 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. Suppose Alice is planning a new business that receives Bitcoin. She sets up an LN node. However, because her LN node is new, it doesn't have channels yet. To expedite payments to her when business is launched, she wants her LN node to have channels. But if she initiates channels herself to nodes already on the network, those channels will be set up to send from her business node to the network, when she wants them to be set up to receive. Of course she could leave her node without channels and have her first customers set up a channel directly to her, but that slows down her customers, who must wait for the channels to open before they can spend money on Alice's excellent service. Instead, in preparation for business launch day, Alice opens a channel to well-connected node Bob. At first, the channel's state is Alice=1.0, Bob=0.0, because Alice initiated the channel, so Alice can't actually use it to receive funds. She sends an invitation-to-top-up to Bob, inviting him to top up the channel by 0.5 btc, and if Bob compiles and does indeed top-up, then the channel's state becomes Alice=0.5, Bob=0.5, so it can now be used by Alice to receive from customers. Alice does this a few more times with various other existing LN nodes, so that on business launch, she can receive money from her first customers immediately. Of course, if we had a symmetrical rather than a one-sided open, a symmetrical open would be more efficient on the underlying Bitcoin network overall. Top-up can be used to revive not only exhausted channels, but exhausted routes. Suppose there is one known route from Alice to Carol: Alice->Bob->Carol. Because of Carol's excellent service, Bob->Carol's channel is exhausted. Alice can then use an on-chain HTLC to revive the Alice->Bob->Carol route, by making a top-up operation: Alice ->(onchain)-> Carol -> Bob -> Alice. Of course, in this case Alice is better off just making a channel directly to Carol, if she is willing to make an on-chain transaction anyway. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: