summaryrefslogtreecommitdiff
path: root/8c/cfaf3d7fdbc9f7d59f7f6b7c7f94fecacb1568
blob: 7b163505260a8a2cfe8ed677a0079ea0cdd2c192 (plain)
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
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B22B480
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 14:05:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com
	[209.85.215.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C72F17B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 14:05:36 +0000 (UTC)
Received: by lagw2 with SMTP id w2so25793598lag.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 07:05:35 -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=RB0PBnsdOkPvPvzfNp+daDJgVhdvONz0tlh4W3xLxhY=;
	b=ShaylUrvYIRsV1o46mVKdMjj1cPALh7LikY7qkkUhqIxJG415anP1dOFL/sobXeF49
	NMNEOfSyq4vbTH4jHe6BDosyDxkd9feOj7mc527o0Gcrsm4JOv04HI9omj6CSJgLZ0Uz
	pgmmBWURHfW0g/5DW3R84r9G8pm+s62wVSqPCfaJePHvmXChgThkvYScqq9f4iwxsmDx
	2BiySPT4ElnbSZhcwd6v14M0OcoQS5+ErV4+o5thpse07vGqjd9DdIjCAkiG83D5AH5R
	t4ShYzGmV85+ps+/Isq2xiu7B+Szss7nmSYCl4WE611N6+X/P5HqFEED3Un9zfLxp9A8
	X4LA==
MIME-Version: 1.0
X-Received: by 10.152.22.99 with SMTP id c3mr45491900laf.32.1438265134872;
	Thu, 30 Jul 2015 07:05:34 -0700 (PDT)
Received: by 10.25.18.228 with HTTP; Thu, 30 Jul 2015 07:05:34 -0700 (PDT)
In-Reply-To: <CAPg+sBjsQPUZEj0LFHBWuM4E+4SsUu4C9fcb7OJX4SC4+omvPQ@mail.gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
	<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
	<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
	<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
	<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
	<55B94FAD.7040205@mail.bihthai.net>
	<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
	<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
	<CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
	<74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
	<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
	<CAPg+sBjsQPUZEj0LFHBWuM4E+4SsUu4C9fcb7OJX4SC4+omvPQ@mail.gmail.com>
Date: Thu, 30 Jul 2015 10:05:34 -0400
Message-ID: <CABsx9T1Wgf8u-ZKXmiRhQwdJNkDJg9RL_o2j2cWxP-6nKmxS2Q@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=089e0158b6c074ff81051c1832c4
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 Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
	temporary
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, 30 Jul 2015 14:05:50 -0000

--089e0158b6c074ff81051c1832c4
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> Let's scale the block size gradually over time, according to technological
> growth.


Yes, lets do that-- that is EXACTLY what BIP101 intends to do.

With the added belt&suspenders reality check of miners, who won't produce
blocks too big for whatever technology they're using.

-------

So what do you think the scalability road map should look like? Should we
wait to hard fork until Blockstream Elements is ready for deploying on the
main network, and then have One Grand Hardfork that introduces all the
scalability work you guys have been working on (like Segregated Witness and
Lightning)?

Or is the plan to avoid controversy by people voluntarily moving their
bitcoin to a sidechain where all this scaling-up innovation happens?

No plan for how to scale up is the worst of all possible worlds, and the
lack of a direction or plan(s) is my main objection to the current status
quo.

And any plan that requires inventing brand-new technology is going to be
riskier than scaling up what we already have and understand, which is why I
think it is worthwhile to scale up what we have IN ADDITION TO working on
great projects like Segregated Witness and Lightning.

-- 
--
Gavin Andresen

--089e0158b6c074ff81051c1832c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <span dir=3D"ltr">&lt;<a href=3D=
"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let&#39;s scale the=
 block size gradually over time, according to technological growth.</blockq=
uote></div><br>Yes, lets do that-- that is EXACTLY what BIP101 intends to d=
o.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Wit=
h the added belt&amp;suspenders reality check of miners, who won&#39;t prod=
uce blocks too big for whatever technology they&#39;re using.<br><br></div>=
<div class=3D"gmail_extra">-------</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">So what do you think the scalability road map =
should look like? Should we wait to hard fork until Blockstream Elements is=
 ready for deploying on the main network, and then have One Grand Hardfork =
that introduces all the scalability work you guys have been working on (lik=
e Segregated Witness and Lightning)?</div><div class=3D"gmail_extra"><br></=
div><div class=3D"gmail_extra">Or is the plan to avoid controversy by peopl=
e voluntarily moving their bitcoin to a sidechain where all this scaling-up=
 innovation happens?</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">No plan for how to scale up is the worst of all possible w=
orlds, and the lack of a direction or plan(s) is my main objection to the c=
urrent status quo.<br></div><div class=3D"gmail_extra"><div><br></div><div>=
And any plan that requires inventing brand-new technology is going to be ri=
skier than scaling up what we already have and understand, which is why I t=
hink it is worthwhile to scale up what we have IN ADDITION TO working on gr=
eat projects like Segregated Witness and Lightning.</div><div><br></div>-- =
<br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div><div class=
=3D"gmail_signature"><br></div>
</div></div>

--089e0158b6c074ff81051c1832c4--