From ZmnSCPxj at protonmail.com Fri May 5 04:58:11 2017 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 05 May 2017 00:58:11 -0400 Subject: [Lightning-dev] Channel top-up In-Reply-To: <87y3ucdnxz.fsf@rustcorp.com.au> References: <87y3ucdnxz.fsf@rustcorp.com.au> Message-ID: <3bRLhkGHycrJ8XM8iW-7fdEfsjQb4Jv2OlDfiwoH25-wH1T2zP1C2sjGF0Q8H4dLFh1FqMGLuacMoBKekuvKJVm2L9JCVcUs3AHewFaSabc=@protonmail.com> Good morning Rusty, >ZmnSCPxj via Lightning-dev >writes: >> Good morning people, >> >> I want to propose, the addition of a new operation (and related messages) to the Lightning Network protocol. > >Hi, > >Yes, we call this re-anchoring. The same method can be used for >adding or removing funds from the channel, by mutual cooperation. It >has the additional merit that (once deeply confirmed) you can forget >revocation information for any older commitment transactions. > >It was omitted from the 1.0 spec because we have more than enough in >there already. I understand. >But your solution seems overly complex? A or B can simply propose a new >funding transaction which spends the current one, both sides exchange >all the output signatures for a new commitment transaction which uses >that, then exchange signatures for the new funding transaction. I'm sorry my poor understanding of complexity. My thought, was that this simply allows an onion-route payment to be started on-chain. Then normal onion-route messages (update_fulfill_htlc etc) can be used. Basically, my idea, if onion route code already exists, we just modify this a little by allowing an onion-route to start on-chain rather than on-Lightning. The onion route can still remain terminated into a Lightning node. So we need new message to allow onion route to be initiated on-chain/off-LN, but the rest of the onion-route uses the same, already-tested code. Originally, I thought similarly to the splice-in/splice-out/reanchoring scheme. But I thought it would be more complex to add new message types to consider reanchoring. >Even if the new funding tx isn't confirmed yet, they can continue to use >the channel as normal. > >(FWIW, Christian Decker was the one who pointed out how elegant this >is). If the funding tx will only output (i.e. only reduce money on the channel), it's OK. If the funding tx will input (increase money on the channel), then we need to confirm a pre-splice-in transaction. Then the reanchoring tx can be made safely "floating", although since the pre-splice-in tx has a timelock, we should still anchor the reanchoring tx before the pre-splice-in transaction's timelock ends. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: