summaryrefslogtreecommitdiff
path: root/0c/80747f8d70833986eee8f39de18fa5453eabce
blob: d8330157ce4b8c76f7ed9c45372c32c25d97bfcd (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephencalebmorse@gmail.com>) id 1YzyVB-0000Vi-Fj
	for bitcoin-development@lists.sourceforge.net;
	Wed, 03 Jun 2015 02:33:57 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.172 as permitted sender)
	client-ip=209.85.160.172;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-yk0-f172.google.com; 
Received: from mail-yk0-f172.google.com ([209.85.160.172])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YzyVA-0007rO-MC
	for bitcoin-development@lists.sourceforge.net;
	Wed, 03 Jun 2015 02:33:57 +0000
Received: by ykfl8 with SMTP id l8so59748994ykf.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 02 Jun 2015 19:33:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.128.139 with SMTP id u133mr36653109ykb.49.1433298831182; 
	Tue, 02 Jun 2015 19:33:51 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Tue, 2 Jun 2015 19:33:51 -0700 (PDT)
In-Reply-To: <CAM7BtUrN9D__ha63Qfs2Fi4HSUFWb8BArHni9yFKRSdLSxCNnA@mail.gmail.com>
References: <CABHVRKSFV_dXZeLnhBLfRK=wrBFsRH5kFBZqwECh-LyCkwrmtQ@mail.gmail.com>
	<CAM7BtUod0hyteqx-yj8XMwATYp73Shi0pvdcTrW0buseLGc_ZQ@mail.gmail.com>
	<CABHVRKT7H1p67Bz_T_caaGFnfuswnC+kXKGdkpRhtXUZQv3HtQ@mail.gmail.com>
	<CAM7BtUrN9D__ha63Qfs2Fi4HSUFWb8BArHni9yFKRSdLSxCNnA@mail.gmail.com>
Date: Tue, 2 Jun 2015 22:33:51 -0400
Message-ID: <CABHVRKS5Mnp9vSJ6mZwNroY7jbBJx+4d+m4hVpWONisaMvBNUw@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Pindar Wong <pindar.wong@gmail.com>
Content-Type: multipart/alternative; boundary=001a11395eceb09202051793e3fd
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
	(stephencalebmorse[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: 1YzyVA-0007rO-MC
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
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: Wed, 03 Jun 2015 02:33:57 -0000

--001a11395eceb09202051793e3fd
Content-Type: text/plain; charset=UTF-8

Pindar,

yes and it's a good idea to separate the hard/soft fork upgrades. The point
> being here is that we're also establishing a process for the community to
> self-determine the way forward in a transparent and verifiable manner.
>
> What's not to like? :)
>
> I'll probably have some time on Sunday to help hack something up but I
> don't think this is that heavy a coding lift? What am I missing?
>

As Matt mentioned, many members of the bitcoin community would be hesitant
about giving miners this much power. It essentially lets them vote to
change the rules of the system. But miners are not the only part of this
ecosystem, and they are not the only ones affected by the choice of block
size limit, so they probably shouldn't be the only ones with a vote.
Instead, we vote with the software we run, and all upgrade.

So, while I think an idea like this has its merits, I would bet that it's
fairly unlikely to get enough support to be merged into bitcoin core.

Best,
Stephen

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

<div dir=3D"ltr">Pindar,<div><br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>yes and it&#39;s a good idea to=
 separate the hard/soft fork upgrades. The point being here is that we&#39;=
re also establishing a process for the community to self-determine the way =
forward in a transparent and verifiable manner.=C2=A0<br></div><div><br></d=
iv><div>What&#39;s not to like? :)<br><br></div><div>I&#39;ll probably have=
 some time on Sunday to help hack something up but I don&#39;t think this i=
s that heavy a coding lift? What am I missing?</div></div></div></div></blo=
ckquote><div><br></div><div>As Matt mentioned, many members of the bitcoin =
community would be hesitant about giving miners this much power. It essenti=
ally lets them vote to change the rules of the system. But miners are not t=
he only part of this ecosystem, and they are not the only ones affected by =
the choice of block size limit, so they probably shouldn&#39;t be the only =
ones with a vote. Instead, we vote with the software we run, and all upgrad=
e.</div><div><br></div><div>So, while I think an idea like this has its mer=
its, I would bet that it&#39;s fairly unlikely to get enough support to be =
merged into bitcoin core.=C2=A0</div><div><br></div><div>Best,<br>Stephen</=
div><div><br></div></div></div></div></div>

--001a11395eceb09202051793e3fd--