From aj at erisian.com.au  Fri Nov 27 02:38:07 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Fri, 27 Nov 2015 12:38:07 +1000
Subject: [Lightning-dev] Committing to dust
Message-ID: <20151127023807.GA31761@sapphire.erisian.com.au>

Hey,

Suppose you have a lightning channel, with balances of exactly 2 BTC
on your side, and 1 BTC on the other (and 1mBTC for fees). You send a
micropayment of 42 satoshi across the channel, resulting in an updated
commitment that looks like:

  in:
    anchor (3.001 BTC): [yoursig theirsig redeemscript]

  out:
    1 BTC: [pay2pubkey(theirs)]
    1.99999958 BTC: [pay2pubkey(yours)]
    0.00000042 BTC: [pay2scripthash(htlc to them with R or you after
                     timeout)]

But the third output will hit the IsDust() test (less than 546 satoshi
for a min relay fee of 0.01 mBTC) and the entire transaction will be
rejected, so the channel can't be closed at all!

This is a similar problem to sub 1-satoshi payments, but it's different
in that while you can't represent them as an HTLC output, you can
represent them as soon as they complete -- ie:

  out:
    1.00000042 BTC: [pay2pubkey(theirs)]
    1.99999958 BTC: [pay2pubkey(yours)]

is completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC
wouldn't be).

I assume treating them much the same way is the only real option --
account for them exactly in the lightning state, but just approximate the
results in the actual commitments. So long as you're closing channels
infrequently, losing a few hundred satoshi here and there won't matter
much.

The important thing is that adding dust to your commitment might mean you
can't access _any_ of your funds if your channel counterparty goes AWOL.
Even though the amount mightn't matter, you can't just treat it like
any other case in the code.

Another option might be to weaken the dust protection in the network --
eg if you made the dust output be

    0.00000042 BTC: [(them && (R || revoke))
                     || (you && d CSV && t CLTV)
                     || (3 months CSV)]

then anyone could clear the dust after 3 months if it weren't otherwise
claimed; maybe having some dust for a finite time is okay. But it'd also
mean paying to an actual (non-standard) script, rather than a scripthash,
which would be annoying in its own way... And, really, adding that output
to the txn would probably cost more in additional fees that it's going
to pay you in any case.

Cheers,
aj