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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Return-Path: <shum@canndrew.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5B308C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 15:24:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 3E96A204FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 15:24:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id yuxBkmb19j4n
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 15:24:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from canndrew.org (canndrew.org [199.167.29.165])
by silver.osuosl.org (Postfix) with ESMTPS id 95A7825B04
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Mar 2020 15:23:12 +0000 (UTC)
Received: from shum by canndrew.org with local (Exim 4.84_2)
(envelope-from <shum@canndrew.org>)
id 1jH7ry-0000vG-4e; Wed, 25 Mar 2020 11:23:02 -0400
Date: Wed, 25 Mar 2020 11:23:02 -0400
From: Andrew Cann <shum@canndrew.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <20200325152302.GA3355@canndrew.org>
References: <PS2P216MB0179EC99BDE0E3388F2627F89DF30@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
<F713CAAC-1997-4645-A166-57358E520594@voskuil.org>
<CAGLBAhdTMbZPwqV9YLMyHdNzLbN2DLjiOe6cBUbkwR_x4cGRmQ@mail.gmail.com>
<20200323125922.GA29881@canndrew.org>
<CAGLBAhcUgTEWnraFem0YwODc61B4nwbzddHJtE0D7ZCjUNWfYg@mail.gmail.com>
<C_qo1AhQuklVr4owEXVgLXsvJomb9Usd1NP2zf_D_23r6Cmz9-iB7ygSfNihJp3FIfAf4c1P41fT3qQP7SFiKdCfXxpogcstHsOnpgLgbok=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ"
Content-Disposition: inline
In-Reply-To: <C_qo1AhQuklVr4owEXVgLXsvJomb9Usd1NP2zf_D_23r6Cmz9-iB7ygSfNihJp3FIfAf4c1P41fT3qQP7SFiKdCfXxpogcstHsOnpgLgbok=@protonmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Thu, 26 Mar 2020 04:32:22 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
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: Wed, 25 Mar 2020 15:24:16 -0000
--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi, thanks for the replies.
> Anyway, yes, your idea is fundamentally broken because a zero block reward
> happens because creating even one more satoshi will push the amount of
> bitcoin over 21,000,0000, breaking the meaning of "bitcoin," or, if you
> like, creating a fundamental contradiction in our use of the term.=20
I wouldn't really consider that fundamentally broken. It changes the meanin=
g of
"bitcoin", but so does every upgrade to the protocol. The worst problem I c=
an
see with this is that there's probably a lot of software out there which
assumes a cap of 21M. But we'd have years to find and fix those bugs.
> They already do so, via an implicit "field", known as the transaction fee.
> This makes the vote for how much security is needed to be costly to the
> voter, which is appropriate: you pay for your security.
This isn't the same thing though, economically / game-theoretically speakin=
g.
Transaction fees are only paid when bitcoins get moved. There's no on-going
cost for people holding bitcoins (assuming they're doing their day-to-day
transactions almost entirely off-chain, which is something that's only goin=
g to
become more common). More to the point, the transaction fee is only set by =
the
current demand for block space. If transaction fees drop too low to maintai=
n a
secure hash rate then people *could* willingly pay more than they need to to
get their transactions mined, but it's unlikely they will since it'd be che=
aper
to just pay the minimum and hope that everyone else covers the costs of kee=
ping
the network secure for them.
With the voting idea everyone decides what everyone pays (via dilution) to =
keep
the network secure. Choosing to signal a high inflation rate doesn't mean y=
ou
pay more than everyone else, just that you might shift the median, so there=
's
no tragedy-of-the-commons problem. Also, votes are weighted by the value of
the utxo, so people both vote and pay in proportion to the amount of bitcoin
they're holding.
Does this make sense? Or is there some game-theoretic reason I'm not seeing=
for
why transaction fees can never drop dangerously low in the first place?
- Andrew
--lrZ03NoBR/3+SXJZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJee3dVAAoJEJQq94U5BTTOII4QALov5cydHP1EA307fCQqbRwh
mpsFDLWXAoh2HdMnW55/eJ75gzZBV1hvWhOeJGwNEatzfnfusKMwpbFTxH+H7CDo
1fjuRKLE0he9taQoMm5Wbjk/zeiDhDuW51Uah+b19aOhYt8GsTH5z2oX7lAyt0jZ
itUU1IS0prWYq+54DgyiLe5e0v3PlTzKfe2/+gl5sayrQ+42WMy5ohY6BiQC8/VB
xO1r34HkcEUNbqkg1wL0PDUPShpZ2Fq6f2UbpVecXS1GvV6dmBE2u+TQPM5qOMBr
IhqxMZtsxjlmuv8Ty2isNacfxggM1rvKo4HM1JKqvyhvBuaCD/oNImO788YTS0M+
GKS4YlUbYrT8OcZ1riBiv3D97M0kr6ClXokhGO0fXHRmo8Hu6mrnqbrnzQ6FiSfx
ancongHNBbgm+xWhbe10k1liz1ztUTXAkFaBnK6oT2LfgU48MHzNgxsMBgeSU/5+
vmA44M37QC+V2wCYS/fLqG4rT+A77dTnxwPWBo4Zt+akjXvEcNXjzQ/PH+mAnH3d
BtD4Qz820o6QF4xHXLDWSniMFZ3a9fW/MOd0mhj/rEHIF6FcYH6NLkhcTUi+jMyy
CkNoAse3PuvsQciDSCMY3ddyQJbjlzoSBity5sQEbdH1onHm5lLlJpij3zcqoElT
gkWclt8G7ToH7fUZYLAn
=Q003
-----END PGP SIGNATURE-----
--lrZ03NoBR/3+SXJZ--
|
