📅 Original date posted:2021-08-21
📝 Original message:
Good morning Jeremy,
> one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me):
>
> the argument can be reduced to:
>
> - dust limit is a per-node relay policy.
> - it is rational for miners to mine dust outputs given their cost of maintenance (storing the output potentially forever) is lower than their immediate reward in fees.
> - if txn relaying nodes censor something that a miner would mine, users will seek a private/direct relay to the miner and vice versa.
> - if direct relay to miner becomes popular, it is both bad for privacy and decentralization.
> - therefore the dust limit, should there be demand to create dust at prevailing mempool feerates, causes an incentive to increase network centralization (immediately)
>
> the tradeoff is if a short term immediate incentive to promote network centralization is better or worse than a long term node operator overhead.
Against the above, we should note that in the Lightning spec, when an output *would have been* created that is less than the dust limit, the output is instead put into fees.
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs
Thus, the existence of a dust limit encourages L2 protocols to have similar rules, where outputs below the dust limit are just given over as fees to miners, so the existence of a dust limit might very well be incentivize-compatible for miners, regardless of centralization effects or not.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:03:20
in reply to nevent1q…gfgd
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:03:20Event JSON
{
"id": "1aa681d35b1b6cf19592b5abb0acd462c002e603976634c6b9494e93f3aee229",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315800,
"kind": 1,
"tags": [
[
"e",
"b41c7f5be0f6c2276459cf421fc852a8fb9e49b32919a16a29ba72db1840cfc7",
"",
"root"
],
[
"e",
"aaf3aeee24e79bd89d1c4cda139c71369a55120dbebbc0fb38f690ff161d3ff3",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2021-08-21\n📝 Original message:\nGood morning Jeremy,\n\n\u003e one interesting point that came up at the bitdevs in austin today that favors remove that i believe is new to this discussion (it was new to me):\n\u003e\n\u003e the argument can be reduced to:\n\u003e\n\u003e - dust limit is a per-node relay policy.\n\u003e - it is rational for miners to mine dust outputs given their cost of maintenance (storing the output potentially forever) is lower than their immediate reward in fees.\n\u003e - if txn relaying nodes censor something that a miner would mine, users will seek a private/direct relay to the miner and vice versa.\n\u003e - if direct relay to miner becomes popular, it is both bad for privacy and decentralization.\n\u003e - therefore the dust limit, should there be demand to create dust at prevailing mempool feerates, causes an incentive to increase network centralization (immediately)\n\u003e\n\u003e the tradeoff is if a short term immediate incentive to promote network centralization is better or worse than a long term node operator overhead.\n\nAgainst the above, we should note that in the Lightning spec, when an output *would have been* created that is less than the dust limit, the output is instead put into fees.\nhttps://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#trimmed-outputs\n\nThus, the existence of a dust limit encourages L2 protocols to have similar rules, where outputs below the dust limit are just given over as fees to miners, so the existence of a dust limit might very well be incentivize-compatible for miners, regardless of centralization effects or not.\n\n\nRegards,\nZmnSCPxj",
"sig": "29c2c87e67f1327da9cade74ae7f41ea78cabd7bcfca1faa83fea83ef6c34b139d7b07da0b1aeefe667e90bb58e010cbd5b133972301b09c0f8c6e7f5e85e5e3"
}