From rusty at rustcorp.com.au Tue Oct 23 10:43:26 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 23 Oct 2018 21:13:26 +1030 Subject: [Lightning-dev] Commitment Transaction Format Update Proposals? In-Reply-To: References: <87in2769wc.fsf@rustcorp.com.au> <87woqn4qnq.fsf@rustcorp.com.au> <0trii6U1G6DP2SAYk75X14oPcS51ZDUJTst7xycABfWTzSB62fpx0LQ5gRR3wfbRUgIIC98_XoTYHDUz4RH97qSODlWTvJU3bX1-q8tXN5Q=@protonmail.com> <87o9by4knd.fsf@rustcorp.com.au> <87va5ycj54.fsf@rustcorp.com.au> Message-ID: <87pnw1c59t.fsf@rustcorp.com.au> 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 they may!), but I believe > CPFP would require that as well. Am I missing something? Yeah, that would change the txid which the HTLC txs rely on :( > I'm a fan of the symmetric delays because it simplifies the game theory > analysis, but I don't think the delays need to be the same for both > participants (max of `to_self_delay` for both sides), just that the delay > is applied equally regardless of who publishes the commitment tx. Like your > `to_self_delay` can be what I specify and vice versa, what's the reason for > taking the max? If you don't take the max, you're back into the Game Theory. Your delay is short, mine is long, so I want you to drop to chain please. Also, there's a fairness argument: if you want me to suffer a long delay, you should too. Cheers, Rusty.