Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Oleg Andreev <oleganza@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 9 Aug 2021 00:41:32 +0300
Message-Id: <29C08A0C-E9DA-4D9A-B27A-A5479D2B434E@gmail.com>
References: <e22dde6c-9a31-60ae-64d0-5e2ff84a6b79@mattcorallo.com>
In-Reply-To: <e22dde6c-9a31-60ae-64d0-5e2ff84a6b79@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Removing the Dust Limit
Precedence: list

I agree with Jeremy. Dust limit works due to design accident: that outputs a=
re not encrypted. But outputs are private business and the real issue is onl=
y the cost of utxo set storage born by every user. There are two ways to add=
ress this:

1) either make ppl pay for renting that storage (which creates a ton of prob=
lems of its own)
2) or make storage extremely cheap so it remains cheap at any scale. This is=
 perfectly solved by Utreexo.

But looking at the private data because you can is a hack that creates issue=
s of its own.

> On 9 Aug 2021, at 00:16, Matt Corallo via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
>=20
> =EF=BB=BFIf it weren't for the implications in changing standardness here,=
 I think we should consider increasing the dust limit instead.
>=20
> The size of the UTXO set is a fundamental scalability constraint of the sy=
stem. In fact, with proposals like assume-utxo/background history sync it is=
 arguably *the* fundamental scalability constraint of the system. Today's du=
st limit is incredibly low - its based on a feerate of only 3 sat/vByte in o=
rder for claiming the UTXO to have *any* value, not just having enough value=
 to be worth bothering. As feerates have gone up over time, and as we expect=
 them to go up further, we should be considering drastically increasing the 3=
 sat/vByte basis to something more like 20 sat/vB.
>=20
> Matt
>=20
>> On 8/8/21 14:52, Jeremy via bitcoin-dev wrote:
>> We should remove the dust limit from Bitcoin. Five reasons:
>> 1) it's not our business what outputs people want to create
>=20
> It is precisely our business - the costs are born by us, not the creator. I=
f someone wants to create outputs which don't make sense to spend, they can d=
o so using OP_RETURN, since they won't spend it anyway.
>=20
>> 2) dust outputs can be used in various authentication/delegation smart co=
ntracts
>=20
> So can low-value-but-enough-to-be-worth-spending-when-you're-done-with-the=
m outputs.
>=20
>> 3) dust sized htlcs in lightning (https://bitcoin.stackexchange.com/quest=
ions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-thro=
ugh-the-light <https://bitcoin.stackexchange.com/questions/46730/can-you-sen=
d-amounts-that-would-typically-be-considered-dust-through-the-light>) force c=
hannels to operate in a semi-trusted mode which has implications (AFAIU) for=
 the regulatory classification of channels in various jurisdictions; agnosti=
c treatment of fund transfers would simplify this (like getting a 0.01 cent d=
ividend check in the mail)
>=20
> This is unrelated to the consensus dust limit. This is related to the prac=
tical question about the value of claiming an output. Again, the appropriate=
 way to solve this instead of including spendable dust outputs would be an O=
P_RETURN output (though I believe this particular problem is actually better=
 solved elsewhere in the lightning protocol).
>=20
>> 4) thinly divisible colored coin protocols might make use of sats as valu=
e markers for transactions.
>=20
> These schemes can and should use values which make them economical to spen=
d. The whole *point* of the dust limit is to encourage people to use values w=
hich make sense economically to "clean up" after they're done with them. If p=
eople want to use outputs which they will not spend/"clean up" later, they s=
hould be using OP_RETURN.
>=20
>> 5) should we ever do confidential transactions we can't prevent it withou=
t compromising privacy / allowed transfers
>=20
> This is the reason the dust limit is not a *consensus* limit. If and when C=
T were to happen we can and would relax the standardness rules around the du=
st limit to allow for CT.
>=20
>> The main reasons I'm aware of not allow dust creation is that:
>> 1) dust is spam
>> 2) dust fingerprinting attacks
>=20
> 3) The significant costs to every miner and full node operator.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev