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
|
Return-Path: <dermoth@aei.ca>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E1682486
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 23:27:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail001.aei.ca (mail001.aei.ca [206.123.6.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0D7A473
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 23:27:40 +0000 (UTC)
Received: (qmail 11238 invoked by uid 89); 22 Aug 2017 23:27:39 -0000
Received: by simscan 1.2.0 ppid: 11233, pid: 11235, t: 0.0065s
scanners: regex: 1.2.0 attach: 1.2.0
Received: from mail002.aei.ca (HELO mail002.contact.net) (206.123.6.132)
by mail001.aei.ca with (DHE-RSA-AES256-SHA encrypted) SMTP;
22 Aug 2017 23:27:39 -0000
Received: (qmail 21448 invoked by uid 89); 22 Aug 2017 23:27:39 -0000
Received: by simscan 1.2.0 ppid: 21387, pid: 21395, t: 8.5879s
scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.97.8/m: spam: 3.3.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28)
X-Spam-Level:
X-Spam-Status: No, hits=-3.0 required=5.0 tests=ALL_TRUSTED,BAYES_00
autolearn=ham autolearn_force=no version=3.4.1
Received: from dsl-66-36-135-64.mtl.aei.ca (HELO ?192.168.67.200?)
(dermoth@66.36.135.64)
by mail.aei.ca with ESMTPA; 22 Aug 2017 23:27:31 -0000
To: Daniele Pinna <daniele.pinna@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAEgR2PGiP8yom+q-XDPgeoUsJnVfUgVFPx7nvWcpDFqBkm8MBQ@mail.gmail.com>
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
Message-ID: <afba8b41-4391-fd10-beb5-c236d44c55c9@aei.ca>
Date: Tue, 22 Aug 2017 19:27:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAEgR2PGiP8yom+q-XDPgeoUsJnVfUgVFPx7nvWcpDFqBkm8MBQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 23 Aug 2017 01:44:33 +0000
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 22 Aug 2017 23:27:41 -0000
On 22/08/17 06:17 PM, Daniele Pinna via bitcoin-dev wrote:
> Also.... how is this not a tax on coin holders? By forcing people to
> move coins around you would be chipping away at their wealth in the
> form of extorted TX fees.=20
> =20
As if the fee for one tx per decade (or more if we'd like) matters, plus
it could be very low priority. In fact we could re-allow free
transactions based on old priority rules (oldest outputs gets higher
priority... I would suggest considering reduction in utxo size as well
but that's another topic).
Actually, to ensure miners allow these transaction one rule could be
that the block must contain free transactions on old utxo's ("old" TBD)
to reclaim from the scavenged pool... One side effect is that mining
empty blocks before previous block TX can be validated would reduce the
reward.
I'd love to find clever approach where we could somehow make a
verifiable block check that old tx refresh are included... I haven't put
much thoughts into it yet but if there was a way a two-step transaction
where 1. a fee is paid to register an UTXO refresh (miners would be
encouraged to accept it and increase their immediate revenue), and 2.
the fee must be returned from the pool on a later block. The idea is to
allow free scavenging of own addresses while discouraging miners from
refusing free transactions so they could eventually reclaim the coins. I
can't think of a way that limits the burden on consensus rules...
--=20
Thomas
|
