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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Yshov-00009Y-T1
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 01:20:18 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.181 as permitted sender)
client-ip=209.85.214.181; envelope-from=pieter.wuille@gmail.com;
helo=mail-ob0-f181.google.com;
Received: from mail-ob0-f181.google.com ([209.85.214.181])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YshoV-0002IK-2M
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 01:19:51 +0000
Received: by obfe9 with SMTP id e9so43034826obf.1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 18:19:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.16.161 with SMTP id h1mr1389046obd.49.1431566385693;
Wed, 13 May 2015 18:19:45 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 18:19:45 -0700 (PDT)
In-Reply-To: <CACq0ZD7qF0oEYHfQFxLMn3OOD=ibVAfE-U5YURLrtmWVMzDpgQ@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
<CABm2gDoQ-atjWKB0c6AC1ZQ9fy22ceFtHHwpLmnX8DLW4DAgYA@mail.gmail.com>
<CACq0ZD4_zxhm=qWrP+Nr+fQER4s2R8i7qRjX4HsBWN46uOP2MA@mail.gmail.com>
<CAPg+sBjxXe0spytGsP1BUzNZhJFDYu_yacdhTy5F+O-X8EG7NQ@mail.gmail.com>
<CACq0ZD7qF0oEYHfQFxLMn3OOD=ibVAfE-U5YURLrtmWVMzDpgQ@mail.gmail.com>
Date: Wed, 13 May 2015 18:19:45 -0700
Message-ID: <CAPg+sBjs_y6Q7YAQjH1vd=WaRvObp+yuv-OcFFjg6umQ2=UCMQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Aaron Voisine <voisine@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2fbe0e448d505160085af
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YshoV-0002IK-2M
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 01:20:18 -0000
--001a11c2fbe0e448d505160085af
Content-Type: text/plain; charset=ISO-8859-1
On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <voisine@gmail.com> wrote:
> Conservative is a relative term. Dropping transactions in a way that is
> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
> increasing the blocksize, drastic as it is, is the more conservative choice.
>
Transactions are already being dropped, in a more indirect way: by people
and businesses deciding to not use on-chain settlement. That is very sad,
but it's completely inevitable that there is space for some use cases and
not for others (at whatever block size). It's only a "things don't fit
anymore" when you see on-chain transactions as the only means for doing
payments, and that is already not the case. Increasing the block size
allows for more utility on-chain, but it does not fundamentally add more
use cases - only more growth space for people already invested in being
able to do things on-chain while externalizing the costs to others.
> I would recommend that the fork take effect when some specific large
> supermajority of the pervious 1000 blocks indicate they have upgraded, as a
> safer alternative to a simple flag date, but I'm sure I wouldn't have to
> point out that option to people here.
>
That only measures miner adoption, which is the least relevant. The
question is whether people using full nodes will upgrade. If they do, then
miners are forced to upgrade too, or become irrelevant. If they don't, the
upgrade is risky with or without miner adoption.
--
Pieter
--001a11c2fbe0e448d505160085af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <span dir=
=3D"ltr"><<a href=3D"mailto:voisine@gmail.com" target=3D"_blank">voisine=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Conservati=
ve is a relative term. Dropping transactions in a way that is unpredictable=
to the sender sounds incredibly drastic to me. I'm suggesting increasi=
ng the blocksize, drastic as it is, is the more conservative choice.</div><=
/blockquote><div><br></div><div>Transactions are already being dropped, in =
a more indirect way: by people and businesses deciding to not use on-chain =
settlement. That is very sad, but it's completely inevitable that there=
is space for some use cases and not for others (at whatever block size). I=
t's only a "things don't fit anymore" when you see on-cha=
in transactions as the only means for doing payments, and that is already n=
ot the case. Increasing the block size allows for more utility on-chain, bu=
t it does not fundamentally add more use cases - only more growth space for=
people already invested in being able to do things on-chain while external=
izing the costs to others.<br>=A0<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div class=3D"gmail_extra">I would recommend that the fork take effect when =
some specific large supermajority of the pervious 1000 blocks indicate they=
have upgraded, as a safer alternative to a simple flag date, but I'm s=
ure I wouldn't have to point out that option to people here.</div></blo=
ckquote><div><br></div><div>That only measures miner adoption, which is the=
least relevant. The question is whether people using full nodes will upgra=
de. If they do, then miners are forced to upgrade too, or become irrelevant=
. If they don't, the upgrade is risky with or without miner adoption.<b=
r><br>-- <br></div><div>Pieter<br><br></div></div></div></div>
--001a11c2fbe0e448d505160085af--
|
