path: root/57/81b03dd1a0c3f254184747a2c052708f0a6695

Return-Path: <shymaa.arafat@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0CA65C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Feb 2022 13:11:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id EDCCF401F8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Feb 2022 13:11:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 0SiLbG1QTm8g
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Feb 2022 13:11:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com
 [IPv6:2a00:1450:4864:20::634])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 7AD8B40119
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Feb 2022 13:11:32 +0000 (UTC)
Received: by mail-ej1-x634.google.com with SMTP id p15so32167035ejc.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 13 Feb 2022 05:11:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=lld8k2cUY9jaOy5xVYHrZ+Vl37+H75SuB8qiBBEveT4=;
 b=gQkCsi5LAldufSgOpxjZSyhJwfweaAz9zjdoFMiCwGBLF2jKm6CCvrJcpTSUEUe7sw
 k+M4A3cp8cprsKHKpuzSqlWc8sAyLqvT7vDH2HhN9lOcP2ZpZHsEUUkZ5rMVY08EJrkf
 VoJKZzVllb0u2lF0IZCYbg+OU7396CHx7i+qrhV350BXd7DeXQTI6TVASQM4710TOMv/
 0dCcVk7XHOBd/YPu6jvOCmHK7J3uuwp9j3uvnidsNjiy7sKScu6UkxGKEk7HGDTgjCIi
 S+kzmDbChr78DQgSA8tK6fvytE0XN3CpdUHoUTRCVfc9I/ZxZnTcI/NvhfxyGQOY0i8Z
 b/fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=lld8k2cUY9jaOy5xVYHrZ+Vl37+H75SuB8qiBBEveT4=;
 b=AFisnvMa6fFxAb4QAoP0mY2C6GQLkVKMvhJqjgJh98O45s4rrs3J/OMoga45Q0fTSh
 XW4me0F6zoGWWOHkm7YUhyJmgISYBuzMxhFY+1GqEfyfGfLagtc8Z4ZQGE2Qpp62cmd2
 VdOVCRoaM+lHaOGYAERjzC/wzXTzTJSJFQs/XvG1pF6zjy/od5Elx9KRgzF0A62ALHwp
 6fA+4aqf2vGmm7YlObepnJxsQ1x3BLdsAI1nsgIPgZxDFf0Gj280+yuVrKl807iZ0K8s
 WgTnE7nICkGdWxDBznmJMefpecvqudZEzG1rzWlGVIMkrqmEvhZ7bBOOB44qS4DZw8Sj
 Qnvw==
X-Gm-Message-State: AOAM531IRROB2SEBIE1fru6AmJajLVGqmL5q+njsy6fTfAOZvaY2EcTv
 0lGu9+SRJJkREIb/04OGzkXv5pu40rqieBo48W8=
X-Google-Smtp-Source: ABdhPJza+jLPggAxzKlAkCszFEPac9T2/q2QQqidHUKB8ppo0xrtiTM9/fM8rSMkMy/6P0Rj0z4OA9IX81agL2UZOAk=
X-Received: by 2002:a17:906:60d5:: with SMTP id
 f21mr8082335ejk.482.1644757890428; 
 Sun, 13 Feb 2022 05:11:30 -0800 (PST)
MIME-Version: 1.0
References: <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>
 <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org>
 <CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com>
 <021d90632551c45fa7093d503f1bd793@cock.li>
In-Reply-To: <021d90632551c45fa7093d503f1bd793@cock.li>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Sun, 13 Feb 2022 15:11:18 +0200
Message-ID: <CAM98U8kK9Q82o2-5MeVs2seqqTtYix6h7mBsN9LFUH8ppUzDEA@mail.gmail.com>
To: yanmaani@cock.li, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ccf23005d7e609d4"
X-Mailman-Approved-At: Sun, 13 Feb 2022 17:31:03 +0000
Cc: Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] A suggestion to periodically destroy (or remove
 to secondary storage for Archiving reasons) dust, Non-standard UTXOs,
 and also detected burn
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Feb 2022 13:11:34 -0000

--000000000000ccf23005d7e609d4
Content-Type: text/plain; charset="UTF-8"

Are you big  Developers aware of what is said in this thread
https://bitcointalk.org/index.php?topic=5385559.new#new
That "Omni" ALT coin, and all Alt coins and new protocols do create such
extensive amount of dust that they are thinking of dividing 1 Satoshi to
fractions or how to accept a UTXO with 0 value????
Isn't that almost the definition of non-standard transactions; the famous
2016 email?
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html



On Sun, Feb 13, 2022, 13:02 yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2022-02-07 14:34, Billy Tetrud via bitcoin-dev wrote:
> > I do think that UTXO set size is something that will need to be
> > addressed at some point. I liked the idea of utreexo or some other
> > accumulator as the ultimate solution to this problem.
>
> What about using economic incentives to disincentivize the creation of
> new UTXOs? Currently, the fee is only charged per byte of space. What if
> you instead charged a fee of (bytes*byte_weight +
> net_utxos*utxo_weight)? For example, if utxo_weight=500, then a
> transaction that creates 2 new UTXOs would cost as if it were 1 KB in
> size. And a transaction that consolidated 2 UTXOs into one might even
> get a negative transaction fee (rebate).
>
> Technologically, you'd implement this by lowering the block size cap by
> max(0, net_utxos_created*utxo_weight). That would be a soft fork, if
> maybe a contentious one. It's probably also a good idea to limit it at
> 0, separate from consensus issues, because it means you're not
> guaranteed to get back whatever you put into it.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000ccf23005d7e609d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Are you big=C2=A0 Developers aware of what is said in thi=
s thread<div dir=3D"auto"><a href=3D"https://bitcointalk.org/index.php?topi=
c=3D5385559.new#new">https://bitcointalk.org/index.php?topic=3D5385559.new#=
new</a></div><div dir=3D"auto">That &quot;Omni&quot; ALT coin, and all Alt =
coins and new protocols do create such extensive amount of dust that they a=
re thinking of dividing 1 Satoshi to fractions or how to accept a UTXO with=
 0 value????</div><div dir=3D"auto">Isn&#39;t that almost the definition of=
 non-standard transactions; the famous 2016 email?</div><div dir=3D"auto"><=
a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/=
012715.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-M=
ay/012715.html</a></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br><=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Sun, Feb 13, 2022, 13:02 yanmaani--- via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2022-=
02-07 14:34, Billy Tetrud via bitcoin-dev wrote:<br>
&gt; I do think that UTXO set size is something that will need to be<br>
&gt; addressed at some point. I liked the idea of utreexo or some other<br>
&gt; accumulator as the ultimate solution to this problem.<br>
<br>
What about using economic incentives to disincentivize the creation of <br>
new UTXOs? Currently, the fee is only charged per byte of space. What if <b=
r>
you instead charged a fee of (bytes*byte_weight + <br>
net_utxos*utxo_weight)? For example, if utxo_weight=3D500, then a <br>
transaction that creates 2 new UTXOs would cost as if it were 1 KB in <br>
size. And a transaction that consolidated 2 UTXOs into one might even <br>
get a negative transaction fee (rebate).<br>
<br>
Technologically, you&#39;d implement this by lowering the block size cap by=
 <br>
max(0, net_utxos_created*utxo_weight). That would be a soft fork, if <br>
maybe a contentious one. It&#39;s probably also a good idea to limit it at =
<br>
0, separate from consensus issues, because it means you&#39;re not <br>
guaranteed to get back whatever you put into it.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ccf23005d7e609d4--