[Lightning-dev] reducing the number of blockchain transactions used by the LN, and the fees paid to confirm them

[ZmnSCPxj]

Good morning Jim,

The idea is called "splce in/out" and as Dario Sneidermanis mentioned, has occasionally been discussed on this list every now and then.

To my understanding:

1.  The splicing transaction has as input the previous funding transaction output.
2.  The splicing transaction has an output that is the next funding transaction output.
3.  All other inputs (to be spliced-in) of the splicing transaction must spend SegWit UTXOs so that the splicing transaction itself is not malleable.
4.  For pure splice-out, it would be possible to continue operating the channel even when the splicing transaction is not yet confirmed.  The channel updates commitment transactions that spend the next funding transaction output (an output of the splicing tranasction).  This is because the splicing transaction cannot be invalidated except by use of a revoked transaction.
5.  For any splice-in, there is the possibility that inputs are forcibly double-spent while the splicing transaction is unconfirmed, so the channel cannot be safely used until the splicing transaction is confirmed.  Getting around this is possible but adds significantly more complexity I think.
6.  Rough idea of protocol would be like this:
6.1.  Write up the splicing transaction without signing it.
6.2.  Write and sign commitment transactions based on the splicing transaction.
6.3.  Sign the splicing transaction.  This requires both parties.  After signing and before sending the splicing transaction, prevent use of the channel (whether pure splice-out or has any splice-in).
6.4.  Broadcast the fully-signed transaction.
6.5.  If pure splice-out, you can now exchange revocation keys for the previous commitment transactions and reenable use of the channel.
6.6.  If any splice-in is involved, wait for the splicing transaction to confirm before reenabling it (exchanging revocation keys is unnecessary for this since if the splicing transaction confirms, all previous commitment transactions are unuseable).

The splicing protocol will exist in BOLT 1.1, although I am unaware if there are people already working on this.

--

It is possible to just open a new channel to a different node that is indirectly connected to the channel you want to replenish, then send a payment from your new channel to your exhausted channel.  This has the advantage that (1) it works with current protocol (although no current node software implements this to my knowledge), (2) the exhausted channel can still be used for receiving and routing while you are doing so.  This also helps the general network health and connectivity.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

> -------- Original Message --------
> Subject: [Lightning-dev] reducing the number of blockchain transactions used by the LN, and the fees paid to confirm them
> Local Time: December 21, 2017 9:52 AM
> UTC Time: December 21, 2017 1:52 AM
> From: jim.renkel at comcast.net
> To: Lightning-dev at lists.linuxfoundation.org
>
> Hello, all!
>
> I'm a long-time computer networking developer, but a newbie to
> cryptocurrency, and am interested in contributing to its development.
>
> While looking at the lightning network design and code, I've come up
> with an idea the would reduce the number of blockchain transactions used
> by the LN, and the fees paid to confirm them, in a common LN use case.
>
> I did a quick search and couldn't find this idea presented previously,
> but I may have missed it. If so, or if the idea is faulty, I'm sure you
> guys will let me know. :-)
>
> And forgive me if I don't have the terminology quite right yet.
>
> The use case I am referring to is the frequent, repeated purchases by a
> customer from the same merchant over an extended period of time. I think
> this will be a common use case.
>
> For example: Alice buys a cup of coffee from Bob's Coffee Shoppe every
> day, has done so for years, will do so for years.
>
> To use the LN to pay for these purchases, Alice opens and funds an LN
> channel to Bob. This takes one blockchain transaction.
>
> As coffees are purchased every day, funds are transferred from Alice to
> Bob in the channel without any blockchain transactions.
>
> Alice cannot afford to fund the channel for an extended period of time,
> and Bob is unwilling to wait an extended period of time to be paid for
> the coffees Alice has purchased.
>
> So every week or so, Alice and Bob close the channel, Alice gets back
> any unspent funds, and Bob gets the funds that have been transferred to
> him for Alice's purchases. Then Alice and Bob re-open the channel with
> new funding from Alice. Closing and re-opening the channel each take one
> blockchain transaction.
>
> Over the life of the channel, if there are n close/re-open cycles, 2*n
> blockchain transactions are required: 1 to open the channel initially, 2
> each time the channel is closed and re-opened (n-1 times), and 1 to
> close the channel finally.
>
> If the LN were enhanced with an operation to deposit and withdraw
> funding in the channel to and from the blockchain without closing the
> channel, this could be done with a single blockchain transaction that is
> essentially the merge of the closing and re-opening blockchain transactions.
>
> In this example, each adjustment will only pay Bob his accumulated but
> as yet unpaid funds and charge Alice for the new funds she places into
> the channel, but leave Alice's unspent funds in the channel. The channel
> could continue to operate between the launching and confirmation of the
> adjustment transaction if Alice has unspent funds in the channel.
>
> Then the n cycles would only require n+1 blockchain transactions: 1 to
> initially open the channel, 1 each time the channel funding is adjusted
> (total n-1), and 1 to finally close the channel. This is a significant
> reduction in the number of blockchain transactions required, approaching
> 50% in the limit as n approaches infinity.
>
> What about blockchain transaction fees? I've done the analysis, but it's
> quite long (several conditions and dozens of combinations of conditions
> to consider), so I won't include it here now. I will included it in
> another post if anyone is interested and doesn't do the analysis for
> themselves.
>
> The bottom line of the analysis is that the number of inputs and the
> number of outputs in the funding adjustment transaction are each never
> greater than the sum of the number of inputs and the number of outputs,
> respectively, in the channel opening and closing transactions that the
> adjustment transaction replaces.
>
> Thus the adjustment transaction is:
>
> - never bigger than the closing and re-opening transactions put together,
> - sometimes smaller, and
> - occasionally significantly smaller.
>
> And there's only one transaction instead of two, so ya always save on
> the transaction header! :-)
>
> Thus, the fee paid for the adjustment transaction, assuming the same fee
> rate for all the transactions, is:
> - never more than the sum of the fees paid for the closing and
> re-opening transactions,
> - sometimes less, and
> - occasionally significantly less.
>
> This reduction in fees is by an additive amount.
>
> Because the channel remains open while waiting for the adjustment
> transaction to confirm, there may be less urgency in having it confirm.
> So it's fee rate can be reduced, reducing the fee paid by a
> multiplicative amount.
>
> Combined, these two effects lead to a reduction in total fees paid for
> operating the channel, sometimes a significant reduction.
>
> Comments expected and welcome.
>
> If this high-level, bare-bones idea is seen to be worthy of further
> consideration, I would like to work with the community to flesh out a
> detailed specification, and, if consensus can be reached on that, to
> participate in the implementation of it.
>
> Jim Renkel
>
> ---------------------------------------------------------------
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171221/38abb23e/attachment-0001.html>