Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-27 📝 Original message: Anthony Towns <aj at ...
📅 Original date posted:2015-11-27
📝 Original message:
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.
📝 Original message:
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.