This operation is called splice in/out, or clopen transaction. There's some information here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000696.html
Cheers, Dario On Wed, Dec 20, 2017 at 9:52 PM, Jim Renkel <jim.ren...@comcast.net> wrote: > 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 to 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
