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
|
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 4D843F90
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 14:31:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
[209.85.212.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A863D19F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 14:31:32 +0000 (UTC)
Received: by wibz8 with SMTP id z8so101165482wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2015 07:31:31 -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=8Q/pW7fMPKfO2z+pKUP1T5AmOg8PptAbWIJlyTYEGX0=;
b=vhVncPoFbbz74e+J4n1UbaJXraxJJO3niPJv5UAjd4r0cmYJb2Uhmq66m2MvR7QtAt
5zrFzKEsiswbWRaj2O0fCm97uE4YtKsz+ZLG7AzIgnL/+uLAgyrmSq8gtd537wDfwah3
jvO2kM//QwR/Jb3QiNkVVA4K6SuYN/siQFRIv7+R+Kqm4uCH7oZgjiIDS6lG+R7IXWRm
yKSw3ACEdYuxoVzW9RCQ1Av29nWGiA/TrccD5JQhpIKtkUu21B2oQPmJV2c5LHWasIdc
LLi7FcePNjvzMwE8LJ9tw7JGDjA4odQzXIyel+cZKd4kmh8bi119OeVZ1A/neTPcldZl
xmkA==
MIME-Version: 1.0
X-Received: by 10.180.92.138 with SMTP id cm10mr14726162wib.33.1441290691413;
Thu, 03 Sep 2015 07:31:31 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:31:31 -0700 (PDT)
In-Reply-To: <CAAS2fgQOi0amBnPK8Ac3iGDN9CP-mLW6o0ncYdSAOAaqSboejg@mail.gmail.com>
References: <CADm_Wcb+5Xo3HS-FNUYtCapVpYfVvUS_fxpU0Q=TZHJW1=iAFQ@mail.gmail.com>
<CAAS2fgQOi0amBnPK8Ac3iGDN9CP-mLW6o0ncYdSAOAaqSboejg@mail.gmail.com>
Date: Thu, 3 Sep 2015 10:31:31 -0400
Message-ID: <CADm_WcYS-zbNFQJ5EPqqkQ5NhgoQNQAgs-SaF_ZZr0QCNFA3_w@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043be24eae0bc5051ed8a3f3
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:31:33 -0000
--f46d043be24eae0bc5051ed8a3f3
Content-Type: text/plain; charset=UTF-8
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?
>
--f46d043be24eae0bc5051ed8a3f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's written as 'a' and/or 'b'.=C2=A0 =
If you don't have idle hashpower, then paying with difficulty requires =
some amount of collusion ('a') =C2=A0<div><br><div>Any miner paying=
with a higher difficulty either needs idle hashpower, or self-increase the=
ir own difficulty at the possible <b>opportunity cost</b> of losing an enti=
re block's income to another miner who doesn't care about changing =
the block size.=C2=A0 The potential loss does not economically compensate f=
or 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 as=
sociated.</div><div><br></div><div>Miners have more to lose paying with dif=
f than they gain -- unless the entire network colludes out-of-band with ~90=
% certainty, by collectively agreeing to increase the block period by colle=
ctively agreeing with pay-with-diff until the globally desired block size i=
s reached.=C2=A0 At that level of collusion, we can create far more simple =
schemes to increase block size.</div><div><br></div><div>Pay-with-diff will=
either not get used, or lead to radical short term block size (and thus fe=
e) volatility.=C2=A0 It is complex & difficult for all players to reaso=
n, and a Rational game theory choice can be to avoid paying-for-diff even w=
hen the network desperately needs an upgrade.</div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div></div></div><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>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D"">On Thu, Sep 3, 2015 at 4:05 AM, Je=
ff Garzik via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.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>
--f46d043be24eae0bc5051ed8a3f3--
|
