[Lightning-dev] Channel refill

Rusty Russell rusty at rustcorp.com.au
Mon May 9 20:30:54 UTC 2016


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.


More information about the Lightning-dev mailing list