[Lightning-dev] Channel refill

mr. gnosteek gnosteek at gmail.com
Tue May 10 04:48:38 UTC 2016

dear all forward thinking who are near Ukraine,
there gonna be the meeting with Lightning team this Thursday in Kyiv!!!

2016-05-09 23:30 GMT+03:00 Rusty Russell <rusty at rustcorp.com.au>:

> Kumaigorodskiy Anton <anton.kumaigorodskiy at outlook.com> writes:
> > As far as I understand LN has some edge cases such as:
> >
> > -- one can't receive a single payment which is larger than what is
> currently locked in a channel (this is the most limiting one). -- a
> variation of the first case: one can issue a large number of small invoices
> which in total exceed current channel capacity so not all of them could be
> paid. -- obviously one can't make payments once their side of channel
> balance reaches zero.
> >
> > The answer currently is to just open another channel (or transfer
> bitcoins directly) but what if "channel refill" procedure could be
> implemented?
> >
> > It could work almost as "open anchor" procedure but not quite: -- the
> same pair of commit_key's is used resulting in a second utxo on anchor
> address. -- a separate "refill commitment tx" is created which does not
> invalidate current "main commitment tx". -- once on-chain refill tx reaches
> required depth a new "main commitment tx" is created which takes into
> account new utxo and old "main commitment tx" as well as "refill commitment
> tx" are invalidated.
> >
> > One advantage of refill over new channel creation is that overall
> channel capacity would grow each time so after a number of refills no more
> of them may be needed for a long time.
> Yes, this definitely a good idea.  I've been calling it "re-anchoring",
> as it's more general than refilling the channel.  The new funding
> transaction would spend the old one, plus some additional input(s).
> For the duration, signatures are provided for both the old funding
> transaction and the new one.  When the new one is deep enough, the old
> signatures can be dropped.
> This is also how you would pay non-lightning bitcoin addresses: the new
> funding transaction spends the old one, has one output to the address
> and one to the 2of2.
> I imagine reanchoring will be the first extension once we get the basics
> sorted out.
> Thanks!
> Rusty.
> _______________________________________________
> 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/20160510/43505474/attachment.html>

More information about the Lightning-dev mailing list