From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: shymaa arafat <shymaa.arafat@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Date: Fri, 08 Oct 2021 10:38:50 +0000 [thread overview]
Message-ID: <R7rqMyBitqJYz8vM37xnRj3OAvTfA4PDZJg3QzTVLNx3nLMeKRUxKNHu49ezhO80N7XeUweFOBeduAeoIUFvEFhjSTfwDltRH4kEdeQ9koE=@protonmail.com> (raw)
In-Reply-To: <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com>
Good morning shymaa,
> The suggested idea I was replying to is to make all dust TXs invalid by some 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 security-efficiency tradeoff.
> I suggested a compromise by keeping them in secondary storage for full nodes, and in a separate Merkle Tree for bridge servers.
> -In bridge servers they won't increase any worstcase, on the contrary this 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 attacker)
> 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 threshold (say more than 1 Tx in a block)
> -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 rejected.
* With dust in secondary storage: some data is loaded from secondary storage.
* Block is composed of only dust sweeps
* With dust rejected: only non-dust outputs are accessed, block is rejected.
* With dust in secondary storage: significant increase in processing to load large secondary storage in memory,
So I fail to see how the proposal ever reduces processing compared to the idea of just outright making all dust txs invalid and rejecting the block.
Perhaps you are trying to explain some other mechanism than what I understood?
It is helpful to think in terms always of worst-case behavior when considering 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 prevents a block from *both* creating *and* sweeping dust, e.g. a block composed of 1-input-1-output transactions, unless you want to describe some kind of restriction here?
Such a degenerate block would hit your secondary storage double: one to read, and one to overwrite and add new entries; if the storage is large then the 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 validated and all transactions validated, not validating and simply accepting some transactions as valid is a degradation of security from full validation to SPV validation.
Now of course in practice modern Bitcoin is hard to attack with *only* mining hashpower as there are so many fullnodes that an SPV node would be easily able to find the "True" history of the chain.
However, as I understand it that proporty of fullnodes protecting against attacks 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
next prev parent reply other threads:[~2021-10-08 10:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-08 18:52 [bitcoin-dev] " Jeremy
2021-08-08 21:14 ` Matt Corallo
2021-08-08 21:41 ` Oleg Andreev
2021-08-08 21:51 ` [bitcoin-dev] [Lightning-dev] " David A. Harding
2021-08-08 22:46 ` Jeremy
2021-08-08 23:07 ` Jeremy
2021-09-30 22:07 ` Pieter Wuille
2021-10-01 13:40 ` Erik Aronesty
2021-10-07 4:52 ` ZmnSCPxj
2021-10-07 8:17 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 8:34 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 10:35 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-07 9:13 ` shymaa arafat
2021-10-07 10:01 ` ZmnSCPxj
[not found] ` <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com>
[not found] ` <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com>
2021-10-08 7:44 ` shymaa arafat
2021-10-08 10:38 ` ZmnSCPxj [this message]
2021-10-08 22:47 ` ZmnSCPxj
2021-08-09 13:22 ` Antoine Riard
2021-08-10 0:30 ` Billy Tetrud
2021-08-10 5:04 ` Jeremy
2021-08-10 5:44 ` Billy Tetrud
2021-08-10 11:37 ` ZmnSCPxj
2021-08-10 18:39 ` Charlie Lee
2021-08-10 6:14 ` David A. Harding
2021-08-10 22:37 ` Antoine Riard
2021-08-11 0:46 ` ZmnSCPxj
2021-08-12 22:03 ` Anthony Towns
2021-08-20 4:51 ` Jeremy
2021-08-20 5:45 ` shymaa arafat
2021-08-21 3:10 ` ZmnSCPxj
2021-08-26 21:21 ` Billy Tetrud
2021-08-27 9:07 ` shymaa arafat
2021-08-30 3:31 ` LORD HIS EXCELLENCY JAMES HRMH
2021-08-18 19:06 shymaa arafat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='R7rqMyBitqJYz8vM37xnRj3OAvTfA4PDZJg3QzTVLNx3nLMeKRUxKNHu49ezhO80N7XeUweFOBeduAeoIUFvEFhjSTfwDltRH4kEdeQ9koE=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=shymaa.arafat@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox