summaryrefslogtreecommitdiff
path: root/a8/3a5a226e1d757f65e27fe9e75f0e0d100db825
blob: 7da07fed72dfe6a13795a16b33accdfb6dd4da57 (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
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
202
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from
	<bounces+404635-86d7-bitcoin-development=lists.sourceforge.net@email.bitpay.com>)
	id 1U5oor-0003pn-5D for bitcoin-development@lists.sourceforge.net;
	Thu, 14 Feb 2013 02:45:05 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1U5oon-00058A-91 for bitcoin-development@lists.sourceforge.net;
	Thu, 14 Feb 2013 02:45:05 +0000
Received: by 10.36.109.179 with SMTP id mf48.1175.511C4FA73
	Wed, 13 Feb 2013 20:44:55 -0600 (CST)
Received: from mail-la0-f44.google.com (unknown [209.85.215.44])
	by mi17 (SG) with ESMTP id 511c4fa6.1029.86fd8c
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 Feb 2013 20:44:54 -0600 (CST)
Received: by mail-la0-f44.google.com with SMTP id eb20so1878861lab.17
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 Feb 2013 18:44:53 -0800 (PST)
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=7xvVInbH3+azPOoAEbzzZ3VcEtVBy8623pzsPsFQGDw=;
	b=nJ/R7sllWa4obPUIPGlHEPC7/6jlDm+hSDR9pUbk+rqqSjrn5usVTqqEyD3mUO1qnH
	rucjQg8Yfmkh7tNEkEbLPFRhffIosCtTU9/75Z7khioL0aVXUIIO6KhnywelqqVYztM+
	aUiDignxqoOT8C5LUxcXzf/YgOjlKrOXt1+4fJk/NkAlA6Izrdiu7WWMOSyWKI06Rbqo
	uAn1M4FJQPZ6yMdRlG90boPoNKi8DmBtkMYWuZ0KhmKo70Svf8GEl6ftdDC6p/hhR9tD
	D2OG00yY4hPp1OtHPvrv401R7TTOhFTKqh4z/5KyUoz2mrSMFETat5NuZcwunZQWdN82
	BOIw==
X-Received: by 10.152.125.239 with SMTP id mt15mr22226199lab.26.1360809892989; 
	Wed, 13 Feb 2013 18:44:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.1.47 with HTTP; Wed, 13 Feb 2013 18:44:11 -0800 (PST)
X-Originating-IP: [71.204.90.78]
In-Reply-To: <CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
	<CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
	<CAN1xFdrGiWmn_EaBNMXXZAV38oeqP14YiMzMZQrkA+WL9QEMfA@mail.gmail.com>
	<CAAS2fgR5=nLTBQUBzjZQs91AVw5XSTiqe-KB_T9R9wKfBrOq6Q@mail.gmail.com>
	<CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
	<CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
	<CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com>
From: Stephen Pair <stephen@bitpay.com>
Date: Wed, 13 Feb 2013 21:44:11 -0500
Message-ID: <CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04426b66474aae04d5a63e67
X-Gm-Message-State: ALoCoQnQzZdEW2b+85EBwjoso8m9WaMXk28UBXw0b6annn48oqOXr5DqtVEnGJv0uAYTp7PMQe/Y
X-Sendgrid-EID: MKV9IjI68is80Jqz/eG9wzL0RPGq34wm6zZKLyf9fV5O8HKFIs9vx7uQQ4ODbOsXMtBoOo0zTOYFxL8xCmMXeD1cfg0atP+fkGrq0XapHuw69gmZ/fNi4Zz07ZkvKtJ1CDXrBtT10ZQgaOwmB+xA2w==
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: 1U5oon-00058A-91
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule
 modifications into the block chain
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 Feb 2013 02:45:05 -0000

--f46d04426b66474aae04d5a63e67
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 13, 2013 at 7:28 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> <bunch of stuff>
>

I understand your arguments, but don't agree with many of your conclusions.

The requirement for everyone to hear the history doesn't get talked
> about much


One of the beauties of bitcoin is that the miners have a very strong
incentive to distribute as widely and as quickly as possible the blocks
they find...they also have a very strong incentive to hear about the blocks
that others find.  There will not be an issue with blocks being "jealously
guarded"...what miners will want is a good feed of transactions that they
want to mine.  They will be willing to pay for those feeds (either by
sharing the proceeds with highly connected "relay" nodes or by operating
highly connected nodes themselves).  Because miners will only want to pay
to get a feed of profitable transactions, they will not pay to receive
transactions whose miner fee does not cover the "relay" fee (by which I
mean the fee or cost associated with the bandwidth and validation that a
transaction requires) with some amount of profit.  This means that the
relay node will not fetch and propagate those transactions whose fee is too
small (unless there was some other fee structure outside the miners fee).

