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
173
174
175
176
177
178
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3333911A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 14:40:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
[209.85.212.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B61E10B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 14:40:38 +0000 (UTC)
Received: by wicge5 with SMTP id ge5so76395073wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2015 07:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=RTnBX1Lr/s7/OX3UHInyuQ2ZxP/8V5zGb4lgIJEZjBg=;
b=Grb9ELNKmn4ruSSYfngWjnmVkH+mTEMdNG6RrcFc8mfbkyeC54zJUwxopRC35N6T5K
3/7vj2eFbtr3NJ3iSOqj/uzhDq+dFFgav+OLSAqJfmAiXi2tn2djIJQHtZLNNfv7Y3Tv
P9qLVwy3XoxrC+YVVNK2mq9IRGvueq7IKYiItmDZjqX27xG+fYCy0knP/o80erq8s3rM
c2fGJdmqjqevZKZ3vrBe8jfV835Bw1Vcx+w1qbKu5owSYbCaf577Zt8JID3AXZ0Dtmmq
d3hTBxFmej2uP2iPuLRZSJIROqX/2xTnZq4vPtxNM715aOWaVmDbEgSYqRFmfzMLz/ft
XOuA==
MIME-Version: 1.0
X-Received: by 10.194.176.201 with SMTP id ck9mr51027699wjc.108.1441291237173;
Thu, 03 Sep 2015 07:40:37 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:40:37 -0700 (PDT)
In-Reply-To: <CADm_WcYS-zbNFQJ5EPqqkQ5NhgoQNQAgs-SaF_ZZr0QCNFA3_w@mail.gmail.com>
References: <CADm_Wcb+5Xo3HS-FNUYtCapVpYfVvUS_fxpU0Q=TZHJW1=iAFQ@mail.gmail.com>
<CAAS2fgQOi0amBnPK8Ac3iGDN9CP-mLW6o0ncYdSAOAaqSboejg@mail.gmail.com>
<CADm_WcYS-zbNFQJ5EPqqkQ5NhgoQNQAgs-SaF_ZZr0QCNFA3_w@mail.gmail.com>
Date: Thu, 3 Sep 2015 10:40:37 -0400
Message-ID: <CADm_WcYwErO1Av_DkMecATQEMFKL7TNZc1Nbs88k-yEKN2vbsQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e013d1eb435aec8051ed8c49c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] block size - pay with difficulty
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 03 Sep 2015 14:40:39 -0000
--089e013d1eb435aec8051ed8c49c
Content-Type: text/plain; charset=UTF-8
Expanding on pay-with-diff and volatility (closing comment),
Users and miners will have significant difficulty creating and/or
predicting a stable block size (and fee environment) with pay-with-diff
across the months. The ability of businesses to plan is low. Chaos and
unpredictability are bad in general for markets and systems. Thus the
binary conclusion of "not get used" or "volatility"
On Thu, Sep 3, 2015 at 10:31 AM, Jeff Garzik <jgarzik@gmail.com> wrote:
> It's written as 'a' and/or 'b'. If you don't have idle hashpower, then
> paying with difficulty requires some amount of collusion ('a')
>
> Any miner paying with a higher difficulty either needs idle hashpower, or
> self-increase their own difficulty at the possible *opportunity cost* of
> losing an entire block's income to another miner who doesn't care about
> changing the block size. The potential loss does not economically
> compensate for size increase gains in most cases, when you consider the
> variability of blocks (they come in bursts and pauses) and the fee income
> that would be associated.
>
> Miners have more to lose paying with diff than they gain -- unless the
> entire network colludes out-of-band with ~90% certainty, by collectively
> agreeing to increase the block period by collectively agreeing with
> pay-with-diff until the globally desired block size is reached. At that
> level of collusion, we can create far more simple schemes to increase block
> size.
>
> Pay-with-diff will either not get used, or lead to radical short term
> block size (and thus fee) volatility. It is complex & difficult for all
> players to reason, and a Rational game theory choice can be to avoid
> paying-for-diff even when the network desperately needs an upgrade.
>
>
>
>
>
>
> On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
>
>> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > (b) requiring miners to have idle
>> > hashpower on hand to change block size are both unrealistic and
>> potentially
>>
>> I really cannot figure out how you could characterize pay with
>> difficty has in any way involving idle hashpower.
>>
>> Can you walk me through this?
>>
>
>
--089e013d1eb435aec8051ed8c49c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Expanding on pay-with-diff and volatility (closing comment=
),<div><br></div><div>Users and miners will have significant difficulty cre=
ating and/or predicting a stable block size (and fee environment) with pay-=
with-diff across the months.=C2=A0 The ability of businesses to plan is low=
.=C2=A0 Chaos and unpredictability are bad in general for markets and syste=
ms.=C2=A0 Thus the binary conclusion of "not get used" or "v=
olatility"</div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Thu, Sep 3, 2015 at 10:31 AM, Jeff Garzik <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jgarzik@gmail.com" target=3D"_blank">jgarzik@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It=
's written as 'a' and/or 'b'.=C2=A0 If you don't ha=
ve idle hashpower, then paying with difficulty requires some amount of coll=
usion ('a') =C2=A0<div><br><div>Any miner paying with a higher diff=
iculty either needs idle hashpower, or self-increase their own difficulty a=
t the possible <b>opportunity cost</b> of losing an entire block's inco=
me to another miner who doesn't care about changing the block size.=C2=
=A0 The potential loss does not economically compensate for size increase g=
ains in most cases, when you consider the variability of blocks (they come =
in bursts and pauses) and the fee income that would be associated.</div><di=
v><br></div><div>Miners have more to lose paying with diff than they gain -=
- unless the entire network colludes out-of-band with ~90% certainty, by co=
llectively agreeing to increase the block period by collectively agreeing w=
ith pay-with-diff until the globally desired block size is reached.=C2=A0 A=
t that level of collusion, we can create far more simple schemes to increas=
e block size.</div><div><br></div><div>Pay-with-diff will either not get us=
ed, or lead to radical short term block size (and thus fee) volatility.=C2=
=A0 It is complex & difficult for all players to reason, and a Rational=
game theory choice can be to avoid paying-for-diff even when the network d=
esperately needs an upgrade.</div><div><br></div><div><br></div><div><br></=
div><div><br></div><div><br></div></div></div><div class=3D"HOEnZb"><div cl=
ass=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu=
, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"=
mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Sep 3, 2015 at 4=
:05 AM, Jeff Garzik via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> (b) requiring miners to have idle<br>
> hashpower on hand to change block size are both unrealistic and potent=
ially<br>
<br>
</span>I really cannot figure out how you could characterize pay with<br>
difficty has in any way involving idle hashpower.<br>
<br>
Can you walk me through this?<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--089e013d1eb435aec8051ed8c49c--
|
