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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 792D1C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:42:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 7558B883C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:42:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id p73b5pvWHrxP
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:42:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by whitealder.osuosl.org (Postfix) with ESMTPS id 1B1318839C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Mar 2020 01:42:25 +0000 (UTC)
Date: Thu, 26 Mar 2020 01:42:22 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1585186943;
bh=RZ09mybsArqgz+uTSVRWlZuwmngMSuWd+OgR/8Fse78=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=d9vk49joksbT5f/GLoRJVvAXxLBZHg6mnphIvvuMshoQc/jIJOgLNgMV8tcH9Tg1U
5kXcf70R4ifQi8zCgdQ79+78H3iiLzMGnXbK4sueEqmmeHJaPgraSCgyaNjAiXg9NV
LeRucN5alJ40/s2d/wmhye418ebt6IHJbA5L0H8U=
To: Andrew Cann <shum@canndrew.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <v1t2DhGSHFng23jy0XTRkoVJrhA_6x_QuHFWdrcxQnMS8Sdcbe7eksRtvjf6JCb8YLoHf2W5y29j3XbBIVfDALSBjoiMqxPUWKsQyGLOR_A=@protonmail.com>
In-Reply-To: <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>
<20200325152302.GA3355@canndrew.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Thu, 26 Mar 2020 01:42:28 -0000
Good morning Andrew,
>
> > Anyway, yes, your idea is fundamentally broken because a zero block rew=
ard
> > 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.
>
> I wouldn't really consider that fundamentally broken. It changes the mean=
ing of
> "bitcoin", but so does every upgrade to the protocol. The worst problem I=
can
> 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.
There are changes of meaning, and then there are changes of meaning.
Smaller changes that puny humans can understand are better than larger chan=
ges beyond the ken of mortal man.
To change the supply is far too big a change.
> > They already do so, via an implicit "field", known as the transaction f=
ee.
> > 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 speak=
ing.
> Transaction fees are only paid when bitcoins get moved. There's no on-goi=
ng
> cost for people holding bitcoins (assuming they're doing their day-to-day
> transactions almost entirely off-chain, which is something that's only go=
ing to
> become more common). More to the point, the transaction fee is only set b=
y the
> current demand for block space. If transaction fees drop too low to maint=
ain a
> secure hash rate then people could willingly pay more than they need to t=
o
> get their transactions mined, but it's unlikely they will since it'd be c=
heaper
> to just pay the minimum and hope that everyone else covers the costs of k=
eeping
> the network secure for them.
>
> With the voting idea everyone decides what everyone pays (via dilution) t=
o keep
> the network secure. Choosing to signal a high inflation rate doesn't mean=
you
> pay more than everyone else, just that you might shift the median, so the=
re'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 bitc=
oin
> they're holding.
>
> Does this make sense? Or is there some game-theoretic reason I'm not seei=
ng for
> why transaction fees can never drop dangerously low in the first place?
What happens if I own a few million Bitcoin and then accidentally lose my p=
rivate keys in a tragic ear-cleaning accident?
Then the vote of that UTXO containing a few million Bitcoins will remain fo=
rever fixed and unable to change according to whatever you believe would ma=
ke us as a community decide to change the inflation rate.
If you enforce that only "recently-created" UTXOs get to vote, then in orde=
r for me to affect the vote (in the happy case where I do **not** lose all =
my privkeys in a tragic ear-cleaning accident), I would have to make a synt=
hetic self-paying transaction.
How is it so different from me having to make up a synthetic transaction in=
order to pay fees and thus affect the current security of the blockchain?
--
It is helpful to remember that as a UTXO gets buried deeper, its security i=
s inevitably better, and once I have a sufficient level of security in my o=
wnership of the coin, I will not particularly care about any improved secur=
ity and will not be interested in paying for more, hence why should I suppo=
rt any fork which makes me pay for my security continuously when I can simp=
ly support a fork that retains the current supply and does *not* make me pa=
y for continued security?
--
If I want to *spend* my Bitcoins on something --- and nothing has value unt=
il I actually utilize it --- then I *will* pay transaction fees.
The receiver of the coin would want to ensure that the received UTXO is dee=
ply buried to the point that it has sufficient security for the receiver, b=
efore releasing or providing me with whatever I am exchanging the coin for.
Thus, if I find that there are no miners at all, I could offer a high fee t=
o get my transaction mined.
Of course, you might say that this only pays for one block.
But in most cases I will have more value remaining beyond what I spend to t=
he receiver, i.e. I have a change output from that transaction.
In such a case, I can pay for more blocks by re-spending the change output=
to myself, paying a transaction fee each time, until the original transact=
ion that spends to the receiver is deeply buried and the receiver credits i=
t and then releases the product or service I am exchanging *for*.
Alternately the receiver can do the same for its *own* UTXO, and will incre=
ase the payment it demands from me in order to perform this itself; thus I =
still end up paying for the security of the *transaction* and not the secur=
ity of the *holding*.
So there is really no need for any mechanism beyond transaction fees.
Regards,
ZmnSCPxj
|