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
|
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 03731117D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 04:05:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7AD6213D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 04:05:13 +0000 (UTC)
Received: by wibz8 with SMTP id z8so84827495wib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 02 Sep 2015 21:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=+gpsOxr3skKJBlTavoZH6YVNVzOXMcdHSGQkqmEajaU=;
b=BfPLnu7VYW/bLYiLYAXyCfnYx4EA3//E6aEXHnUIRKbrTQ3R7/PZVYoEAtllI4ClBD
d4p+qf22pfNKiZUZgkqomzvewnv5PYXEa8CJ0DZzvXolGd3ZnI+07iWGUAog4RNsD8x1
SX3uoSBrJXqgGCCOfiMU9FjtJIKGOsdLCUKVYi2UtIEv42VSkIXHuMuiBZxMz4uFhfhG
8F67cJbb4AK0vUsqAwYloUjQH+P7CaxOn35EJ3OGbIQW7K1+d2P6O2MEy6AX2c5NJT2s
6KUUMJaSymVs/sYWaCKwQtT1sB9Z5MfdJfcY8jZ4W6MQ8bwZdOGuXp8bC1AUwGtfKkLI
apUA==
MIME-Version: 1.0
X-Received: by 10.180.92.138 with SMTP id cm10mr10011683wib.33.1441253112028;
Wed, 02 Sep 2015 21:05:12 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Wed, 2 Sep 2015 21:05:11 -0700 (PDT)
Date: Thu, 3 Sep 2015 00:05:11 -0400
Message-ID: <CADm_Wcb+5Xo3HS-FNUYtCapVpYfVvUS_fxpU0Q=TZHJW1=iAFQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f46d043be24ec622e6051ecfe3b9
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
Subject: [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 04:05:14 -0000
--f46d043be24ec622e6051ecfe3b9
Content-Type: text/plain; charset=UTF-8
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.
--f46d043be24ec622e6051ecfe3b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Schemes proposing to pay with difficulty / hashpower to ch=
ange block size should be avoided.=C2=A0 The miners incentive has always be=
en fairly straightforward - it is rational to deploy new hashpower as soon =
as you can get it online.=C2=A0 Introducing the concepts of (a) requiring o=
ut-of-band collusion to change block size and/or (b) requiring miners to ha=
ve idle hashpower on hand to change block size are both unrealistic and pot=
entially corrosive.=C2=A0 That potentially makes the block size - and there=
fore fee market - too close, too sensitive to the wild vagaries of the mini=
ng chip market.<div><br></div><div>Pay-to-future-miner has neutral, forward=
looking incentives worth researching.</div><div><br></div><div><br></div><=
/div>
--f46d043be24ec622e6051ecfe3b9--
|