These are relatively easy businesses to operate...which means there will be
a lot of them and they'll compete on fees (with wallets automatically
discovering the cheapest of the services).  If the businesses of relaying
and mining ever became too centralized, other businesses with a vested
interest in the success of bitcoin would take the necessary steps to ensure
there remained adequate decentralization.

It's important to remember that the centralization that currently exists in
the fiat currency world benefits one set of businesses to the detriment of
many others.  Having a functioning and trustworthy payment system benefits
far more people and businesses than a centralized system would.

It is good to be wary of these potential issues, but I don't see how the
economics are likely to yield the outcome you fear.  And, really, there's
not a lot that can be done to prevent economics from dictating the ultimate
outcome.  In fact, what I write above is not so much about what I think
*should* be built, it's more about what I *predict* will be built.

--f46d04426b66474aae04d5a63e67
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On Wed, Feb 13, 2013 at 7:28 PM=
, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"mailto:gmaxwell@gmail.co=
m" target=3D"_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">&lt;bunch of stuff&gt;</div></blockquote>
<div>
<br></div><div>I understand your arguments, but don&#39;t agree with many o=
f your conclusions.<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

The requirement for everyone to hear the history doesn&#39;t get talked<br>
about much</blockquote><div><br></div><div style>One of the beauties of bit=
coin is that the miners have a very strong incentive to distribute as widel=
y and as quickly as possible the blocks they find...they also have a very s=
trong incentive to hear about the blocks that others find. =A0There will no=
t be an issue with blocks being &quot;jealously guarded&quot;...what miners=
 will want is a good feed of transactions that they want to mine. =A0They w=
ill be willing to pay for those feeds (either by sharing the proceeds with =
highly connected &quot;relay&quot; nodes or by operating highly connected n=
odes themselves). =A0Because miners will only want to pay to get a feed of =
profitable transactions, they will not pay to receive transactions whose mi=
ner fee does not cover the &quot;relay&quot; fee (by which I mean the fee o=
r cost associated with the bandwidth and validation that a transaction requ=
ires) with some amount of profit. =A0This means that the relay node will no=
t fetch and propagate those transactions whose fee is too small (unless the=
re was some other fee structure outside the miners fee).</div>

<div style><br></div><div style>These are relatively easy businesses to ope=
rate...which means there will be a lot of them and they&#39;ll compete on f=
ees (with wallets automatically discovering the cheapest of the services). =
=A0If the businesses of relaying and mining ever became too centralized, ot=
her businesses with a vested interest in the success of bitcoin would take =
the necessary steps to ensure there remained adequate decentralization.</di=
v>

<div style><br></div><div style>It&#39;s important to remember that the cen=
tralization that currently exists in the fiat currency world benefits one s=
et of businesses to the detriment of many others. =A0Having a functioning a=
nd trustworthy payment system benefits far more people and businesses than =
a centralized system would. =A0</div>

<div><br></div><div style>It is good to be wary of these potential issues, =
but I don&#39;t see how the economics are likely to yield the outcome you f=
ear. =A0And, really, there&#39;s not a lot that can be done to prevent econ=
omics from dictating the ultimate outcome. =A0In fact, what I write above i=
s not so much about what I think *should* be built, it&#39;s more about wha=
t I *predict* will be built. =A0</div>

<div><br></div></div>
</div></div>
<img src=3D"http://email.bitpay.com/wf/open?upn=3DFPVR34OW0iTCykNVpPzODvIQt=
2S-2BzCNFBszsV6r9gX31pUdL7Qn-2Be1uVJ4jTNxzg7mdNkjuhSmoG05kJrobeSbq9Wqp4Yvbo=
kwOHuPuERVoOy2xW9yAzh-2FdDTWus2SkRnfJt5aoVFtdR-2BSVDKpMf8-2FUgIbLBcs3mLCcHs=
2Cdy2RfRmKX3uMe8WytAIHrV2qZ9RT1E8q7TwmkM5TW-2Bo6Lwg-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-bottom:0=
 !important;margin-right:0 !important;margin-left:0 !important;padding-top:=
0 !important;padding-bottom:0 !important;padding-right:0 !important;padding=
-left:0 !important;"/>

--f46d04426b66474aae04d5a63e67--