1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
Return-Path: <yanmaani@cock.li>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id F164BC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Feb 2022 10:06:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id DD43640339
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Feb 2022 10:06:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.309
X-Spam-Level:
X-Spam-Status: No, score=-1.309 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, RDNS_NONE=0.793,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=cock.li
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id luAR_UInXssp
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Feb 2022 10:06:49 +0000 (UTC)
X-Greylist: delayed 00:10:17 by SQLgrey-1.8.0
Received: from mail.cock.li (unknown [37.120.193.123])
by smtp4.osuosl.org (Postfix) with ESMTPS id 3F4C84030C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Feb 2022 10:06:49 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
t=1644746182; bh=kEz43TpJG/bLmiYv+/wWL10yDJf10mzn703Phyt0aFM=;
h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
b=CF7fmHvFtnHfv8srOTiFSp/4+comJIcCbBBbwdTPvCgl9j//6dnbYTNTZkwEuhO64
VvZg6rsPqJ/K1W8lsTkv6hF4oFUq4SqzU+R66owAe9UZuGE1P8Vt50vMTkdjq7avQ/
jxhmdG3iG0g3az5Zfp2oNoM1NKv3TXG9fFYsAlthiH7E/JV+4dPqDMDdBcN/zVP00o
br9A51wDLCHMVaDj1jli5HP+Ajewoieztlq4PUZwfwJvYkmQAR5mt1WLradOMgEfcD
f9gfwzEAdObas2CslazX7RBAAMGfRKTeMroAL75AkgyGcuZXvmVTM+WDZICXsRsmrG
/fc8UvGxHY1Lw==
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 13 Feb 2022 09:56:21 +0000
From: yanmaani@cock.li
To: Billy Tetrud <billy.tetrud@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com>
References: <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>
<86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org>
<CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com>
Message-ID: <021d90632551c45fa7093d503f1bd793@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.17
X-Mailman-Approved-At: Sun, 13 Feb 2022 11:02:06 +0000
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 10:06:52 -0000
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.
|
