📅 Original date posted:2015-11-27
📝 Original message:
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
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:45:16
in reply to nevent1q…utgt
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:45:16Event JSON
{
"id": "232d46a3fe5574739eda3fa8b1ec2457884c26d45884eaec3c0620f45b808d0b",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314716,
"kind": 1,
"tags": [
[
"e",
"977c8b703585b4f8b23fbd30eba547407cce68bd9a239ef06df17deb90c6161f",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2015-11-27\n📝 Original message:\nHey,\n\nSuppose you have a lightning channel, with balances of exactly 2 BTC\non your side, and 1 BTC on the other (and 1mBTC for fees). You send a\nmicropayment of 42 satoshi across the channel, resulting in an updated\ncommitment that looks like:\n\n in:\n anchor (3.001 BTC): [yoursig theirsig redeemscript]\n\n out:\n 1 BTC: [pay2pubkey(theirs)]\n 1.99999958 BTC: [pay2pubkey(yours)]\n 0.00000042 BTC: [pay2scripthash(htlc to them with R or you after\n timeout)]\n\nBut the third output will hit the IsDust() test (less than 546 satoshi\nfor a min relay fee of 0.01 mBTC) and the entire transaction will be\nrejected, so the channel can't be closed at all!\n\nThis is a similar problem to sub 1-satoshi payments, but it's different\nin that while you can't represent them as an HTLC output, you can\nrepresent them as soon as they complete -- ie:\n\n out:\n 1.00000042 BTC: [pay2pubkey(theirs)]\n 1.99999958 BTC: [pay2pubkey(yours)]\n\nis completely legitimate (whereas an output of 1.0 + 0.042e-8 BTC\nwouldn't be).\n\nI assume treating them much the same way is the only real option --\naccount for them exactly in the lightning state, but just approximate the\nresults in the actual commitments. So long as you're closing channels\ninfrequently, losing a few hundred satoshi here and there won't matter\nmuch.\n\nThe important thing is that adding dust to your commitment might mean you\ncan't access _any_ of your funds if your channel counterparty goes AWOL.\nEven though the amount mightn't matter, you can't just treat it like\nany other case in the code.\n\nAnother option might be to weaken the dust protection in the network --\neg if you made the dust output be\n\n 0.00000042 BTC: [(them \u0026\u0026 (R || revoke))\n || (you \u0026\u0026 d CSV \u0026\u0026 t CLTV)\n || (3 months CSV)]\n\nthen anyone could clear the dust after 3 months if it weren't otherwise\nclaimed; maybe having some dust for a finite time is okay. But it'd also\nmean paying to an actual (non-standard) script, rather than a scripthash,\nwhich would be annoying in its own way... And, really, adding that output\nto the txn would probably cost more in additional fees that it's going\nto pay you in any case.\n\nCheers,\naj",
"sig": "fa99dbdb76577a28ddfe688d15a7876b53d612984dcfda55e8b724f02c11d65ee1f9de96ce8fb23bda6a0d7f4bc65a78db50a0c901cde02d8357cab119834ae4"
}