From decker.christian at gmail.com  Thu May  4 10:39:30 2017
From: decker.christian at gmail.com (Christian Decker)
Date: Thu, 4 May 2017 12:39:30 +0200
Subject: [Lightning-dev] Channel top-up
In-Reply-To: <fWCa0hDGzX5AeyjKFSGKnZzYIryTdy1n7eNTK7JE8ZWLbs9ZM2NgiCyMNZF2b5JcSfYxX0Mdxhg7FPF4Erep3iJUorfBngugAs0wOW7fUfI=@protonmail.com>
References: <fWCa0hDGzX5AeyjKFSGKnZzYIryTdy1n7eNTK7JE8ZWLbs9ZM2NgiCyMNZF2b5JcSfYxX0Mdxhg7FPF4Erep3iJUorfBngugAs0wOW7fUfI=@protonmail.com>
Message-ID: <20170504103930.GA27668@nex>

Hi ZmnSCPxj,

thanks for proposing this, it looks quite interesting, and the top-up
problem is definitely worth looking into. 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, 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.

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.

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, 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.

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
transactions 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.

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.


I'd love feedback and comparisons of both proposals :-)

Cheers,
Christian