<div dir="ltr"><div>&gt; I think it does already:</div><div><br></div><div>Yep! An oversight on my part.</div><div><br></div><div>&gt; So, you&#39;re suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY?</div><div> </div><div>Precisely. The code modifications required to switch to this signing mode are</div><div>trivial.  </div><div><br></div><div>&gt; though it&#39;s a pretty obscure case where we want to close out many HTLCs at</div><div>&gt; once; this is more for fee bumping I think.</div><div><br></div><div>Well it&#39;s for both. In the case of a commitment transaction broadcast (for what</div><div>ever reason) each party is able to group together HTLC&#39;s expiring around the</div><div>same height (in the case that the pre-image for a bunch was never revealed.</div><div>This leads to less transactions on-chain, and lower fees cumulative for either</div><div>side to sweep all funds back into their primary wallet.</div><div><br></div><div>The fee bumping use case is also a bonus!</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 29, 2017 at 10:36 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">Rusty Russell &lt;<a href="mailto:rusty@rustcorp.com.au" target="_blank">rusty@rustcorp.com.au</a>&gt; writes:<br>
<br>
&gt; <a href="https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing</a><br>
<br>
Some feedback, since I missed what seems like a very productive<br>
discussion!<br>
<br>
&gt; HTLC floor created by second-level HTLC transactions<br>
&gt; Pierre points out that should choose HTLC min high enough that don’t run into issues.<br>
&gt; Laolu points out this means that unable to send and claim small-ish amounts chain.<br>
&gt; Laolu points out that would basically CREATE a dust output in the process.<br>
&gt; LAOLU SUGGESTS THAT TRIM OUTPUT SPEC PORTION SHOULD ALSO SAY DON’T CREATE DUST OUTPUT ON SECOND LEVEL TX<br>
<br>
I think it does already:<br>
<br>
  For every offered HTLC, if the HTLC amount minus the HTLC-timeout fee<br>
  would be less than `dust_limit_satoshis` set by the transaction owner,<br>
  the commitment transaction MUST NOT contain that output<br>
<br>
(Similarly for received HTLCs)<br>
<br>
ie. don&#39;t create HTLC outputs which would need an HTLC tx with a dust<br>
output.<br>
<br>
&gt; Don’t use sighash-all on the second-level HTLC transactions<br>
&gt;   Laolu points out that this would allow us to coalesce many HTLC<br>
&gt;   transactions into a single one. Saves on-chain foot print, and also<br>
&gt;   allows to add more fees.  Basically like “Lighthouse” (by hearn).<br>
<br>
So, you&#39;re suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY?<br>
<br>
I *think* this would work, though it&#39;s a pretty obscure case where we<br>
want to close out many HTLCs at once; this is more for fee bumping I<br>
think.<br>
<br>
There are two other cases where we don&#39;t rely on the TXID, and such an<br>
approach would be possible:<br>
<br>
1. Commitment tx with no HTLC outputs.<br>
2. The closing transaction.<br>
<br>
Cheers,<br>
Rusty.<br>
</blockquote></div>