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

2018-11-05 Thread Olaoluwa Osuntokun
> This seems at odds with the goal of "if the remote party force closes, then > I get my funds back immediately without requiring knowledge of any secret > data" Scratch that: the static back ups just need to include this CSV value! -- Laolu On Tue, Nov 6, 2018 at 3:29 PM Olaoluwa Osuntokun

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

2018-11-05 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Rusty, > > I'm a big fan in general of most of this! Amongst many other things, it'll: > simplify the whole static channel backup + recovery workflow, and avoid all > the fee related headaches we've run into over the past few months. I certainly hope so! >> -

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

2018-11-05 Thread Olaoluwa Osuntokun
Hi Rusty, I'm a big fan in general of most of this! Amongst many other things, it'll: simplify the whole static channel backup + recovery workflow, and avoid all the fee related headaches we've run into over the past few months. > - HTLC-timeout and HTLC-success txs sigs are >

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

2018-10-23 Thread Rusty Russell
Jim Posen writes: > Instead of leaving an extra output for CPFP, is it not sufficient to just > sign all inputs with ANYONECANPAY and expect the sender to make an exact > output for the fees input? It would require an extra tx assuming they don't > already have a properly sized UTXO handy (which

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

2018-10-20 Thread Jim Posen
Instead of leaving an extra output for CPFP, is it not sufficient to just sign all inputs with ANYONECANPAY and expect the sender to make an exact output for the fees input? It would require an extra tx assuming they don't already have a properly sized UTXO handy (which they may!), but I believe

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

2018-10-20 Thread Conner Fromknecht
Good morning everyone, > We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE > for HTLC txs, without adding the "OP_TRUE" > output to the commitment transaction Doesn’t this require a non-zero number of HTLCs on the commitment txn? We would still require the OP_TRUE if there are no HTLCs,

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

2018-10-19 Thread Rusty Russell
Fabrice Drouin writes: > Hello, > >> 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) > > We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without > adding the "OP_TRUE" output to the

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

2018-10-18 Thread Fabrice Drouin
Hello, > 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) We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without adding the "OP_TRUE" output to the commitment transaction. We would still

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] 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()

[Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-11 Thread Rusty Russell
Hi all, There have been a number of suggested changes to the commitment transaction format: 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) 2. The `remotepubkey` should be a BIP-32-style, to avoid the