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"
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
Precedence: list

--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--