Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread ZmnSCPxj via Lightning-dev
Good morning laolu, > Hi Z, > > > Probably arguably off-topic, but this post triggered me into thinking > > about an insane idea: offchain update from existing Poon-Dryja to newer > > Decker-Russell-Osuntokun ("eltoo") mechanism. > > Ooo, yeh I don't see why this would be possible assuming at

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Antoine Riard
Hi Laolu, I think that's a must before we introduce a bunch of new features and the number of channels explodes. The de-synchronized side could be underscored more as any scheduled, automatic, massive upgrade for security forcing chain writes can be exploited to launch mempool-congestion

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Olaoluwa Osuntokun
Hi Z, > Probably arguably off-topic, but this post triggered me into thinking > about an insane idea: offchain update from existing Poon-Dryja to newer > Decker-Russell-Osuntokun ("eltoo") mechanism. Ooo, yeh I don't see why this would be possible assuming at that point no_input has been

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Olaoluwa Osuntokun
> Note that this is already possible today, a node can unilaterally decide its internal rules for accepting channels/HTLCs. Mhmm, it's possible today but would generate extra failures vs knowing what all the limits are ahead of time. > I prefer that alternative. I think it's better to explicitly

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Olaoluwa Osuntokun
After getting some feedback from the Lightning Labs squad, we're thinking that it may be better to make the initial switch over double-opt-in, similar to the current `shutdown` message flow. So with this variant, we'd add two new messages: `commit_switch` and `commit_switch_reply` (placeholder

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread ZmnSCPxj via Lightning-dev
Good morning Laolu, and list, Probably arguably off-topic, but this post triggered me into thinking about an insane idea: offchain update from existing Poon-Dryja to newer Decker-Russell-Osuntokun ("eltoo") mechanism. Due to the way `SIGHASH_ANYPREVOUT` will be deployed --- requires a new

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Bastien TEINTURIER via Lightning-dev
Thanks for sharing this, I think it's the right time to start experimenting with that kind of feature (especially in the light of Taproot and the package relay work / pinning transactions issue). we can start to experiment with flow-control like > ideas such as limiting a new channel peer to only