From rusty at rustcorp.com.au  Fri Nov 27 03:58:25 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Fri, 27 Nov 2015 14:28:25 +1030
Subject: [Lightning-dev] Committing to dust
In-Reply-To: <20151127023807.GA31761@sapphire.erisian.com.au>
References: <20151127023807.GA31761@sapphire.erisian.com.au>
Message-ID: <8737vsrt3y.fsf@rustcorp.com.au>

Anthony Towns <aj at erisian.com.au> writes:
> 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.

Yes, unfortunately we'll have to have a rule to avoid producing those
outputs.

I've opened https://github.com/ElementsProject/lightning/issues/14
so we make sure we track this.

> 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.

Agreed, we'll just cull those outputs and let them go to fees.

Cheers,
Rusty.