From gnosteek at gmail.com Tue May 10 04:48:38 2016 From: gnosteek at gmail.com (mr. gnosteek) Date: Tue, 10 May 2016 07:48:38 +0300 Subject: [Lightning-dev] Channel refill In-Reply-To: <874ma70y9t.fsf@rustcorp.com.au> References: <874ma70y9t.fsf@rustcorp.com.au> Message-ID: 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 : > Kumaigorodskiy Anton 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: