<div dir="ltr"><div>Hi Rusty, </div><div><br></div><div>I&#39;m a big fan in general of most of this! Amongst many other things, it&#39;ll:</div><div>simplify the whole static channel backup + recovery workflow, and avoid all</div><div>the fee related headaches we&#39;ve run into over the past few months.</div><div><br></div><div>&gt; - HTLC-timeout and HTLC-success txs sigs are </div><div>&gt; SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.</div><div><br></div><div>Would this mean that we no longer extend fees to the second-level</div><div>transactions as well? If so, then a dusty HTLC would be determined solely by</div><div>looking at the direct output, rather than the resulting output in the second</div><div>layer.</div><div><br></div><div>&gt;  - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`,</div><div>&gt; `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a</div><div>&gt; two-stage unhardened BIP-32 derivation based on the commitment number.</div><div><br></div><div>It seems enough to _only_ modify the derivation for local+remote pubkey (so</div><div>the direct &quot;settle&quot; keys). This constrains the change to only what&#39;s</div><div>necessary to simplify the backup+recovery workflow with the current</div><div>commitment design. By restricting the change to these two keys, we minimize</div><div>the code impact to the existing implementations, and avoid unnecessary</div><div>changes that don&#39;t make strides towards the immediate goal.</div><div><br></div><div>&gt; - `to_remote` is now a P2WSH of:</div><div>&gt;        `to_self_delay` OP_CSV OP_DROP &lt;remotepubkey&gt; OP_CHECKSIG</div><div><br></div><div>This seems at odds with the goal of &quot;if the remote party force closes, then</div><div>I get my funds back immediately without requiring knowledge of any secret</div><div>data&quot;. If it was just a plain p2wkh, then during a routine seed import and</div><div>rescan (assuming ample look ahead as we know this is a &quot;special&quot; key), I</div><div>would pick up outputs of channels that were force closed while I was down</div><div>due to my dog eating my hard drive. </div><div><br></div><div>Alternatively, since the range of CSV values can be known ahead of time, I</div><div>can brute force a set of scripts to look for in the chain. However, this</div><div>results in potentially a very large number of scripts (depending on how many</div><div>channels one has, and bounds on the acceptable CSV) I need to scan for.</div><div><br></div><div>-- Laolu</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018 at 3:57 PM Rusty Russell &lt;<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
        There have been a number of suggested changes to the commitment<br>
transaction format:<br>
<br>
1. Rather than trying to agree on what fees will be in the future, we<br>
   should use an OP_TRUE-style output to allow CPFP (Roasbeef)<br>
2. The `remotepubkey` should be a BIP-32-style, to avoid the<br>
   option_data_loss_protect &quot;please tell me your current<br>
   per_commitment_point&quot; problem[1]<br>
3. The CLTV timeout should be symmetrical to avoid trying to game the<br>
   peer into closing. (Connor IIRC?).<br>
<br>
It makes sense to combine these into a single `commitment_style2`<br>
feature, rather than having a testing matrix of all these disabled and<br>
enabled.<br>
<br>
BOLT #2:<br>
<br>
- If `commitment_style2` negotiated, update_fee is a protocol error.<br>
<br>
This mainly changes BOLT #3:<br>
<br>
- The feerate for commitment transactions is always 253 satoshi/Sipa.<br>
- Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi.<br>
- Fees, OP_TRUE are always paid by the initial funder, because it&#39;s simple,<br>
  unless they don&#39;t have funds (eg. push_msat can do this, unless we remove it?)<br>
- HTLC-timeout and HTLC-success txs sigs are <br>
  SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.<br>
- `localpubkey`, `remotepubkey`, `local_htlcpubkey`,<br>
  `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey`<br>
  derivation now uses a two-stage unhardened BIP-32 derivation based on<br>
  the commitment number.  Two-stage because we can have 2^48 txs and<br>
  BIP-32 only supports 2^31: the first 17 bits are used to derive the<br>
  parent for the next 31 bits?<br>
- `to_self_delay` for both sides is the maximum of either the<br>
  `open_channel` or `accept_channel`.<br>
- `to_remote` is now a P2WSH of:<br>
        `to_self_delay` OP_CSV OP_DROP &lt;remotepubkey&gt; OP_CHECKSIG<br>
<br>
Cheers,<br>
Rusty.<br>
<br>
[1] I recently removed checking this field from c-lightning, as I<br>
    couldn&#39;t get it to reliably work under stress-test.  I may just have<br>
    a bug, but we could just fix the spec instead, then we can get our<br>
    funds back even if we never talk to the peer.<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div>