public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: shymaa arafat <shymaa.arafat@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Date: Wed, 18 Aug 2021 21:06:30 +0200	[thread overview]
Message-ID: <CAM98U8m9=D115g-wHuVsVcSP6z7Q0EqNt0bbQKFo00ZZx0QR1g@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

Dear Sir,

I'm not discussing the dust limit here, but I'm suggesting some mitigations
to the dust problem which tackles almost the same points mentioned here
especially the scalability of the UTXOS set and the corresponding Merkle
proofs/witnesses in Utreexo or any similar design ....
.
I suggest:
1-Dust UTXOS, along with burned & non-standard UTXOS, to be stored
separately in secondary storage; their Hashes in a separate Merkle too in
any accumulator design
(an earlier draft of the idea
https://bitcointalk.org/index.php?topic=5343748.new#new)
.
-In fact, the idea of separating the real UTXO values was first suggested in
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
In their words
"Similarly, one can think of a two-tier data structure where a UTXO subset
containing UTXOs with a low probability of being selected such as dust is
kept on disk, while the other UTXOs are kept in memory."
.
2-I suggest also that existing dust UTXOS (from the same paper, in some
cases a UTXO could be added as an extra input with the cost of 68*fee/byte)
, to be selected with large UTXO whenever they fit in a spending ( use one
large & one small to get rid of the small)
.
3-In general when user is not willing to leave the dust to the fee, and if
there's no dust UTXOS, do not let the coin selection algorithm select the
closest match; let it choose the smallest that doesn't create dust.
For example if there's UTXOS 0.00013 & 0.00012 and user want to spend
0.0001198 choose 0.00013 so that the change is not dust (with same cost).
.
Thank you for your time,
This is the first time I send a suggestion to your emailing list, so sorry
if I missed any regulations
.
Shymaa M. Arafat

[-- Attachment #2: Type: text/html, Size: 2501 bytes --]

             reply	other threads:[~2021-08-18 19:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 19:06 shymaa arafat [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-08-08 18:52 [bitcoin-dev] Removing the Dust Limit Jeremy
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
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

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='CAM98U8m9=D115g-wHuVsVcSP6z7Q0EqNt0bbQKFo00ZZx0QR1g@mail.gmail.com' \
    --to=shymaa.arafat@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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