<div dir="ltr">Hello Rusty. Exciting stuff!  A few observations:<div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 12:18 AM Rusty Russell &lt;<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
### Confirming a splice: `splice_confirm`<br>
<br>
1. type: 43 (`splice_confirm`) (`option_splice`)<br>
2. data:<br>
   * [`32`:`channel_id`]<br>
   * [`64`:`signature`]<br>
   * [`2`:`num_witnesses`]<br>
   * [`num_witnesses*witness_stack`]<br>
<br></blockquote><div><br></div><div>I don&#39;t believe that you need the `signature` field here; if I&#39;m understanding correctly the sigs for the inputs should be the witness stack that you&#39;re sending.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The sender:<br></blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  - MUST ensure it will have sufficient funds post-splice above its<br>
    reserve to pay for the splice transaction at the new feerate.<br></blockquote><div><br></div><div>If fees outstrip the value of the updated splice transaction, what then? It&#39;s not really possible to abandon a splice, practically you&#39;d end up closing the channel. This feels like an obvious observation, but worth noting that splicing is &#39;risky&#39; in that regard i.e. channel closure due to extenuating circumstances (fee spike).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Message Changes During Splicing<br>
-------------------------------<br>
Once you&#39;ve sent `splice_confirm` each commitment transaction is needs<br>
to be duplicated for every splice transaction (thanks to RBF, there can<br>
be multiple at once).  These are in rbf-received order (increasing fee<br>
order, if initiator is spec compliant):<br><br></blockquote><div>Are HTLC&#39;s to be duplicated as well? CPFP seems like a neater construction than RBF in this case, as it avoids fee rate negotiation and ballooning HTLC/commitment txn management. It also makes the single-payer for fees (initiator) less burdensome which is nice for skewed benefit updates. We can reuse the scheme we came up with for commitment txns (either party can spend, I believe). </div><div><br></div><div>Was there an argument against using CPFP on funding txns that I&#39;m not remembering? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
NOTES:<br>
<br>
1. I suggest that the option_data_loss_protect fields MUST BE set here if<br>
   option_splice (there&#39;s no reason not to AFAICT).  Or do we want to try TLV<br>
   here?<br></blockquote><div> </div><div>+1 for moving to TLV, in the spirit of moving towards the new spec guidelines.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<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></div>