<div dir="ltr">dear all forward thinking who are near Ukraine,<div>there gonna be the meeting with Lightning team this Thursday in Kyiv!!! </div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-09 23:30 GMT+03:00 Rusty Russell <span dir="ltr"><<a href="mailto:rusty@rustcorp.com.au" target="_blank">rusty@rustcorp.com.au</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kumaigorodskiy Anton <<a href="mailto:anton.kumaigorodskiy@outlook.com">anton.kumaigorodskiy@outlook.com</a>> writes:<br>
> As far as I understand LN has some edge cases such as:<br>
><br>
> -- 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.<br>
><br>
> The answer currently is to just open another channel (or transfer bitcoins directly) but what if "channel refill" procedure could be implemented?<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
Yes, this definitely a good idea. I've been calling it "re-anchoring",<br>
as it's more general than refilling the channel. The new funding<br>
transaction would spend the old one, plus some additional input(s).<br>
<br>
For the duration, signatures are provided for both the old funding<br>
transaction and the new one. When the new one is deep enough, the old<br>
signatures can be dropped.<br>
<br>
This is also how you would pay non-lightning bitcoin addresses: the new<br>
funding transaction spends the old one, has one output to the address<br>
and one to the 2of2.<br>
<br>
I imagine reanchoring will be the first extension once we get the basics<br>
sorted out.<br>
<br>
Thanks!<br>
Rusty.<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div><br></div>