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
|
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 17A3BFB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 14:18:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
[209.85.212.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A0B1E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 14:18:57 +0000 (UTC)
Received: by wibz8 with SMTP id z8so100744670wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2015 07:18:56 -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=uHPXlYSR5AHFbjNSt97OaGGQRjw3v0uJ63PWzFfwQ5Q=;
b=urhJxoP9e7w2NgPpExwKXMo3kXFhOwHR+YH6NCc6RG9Wlh7iD8q1A2TfmGG0erzabq
vZLek3fC5SI96se0fTpi0av+Cu9me0iU66rKsSgVjX0jJCshmRW3NsphbGNKxeVEBhbw
xog5kIDFvNDxiAbI9A9CZMyFaQF4fwxKT52BoIHk0UDUINWFFk1Asm7reUVO8Dw8RP+Z
kCrTQWymxNGO1j411Ohm/Kb+B9Z5bpJSbARnw661miavHSD9k3TZLaalVtTfv/ad266s
C+LJTEnGeh9y0lxZe3qyNABXWfX5MYIpFtDE9lsKVuJoBEOhB0WDbRDi+Z/Ae6+kbzbd
AlNg==
MIME-Version: 1.0
X-Received: by 10.180.87.1 with SMTP id t1mr14621548wiz.33.1441289936087; Thu,
03 Sep 2015 07:18:56 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:18:56 -0700 (PDT)
In-Reply-To: <d15669b6ce3dbc89dff6c907a5749034@xbt.hk>
References: <CADm_Wcb+5Xo3HS-FNUYtCapVpYfVvUS_fxpU0Q=TZHJW1=iAFQ@mail.gmail.com>
<d15669b6ce3dbc89dff6c907a5749034@xbt.hk>
Date: Thu, 3 Sep 2015 10:18:56 -0400
Message-ID: <CADm_WcbudZs6_bYfDkQ2XgqvPEMRN4ONnmz45Wz45E06bpGOrQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=f46d044481afa8b019051ed876c2
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:18:58 -0000
--f46d044481afa8b019051ed876c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for the link. I readily admit only having given pay-to-future-miner
a little bit of thought. Not convinced it sets a minimal tx fee in all
cases.
On Thu, Sep 3, 2015 at 12:55 AM, <jl2012@xbt.hk> wrote:
> Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-03 00:05 =E5=AF=AB=E5=88=B0=
:
>
>> Schemes proposing to pay with difficulty / hashpower to change block
>> size should be avoided. The miners incentive has always been fairly
>> straightforward - it is rational to deploy new hashpower as soon as
>> you can get it online. Introducing the concepts of (a) requiring
>> out-of-band collusion to change block size and/or (b) requiring miners
>> to have idle hashpower on hand to change block size are both
>> unrealistic and potentially corrosive. That potentially makes the
>> block size - and therefore fee market - too close, too sensitive to
>> the wild vagaries of the mining chip market.
>>
>> Pay-to-future-miner has neutral, forward looking incentives worth
>> researching.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> Ref:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01072=
3.html
>
> I explained here why pay with difficulty is bad for everyone: miners and
> users, and described the use of OP_CLTV for pay-to-future-miner
>
> However, a general problem of pay-to-increase-block-size scheme is it
> indirectly sets a minimal tx fee, which could be difficult and arbitrary,
> and is against competition
>
>
>
--f46d044481afa8b019051ed876c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for the link.=C2=A0 I readily admit only having giv=
en pay-to-future-miner a little bit of thought.=C2=A0 Not convinced it sets=
a minimal tx fee in all cases.<div><br></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Thu, Sep 3, 2015 at 12:55 AM, <span =
dir=3D"ltr"><<a href=3D"mailto:jl2012@xbt.hk" target=3D"_blank">jl2012@x=
bt.hk</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jeff Garzik v=
ia bitcoin-dev =E6=96=BC 2015-09-03 00:05 =E5=AF=AB=E5=88=B0:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div class=3D"h5">
Schemes proposing to pay with difficulty / hashpower to change block<br>
size should be avoided.=C2=A0 The miners incentive has always been fairly<b=
r>
straightforward - it is rational to deploy new hashpower as soon as<br>
you can get it online.=C2=A0 Introducing the concepts of (a) requiring<br>
out-of-band collusion to change block size and/or (b) requiring miners<br>
to have idle hashpower on hand to change block size are both<br>
unrealistic and potentially corrosive.=C2=A0 That potentially makes the<br>
block size - and therefore fee market - too close, too sensitive to<br>
the wild vagaries of the mining chip market.<br>
<br>
Pay-to-future-miner has neutral, forward looking incentives worth<br>
researching.<br>
<br>
<br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote>
<br>
Ref: <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
5-August/010723.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html</a><br>
<br>
I explained here why pay with difficulty is bad for everyone: miners and us=
ers, and described the use of OP_CLTV for pay-to-future-miner<br>
<br>
However, a general problem of pay-to-increase-block-size scheme is it indir=
ectly sets a minimal tx fee, which could be difficult and arbitrary, and is=
against competition<br>
<br>
<br>
</blockquote></div><br></div>
--f46d044481afa8b019051ed876c2--
|
