From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 75CD2C000E for ; Wed, 18 Aug 2021 19:06:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 55AF560BC9 for ; Wed, 18 Aug 2021 19:06:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9F-a9Ea1pGG for ; Wed, 18 Aug 2021 19:06:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by smtp3.osuosl.org (Postfix) with ESMTPS id 2EE9960746 for ; Wed, 18 Aug 2021 19:06:43 +0000 (UTC) Received: by mail-pf1-x436.google.com with SMTP id k19so3150579pfc.11 for ; Wed, 18 Aug 2021 12:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JfBgb2+P+/5zGELhwAsIe0YF49GQpZDlC5N/2O/hBK0=; b=SZHTKFqilFNCBWgLGI8i1fQzCYlZgRZs1m8W1esLz1eDiiXI6uVXnufDgZHHo2J7Ev ioYaa2JBaHDLnSUX3noG0LuCCzrdU6e0+SDY0WvTs6u4ZBLj0SXIW/X5y3mEU470I9om e7IZfOrxjHm2ln9mjiMi9IMhPb1jfC1S+fCEhtjkVNhEQNArAXVaR4TE8thAXusefYaN W/HYcCfI7GqCrbx+26zu4uyQoYs7pD7BKfXIBj2686dFBYK9uoj30lsThtUa+bwmnZs2 /0aEAAtMOAbAAO/kggkSmTXrtGcf6ar7Ml6B5mX4fX9vMIIAw2y6a7JcWmBxHITedL1s 67Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JfBgb2+P+/5zGELhwAsIe0YF49GQpZDlC5N/2O/hBK0=; b=tsTVAmxszpl0sLV0lmycD8dLk/OuLq+QpSs7lZaauaROFWPqNJMeTP2/6FnsOtjsLe BoZnS8AMeHHHnScwY+4+ydohcrCQAO5gyFkK7iF8Az7ba4zAmmVRAXjG3fbfHxREgS3a eONbbcz3tre1xLIDw5CtklxvEkrJorDsfG072XM5O5pnT/Ux5rkek/AFqsYKnoctIWIt zvE5sYqlmQFfd/JNxAY32geo6V/7PAkxEyF+X/78scN7mauFq2D5DnJNCiv2YyehJRzZ e4vxmLtCfLyMu7nRRXKXoVap3zLQcA0LjQ54Zgw+MlTEso+J7Rgw/UFZU0YsF7fiV+8S o8mg== X-Gm-Message-State: AOAM530C+UW+ylnZYzYKeb1NnC5fwjV2r6Hzz32xqVEufo0NKTog6YNi B4pDY0ARIp2elRTHEv3/axD06pYrBcMRUnnldzgPJ+Zj X-Google-Smtp-Source: ABdhPJyqCPQA54+ISWuzyrWqgvqeCnPXa65VPUPrV9xpbZlzg9hLFCdgY5uV55nIVhm/i/0KmUOzk9O0BssGqrRgLLs= X-Received: by 2002:a63:3501:: with SMTP id c1mr10152847pga.280.1629313602545; Wed, 18 Aug 2021 12:06:42 -0700 (PDT) MIME-Version: 1.0 From: shymaa arafat Date: Wed, 18 Aug 2021 21:06:30 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="00000000000081e9ad05c9da2247" X-Mailman-Approved-At: Wed, 18 Aug 2021 20:52:43 +0000 Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 19:06:47 -0000 --00000000000081e9ad05c9da2247 Content-Type: text/plain; charset="UTF-8" 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 --00000000000081e9ad05c9da2247 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Sir,

I&= #39;m not discussing the dust limit here, but I'm suggesting some mitig= ations to the dust problem which tackles almost the same points mentioned h= ere especially the scalability of the UTXOS set and the corresponding Merkl= e proofs/witnesses in Utreexo or any similar design ....
.
I suggest:
1-Dust UTXO= S, along with burned & non-standard UTXOS, to be stored separately in s= econdary storage; their Hashes in a separate Merkle too in any accumulator = design
(an earlier draft of the idea
= .
-In fact, the idea of separating the real UTXO val= ues was first suggested in
In their words
"Similarly, one can think of a two-tier data structure where a UTX= O 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 d= ust UTXOS (from the same paper, in some cases a UTXO could be added as an e= xtra input with the cost of 68*fee/byte) , to be selected with large UTXO w= henever they fit in a spending ( use one large & one small to get rid o= f the small)
.
3-In general w= hen user is not willing to leave the dust to the fee, and if there's n= o dust UTXOS, do not let the coin selection algorithm select the closest ma= tch; let it choose the smallest that doesn't create dust.
For example if there's UTXOS 0.00013 & 0.00012 and user w= ant to spend 0.0001198 choose 0.00013 so that the change is not dust (with = same cost).
.
Thank you for y= our time,
This is the first time I send a suggestion= to your emailing list, so sorry if I missed any regulations
.
Shymaa M. Arafat
=
--00000000000081e9ad05c9da2247--