From: shymaa arafat <shymaa.arafat@gmail•com>
To: yanmaani@cock•li,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
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
Date: Sun, 13 Feb 2022 15:11:18 +0200 [thread overview]
Message-ID: <CAM98U8kK9Q82o2-5MeVs2seqqTtYix6h7mBsN9LFUH8ppUzDEA@mail.gmail.com> (raw)
In-Reply-To: <021d90632551c45fa7093d503f1bd793@cock.li>
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 2714 bytes --]
next prev parent reply other threads:[~2022-02-13 13:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-06 12:41 shymaa arafat
2022-02-06 17:39 ` Pieter Wuille
2022-02-06 19:14 ` Eric Voskuil
2022-02-07 14:34 ` Billy Tetrud
2022-02-07 16:51 ` shymaa arafat
2022-02-13 9:56 ` yanmaani
2022-02-13 13:11 ` shymaa arafat [this message]
[not found] ` <382073c28af1ec54827093003cbec2cc@willtech.com.au>
[not found] ` <CAM98U8mJvYcBur01Z32TS4RYW+jMDCVQAUtrg5KXF+50d0zirA@mail.gmail.com>
2022-02-13 5:19 ` shymaa arafat
2022-02-18 3:36 ` ZmnSCPxj
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=CAM98U8kK9Q82o2-5MeVs2seqqTtYix6h7mBsN9LFUH8ppUzDEA@mail.gmail.com \
--to=shymaa.arafat@gmail$(echo .)com \
--cc=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=yanmaani@cock$(echo .)li \
/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