Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-12 Thread Rusty Russell
ZmnSCPxj writes: > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Friday, October 12, 2018 2:36 PM, Rusty Russell > wrote: > >> ZmnSCPxj zmnsc...@protonmail.com writes: >> >> > Good morning Rusty and list, >> > >> > > 1. Rather than trying to agree on what fees

Re: [Lightning-dev] Proposal for syncing channel updates

2018-10-12 Thread Fabrice Drouin
Hi Zmn, > It may be reduced to a set reconciliation problem if we consider the > timestamp and enable/disable state of channel updates as part of an item, > i.e. a channel update of 111:1:1 at 2018-10-04 state=enabled is not the same > as a channel update of 111:1:1 at 2018-10-05

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-12 Thread ZmnSCPxj via Lightning-dev
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, October 12, 2018 2:36 PM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Good morning Rusty and list, > > > > > 1. Rather than trying to agree on what fees will be in the future, we > > >

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-12 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty and list, > >> >> 1. Rather than trying to agree on what fees will be in the future, we >> should use an OP_TRUE-style output to allow CPFP (Roasbeef) >> > > My understanding is that this would require some base-layer changes at > Bitcoin level first?

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-12 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty and list, > > 1. Rather than trying to agree on what fees will be in the future, we > should use an OP_TRUE-style output to allow CPFP (Roasbeef) > My understanding is that this would require some base-layer changes at Bitcoin level first? At minimum IsStandard()

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-12 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > > > It may be good to start brainstorming possible failure modes during splice, > > and how to recover, and also to indicate the expected behavior in the > > proposal, as I believe these will be the points where splicing must be > > designed most precisely. What happens