[Lightning-dev] Minutes of Dev Meeting 2017-07-10

Rusty Russell rusty at rustcorp.com.au
Sun Jul 30 05:36:32 UTC 2017


Rusty Russell <rusty at rustcorp.com.au> writes:

> https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing

Some feedback, since I missed what seems like a very productive
discussion!

> HTLC floor created by second-level HTLC transactions 
> Pierre points out that should choose HTLC min high enough that don’t run into issues.
> Laolu points out this means that unable to send and claim small-ish amounts chain. 
> Laolu points out that would basically CREATE a dust output in the process.
> LAOLU SUGGESTS THAT TRIM OUTPUT SPEC PORTION SHOULD ALSO SAY DON’T CREATE DUST OUTPUT ON SECOND LEVEL TX

I think it does already:

  For every offered HTLC, if the HTLC amount minus the HTLC-timeout fee
  would be less than `dust_limit_satoshis` set by the transaction owner,
  the commitment transaction MUST NOT contain that output

(Similarly for received HTLCs)

ie. don't create HTLC outputs which would need an HTLC tx with a dust
output.

> Don’t use sighash-all on the second-level HTLC transactions
>   Laolu points out that this would allow us to coalesce many HTLC
>   transactions into a single one. Saves on-chain foot print, and also
>   allows to add more fees.  Basically like “Lighthouse” (by hearn).

So, you're suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY?

I *think* this would work, though it's a pretty obscure case where we
want to close out many HTLCs at once; this is more for fee bumping I
think.

There are two other cases where we don't rely on the TXID, and such an
approach would be possible:

1. Commitment tx with no HTLC outputs.
2. The closing transaction.

Cheers,
Rusty.


More information about the Lightning-dev mailing list