Date: Fri, 08 Oct 2021 10:38:50 +0000
To: shymaa arafat <shymaa.arafat@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <R7rqMyBitqJYz8vM37xnRj3OAvTfA4PDZJg3QzTVLNx3nLMeKRUxKNHu49ezhO80N7XeUweFOBeduAeoIUFvEFhjSTfwDltRH4kEdeQ9koE=@protonmail.com>
In-Reply-To: <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com>
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <20210808215101.wuaidu5ww63ajx6h@ganymede>
 <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>
 <CAJowKgKt=yYdNOYYNsWh7FJ2EH7rz0bd2EjUjmyA=cA6k5cvUQ@mail.gmail.com>
 <BtaljKLqpe75GB6pHEPQMF6_L-hBaE0ZCBGaXrUfnHRYeEbCqFWZ12DaMRm5jEADceL3uPfCiL-WU9MOZJ_m54Zi3Pzu0vSFN3nQvuSKvBM=@protonmail.com>
 <CAM98U8nSOQ9HpdRLBdkcFAdToW=z7_EhnYisMb7F46ExmJkT-w@mail.gmail.com>
 <ZKZ4RR6uAv0mG8yFQyRkWDTFQ7JnsGVfLQcMTmsc5ui7MTJXuzMkVk5YQTniPuc4F_KRhn7BEZZHEK60IZYZYU9A1r-tbmfPTnIs0pOd7oU=@protonmail.com>
 <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
 <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
 <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Precedence: list

Good morning shymaa,

> The suggested idea I was replying to is to make all dust TXs invalid by s=
ome nodes.

Is this supposed to be consensus change or not?
Why "some" nodes and not all?

I think the important bit is for full nodes.
Non-full-nodes already work at reduced security; what is important is the s=
ecurity-efficiency tradeoff.

> I suggested a compromise by keeping them in secondary storage for full no=
des, and in a separate Merkle Tree for bridge servers.
> -In bridge servers they won't increase any worstcase, on the contrary thi=
s will enhance the performance even if slightly.
> -In full nodes, and since they will usually appear in clusters, they will=
 be fetched rarely (either by a dust sweeping action, or a malicious attack=
er)
> In both cases as a batch
> -To not exhaust the node with DoS(as the reply mentioned)one may think of=
 uploading the whole dust partition if they were called more than certain t=
hreshold (say more than 1 Tx in a block)=C2=A0=C2=A0
> -and then keep them there for "a while", but as a separate partition too =
to exclude them from any caching mechanism after that block.
> -The "while" could be a tuned parameter.

Assuming you meant "dust tx is considered invalid by all nodes".

* Block has no dust sweep
  * With dust rejected: only non-dust outputs are accessed.
  * With dust in secondary storage: only non-dust outputs are accessed.
* Block has some dust sweeps
  * With dust rejected: only non-dust outputs are accessed, block is reject=
ed.
  * With dust in secondary storage: some data is loaded from secondary stor=
age.
* Block is composed of only dust sweeps
  * With dust rejected: only non-dust outputs are accessed, block is reject=
ed.
  * With dust in secondary storage: significant increase in processing to l=
oad large secondary storage in memory,

So I fail to see how the proposal ever reduces processing compared to the i=
dea of just outright making all dust txs invalid and rejecting the block.
Perhaps you are trying to explain some other mechanism than what I understo=
od?

It is helpful to think in terms always of worst-case behavior when consider=
ing resistance against attacks.

> -Take care that the more dust is sweeped, the less dust to remain in the =
UTXO set; as users are already much dis-incentivised to create more.

But creation of dust is also as easy as sweeping them, and nothing really p=
revents a block from *both* creating *and* sweeping dust, e.g. a block comp=
osed of 1-input-1-output transactions, unless you want to describe some kin=
d of restriction here?

Such a degenerate block would hit your secondary storage double: one to rea=
d, and one to overwrite and add new entries; if the storage is large then t=
he index structure you use also is large and updates can be expensive there=
 as well.


Again, I am looking solely at fullnode efficiency here, meaning all rules v=
alidated and all transactions validated, not validating and simply acceptin=
g some transactions as valid is a degradation of security from full validat=
ion to SPV validation.
Now of course in practice modern Bitcoin is hard to attack with *only* mini=
ng hashpower as there are so many fullnodes that an SPV node would be easil=
y able to find the "True" history of the chain.
However, as I understand it that proporty of fullnodes protecting against a=
ttacks on SPV nodes only exists due to fullnodes being cheap to keep online=
; if the cost of fullnodes in the **worst case** (***not*** average, please=
 stop talking about average case) increases then it may become feasible for=
 miners to attack SPV nodes.

Regards,
ZmnSCPxj