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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from
<bounces+404635-86d7-bitcoin-development=lists.sourceforge.net@email.bitpay.com>)
id 1UFran-0007ed-Hz for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 19:44:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of
email.bitpay.com designates 198.37.155.136 as permitted sender)
client-ip=198.37.155.136;
envelope-from=bounces+404635-86d7-bitcoin-development=lists.sourceforge.net@email.bitpay.com;
helo=o19837155136.outbound-mail.sendgrid.net;
Received: from [198.37.155.136] (helo=o19837155136.outbound-mail.sendgrid.net)
by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1UFral-0007OF-Ag for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 19:44:05 +0000
Received: by 10.42.80.130 with SMTP id filter-064.24699.5140D6FD3
Wed, 13 Mar 2013 19:43:57 +0000 (UTC)
Received: from mail-la0-f48.google.com (unknown [209.85.215.48])
by mi17 (SG) with ESMTP id 5140d6fc.6108.10961f0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 14:43:56 -0500 (CST)
Received: by mail-la0-f48.google.com with SMTP id fq13so1563721lab.7
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 12:43:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:mime-version:x-originating-ip:in-reply-to:references
:from:date:message-id:subject:to:cc:content-type:x-gm-message-state;
bh=UABPN6KtW8zfCwGgz3Y0wzyTJQAvESCpmHhE56Bn2t4=;
b=X98iRUOJSovQR7z9R+/r1+LFTHeeN+MJaKNWJTTopdjiyeedydiqVdoWiWD/IYOgvt
V56oqUxUy+I0FbgTPMVN6Tn0KcvPBwNChRFsy2NyQ+rybfcQ2L24rjkN+neYcGZ5DNFu
U3wvYOzX+YFi6pPG+N7EJfDRXYxm8uQ3I9dnrGngW2yupt28BDEHzAkQMTOhQ070FgPp
k9EgFGxUImeaJcpMQsg+ycLXnRNoO4+8omne/Mi4aNk6U3EVoiM8XVdDTnCQTJ9F61Gp
BbQyQy9BOkC0pYbHfpW7HiTxFrA324KlawyAgA9GFYhk7kuxE5IGKGop0/ibUwcNq0FO
S5tA==
X-Received: by 10.112.88.10 with SMTP id bc10mr42729lbb.70.1363203835111; Wed,
13 Mar 2013 12:43:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.82.132 with HTTP; Wed, 13 Mar 2013 12:43:15 -0700 (PDT)
X-Originating-IP: [66.194.102.6]
In-Reply-To: <20130313182805.GA7921@vps7135.xlshosting.net>
References: <CABsx9T0xOpNpFG4bo7wjcMV8a_xtw_jrRx_fiSutX08yfP8P7Q@mail.gmail.com>
<20130313174838.GA22621@savin>
<2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com>
<20130313182805.GA7921@vps7135.xlshosting.net>
From: Stephen Pair <stephen@bitpay.com>
Date: Wed, 13 Mar 2013 15:43:15 -0400
Message-ID: <CADb9v0L4fXw9qzhzKmRi+Xet_5qK7RoU4=gbCRpXA1BXuVaYSg@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=f46d040169755958ed04d7d3a0b1
X-Gm-Message-State: ALoCoQknIJPlcblgyunK3D4YWNo5d9ch9z/ica2eZTa1sYa1azkTSreNlMvdZxWU8RRC7yddTqUB
X-SG-EID: MKV9IjI68is80Jqz/eG9wzL0RPGq34wm6zZKLyf9fV5O8HKFIs9vx7uQQ4ODbOsXepzcyWTd64mtNHqsdI51Kv5A4cNRB5wN8sTVu7YKMKFj7bSthHkRGu+hd03IN0B1dOpUVcdOqIbFcXAjDmeTxAkZGXI7VGci9DunbmG47Ig=
X-Spam-Score: 0.5 (/)
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
1.0 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Headers-End: 1UFral-0007OF-Ag
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Michael Gronager <gronager@ceptacle.com>
Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions
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, 13 Mar 2013 19:44:05 -0000
--f46d040169755958ed04d7d3a0b1
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> But we cannot just drop support for old nodes. It is completely
> unreasonable to put the
> _majority_ of the network on a fork, without even as much as a discussion
> about it.
> "Oh, you didn't get the memo? The rules implemented in your client are
> outdated." - that
> is not how Bitcoin works: the network defines the rules.
> ...
> Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This
> is something
> that requires widespread community consensus - far more than just miners
> and developers
The way I've started thinking about it is that there is a market for
securing a payment network. In that market you have consumers (users of
bitcoin) and providers (miners). It's not clear to me that if the
overwhelming majority of miners stayed on 0.8 that the 0.7 fork wouldn't
have still won out in the long run because effectively what you would have
had is a situation where the providers abandon a large portion of their
customers (0.7 users) and start providing a service that is in much less
demand. Would everyone have upgraded to 0.8? Maybe, but maybe not. Maybe
many people would have made the rational decision to stay on earlier
versions and the small minority of miners that choose to service the 0.7
fork could have earned more Bitcoin on that fork...and maybe in the long
run, the majority of miners on 0.8 would realize this situation and start
to trickle back over to the 0.7 fork. The flip side of the equation is
that the users have a pretty compelling reasons to use the services of the
most secure network (less risk of double spends). So, the users very well
could have made the rational decision to consume the services of the most
powerful network and made the switch to 0.8.
What happened in reality is that the majority of the mining community made
the rational decision to service the largest pool of customers (0.8 as well
as 0.7 and earlier users). It was rational because the risk of servicing
only the 0.8 users would have been much greater.
Because of this dynamic, I doubt there would ever be multiple forks of any
consequence in permanent coexistence. I would even go so far as to say
that at this point, a successful competitor to Bitcoin would have to arise
as a fork of the UTXOs in the block chain (even if the competitor didn't
even use a block chain). That competitor might even have to begin life in
lock step co-existence with Bitcoin, recognizing all Bitcoin transactions
for some period of time while it attempts to gain market share.
--f46d040169755958ed04d7d3a0b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On Wed, Mar 13, 2013 at 2:28 PM=
, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail=
.com" target=3D"_blank">pieter.wuille@gmail.com</a>></span> wrote:<div c=
lass=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
But we cannot just drop support for old nodes. It is completely unreasonabl=
e to put the<br>
_majority_ of the network on a fork, without even as much as a discussion a=
bout it.<br>
"Oh, you didn't get the memo? The rules implemented in your client=
are outdated." - that<br>
is not how Bitcoin works: the network defines the rules.<br>...<br>
Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. Th=
is is something<br>
that requires widespread community consensus - far more than just miners an=
d developers</blockquote><div><br></div><div style>The way I've started=
thinking about it is that there is a market for securing a payment network=
. =A0In that market you have consumers (users of bitcoin) and providers (mi=
ners). =A0It's not clear to me that if the overwhelming majority of min=
ers stayed on 0.8 that the 0.7 fork wouldn't have still won out in the =
long run because effectively what you would have had is a situation where t=
he providers abandon a large portion of their customers (0.7 users) and sta=
rt providing a service that is in much less demand. =A0Would everyone have =
upgraded to 0.8? =A0Maybe, but maybe not. =A0Maybe many people would have m=
ade the rational decision to stay on earlier versions and the small minorit=
y of miners that choose to service the 0.7 fork could have earned more Bitc=
oin on that fork...and maybe in the long run, the majority of miners on 0.8=
would realize this situation and start to trickle back over to the 0.7 for=
k. =A0The flip side of the equation is that the users have a pretty compell=
ing reasons to use the services of the most secure network (less risk of do=
uble spends). =A0So, the users very well could have made the rational decis=
ion to consume the services of the most powerful network and made the switc=
h to 0.8. =A0</div>
<div style><br></div><div style>What happened in reality is that the majori=
ty of the mining community made the rational decision to service the larges=
t pool of customers (0.8 as well as 0.7 and earlier users). =A0It was ratio=
nal because the risk of servicing only the 0.8 users would have been much g=
reater.</div>
<div style><br></div><div style>Because of this dynamic, I doubt there woul=
d ever be multiple forks of any consequence in permanent coexistence. =A0I =
would even go so far as to say that at this point, a successful competitor =
to Bitcoin would have to arise as a fork of the UTXOs in the block chain (e=
ven if the competitor didn't even use a block chain). =A0That competito=
r might even have to begin life in lock step co-existence with Bitcoin, rec=
ognizing all Bitcoin transactions for some period of time while it attempts=
to gain market share.</div>
</div>
</div></div>
<img src=3D"http://email.bitpay.com/wf/open?upn=3DFPVR34OW0iTCykNVpPzODvIQt=
2S-2BzCNFBszsV6r9gX31pUdL7Qn-2Be1uVJ4jTNxzgR3J8x5-2F6k-2FLoWHADRwRANCLR1ANf=
I-2B-2B-2BeSaYLRL0eYQAnFXXiCotLcLn3qcAjtU6MB2WJrY-2Bjn3g-2Fo3BrHCaCIr9n0Rfk=
B-2BJkjQhFZs0VXxlnZF0X7VXhonUmOjN0nByOcBfnwfXUE5HKVzGVxUkGA-3D-3D" alt=3D""=
width=3D"1" height=3D"1" border=3D"0" style=3D"height:1px !important;width=
:1px !important;border-width:0 !important;margin-top:0 !important;margin-bo=
ttom:0 !important;margin-right:0 !important;margin-left:0 !important;paddin=
g-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;p=
adding-left:0 !important;"/>
--f46d040169755958ed04d7d3a0b1--
|
