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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <zooko@zooko.com>) id 1SY9On-00016k-92
for bitcoin-development@lists.sourceforge.net;
Sat, 26 May 2012 05:18:45 +0000
X-ACL-Warn:
Received: from zim.maski.org ([173.230.137.215])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1SY9Om-0003vm-1s
for bitcoin-development@lists.sourceforge.net;
Sat, 26 May 2012 05:18:45 +0000
Received: from mail-lpp01m010-f47.google.com (mail-lpp01m010-f47.google.com
[209.85.215.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
(No client certificate requested) (Authenticated sender: zooko)
by zim.maski.org (Postfix) with ESMTPSA id 5BB2722DAE
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 May 2012 05:03:17 +0000 (UTC)
Received: by lags15 with SMTP id s15so1517876lag.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 25 May 2012 22:03:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.26.165 with SMTP id m5mr601166lbg.15.1338008595664; Fri,
25 May 2012 22:03:15 -0700 (PDT)
Received: by 10.112.49.65 with HTTP; Fri, 25 May 2012 22:03:15 -0700 (PDT)
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
References: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
Date: Fri, 25 May 2012 23:03:15 -0600
Message-ID: <CANdZDc7+_xBH0DhujnXbh7gVB603qMQdQ7yOO5qq3HEfsJ2Lpw@mail.gmail.com>
From: "Zooko Wilcox-O'Hearn" <zooko@zooko.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1SY9Om-0003vm-1s
Subject: Re: [Bitcoin-development] Punishing empty blocks?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 26 May 2012 05:18:45 -0000
For what it is worth, I question whether this is a problem. Or, I
guess I question whether the best solution to it isn't for people to
start including more transaction fees. In fact, I'm not entirely sure
that this problem doesn't actually *encourage* people to that
solution, which would be very good if true.
I would be more comfortable if the reward for mining were more
commensurate with the value it provides. Ultimately, of course, that
means that each transaction fee would have to be more of a proportion
of the value *to the spender* of that transaction being included in
the blockchain.
(Aside: in order to convey to outsiders that miners are providing a
useful service rather than gaining undeserved reward for wasting
electricity, I refer to them as "distributed transaction verification
servers" rather than "miners" whenever possible.)
I'm pretty sure that =E2=80=94 assuming there isn't some Bitcoin-killing
disaster =E2=80=94 transaction fees will eventually rise, but sooner might =
be
better, especially with the first coinbase-halving looming.
Perhaps people will be motivated to include transaction fees if they
know that some miners don't bother to validate their transactions and
others do. They may feel motivated to reward the miners that are
serving them and punish the ones that are not. (Note: this wouldn't be
a valid strategy on their part from a strictly game-theoretic
perspective, but if they act on those motivations, then I don't care
if it was rational or not.)
Also, they may decide that they want to counteract the added delay
which those no-transactions miners are adding to *all* transactions
(with or without fee), by putting a fee on their transactions in order
to make them take less long when they are processed by a miner which
does process (some) transactions.
Already this visualization, which I typically glance at a few times a
day, usually shows a good separation with fee-included transactions
sometimes doing much better than (some) free transactions:
http://bitcoinstats.org/
However, this graph shows that the aggregate reward to the miners for
processing transaction is minimal:
http://blockchain.info/charts/transaction-fees?timespan=3D60days&showDataPo=
ints=3Dfalse&daysAverageString=3D1&show_header=3Dtrue&scale=3D0&address=3D
You can see from the first visualization (assuming it is showing the
typical pattern that I've seen) how you risk greater delay by sending
your transaction without fees. The no-transactions miners push *all*
transactions, fee or no-fee to the right. This may incentivize more
people to change their transactions from red diamonds into blue
circles, in order to move their transactions further to the left, even
though the no-transactions miners are not currently discriminating
among the two types.
Therefore, the presence of those miners may help push the aggregate
fees in that latter graph up, which is something I would very much
like to see.
Regards,
Zooko
|
