summaryrefslogtreecommitdiff
path: root/ba/1408565cc2c43074e2b7af70ebfbd8c8c222c1
blob: 15ebaf424d31cd4d6e25fad06a982352b32c610e (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1U7TUV-00073B-1q
	for bitcoin-development@lists.sourceforge.net;
	Mon, 18 Feb 2013 16:22:55 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.55 as permitted sender)
	client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
	helo=outmail149055.authsmtp.co.uk; 
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1U7TUO-0006NR-5a for bitcoin-development@lists.sourceforge.net;
	Mon, 18 Feb 2013 16:22:55 +0000
Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226])
	by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	r1IGMdh4034530; Mon, 18 Feb 2013 16:22:39 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r1IGMX3g008353
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 18 Feb 2013 16:22:36 GMT
Date: Mon, 18 Feb 2013 11:22:35 -0500
From: Peter Todd <pete@petertodd.org>
To: Stephen Pair <stephen@bitpay.com>
Message-ID: <20130218162235.GA17224@savin>
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>
	<CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
	<20130214060744.GA15157@savin>
	<CADb9v0L53kZfiBYtzCLtCsBVdeZz5CHtwBsM1CBDcCh9v-T=HA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L"
Content-Disposition: inline
In-Reply-To: <CADb9v0L53kZfiBYtzCLtCsBVdeZz5CHtwBsM1CBDcCh9v-T=HA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 684005fd-79e7-11e2-98a9-0025907ec6c5
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdwoUHlAWAgsB AmUbWlJeUl97WmU7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsqAGV2 e3YdBRlyfwZDezBy bEZkWj5dVEB6dUMr
	FlNTHDgBeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA4qGDU7 XQgFBzwzHEsKDy83
	KBclYkAVGEcdO1kz Nl1pQ08cPn1aDwpS Hk9MCyZFJl4HXGIq
	Cx9dFVIeHXVXRSBX AVUjIhZJBFQA
X-Authentic-SMTP: 61633532353630.1020:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.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
	0.0 LOTS_OF_MONEY          Huge... sums of money
X-Headers-End: 1U7TUO-0006NR-5a
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: Mon, 18 Feb 2013 16:22:55 -0000


--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 14, 2013 at 07:59:04AM -0500, Stephen Pair wrote:
> > The idea that miners have a strong incentive to distribute blocks as
> > widely and as quickly as possible is a serious misconception. The
> > optimal situation for a miner is if they can guarantee their blocks
> > would reach just over 50% of the overall hashing power, but no more. The
> > reason is orphans.
> >
>=20
> Perhaps, but a miner trying to target just over 50% of the network will r=
un
> the very real risk that they'll only reach 49%.

Then don't be so agressive; target 90% as I suggested and the miner
still comes out ahead by having 10% less hashing power to compete with.
50% is only a maximum because when more than 50% of the network does not
see your blocks the majority will inevitably create a longer chain than
you, but less than 50% and your part of the network will inevitably
create a longer chain than them.

> What about the case for centralization if the block size remains capped? =
 I
> see a far greater risk of centralization in that scenario than if the cap
> were to be removed.  The reason is very simple, bitcoin would ultimately
> become useful only for very high value, settlement transactions.  Only the
> mega corporations and banks would be using it directly, everyone else wou=
ld
> be doing daily transacting in centrally issued currencies of one form or
> another.  As the banks and mega corps learned about the utility of bitcoin
> and began to use it en masse, they would start to take the whole network
> off the public internet and put it on a higher speed and more reliable
> backbone.  Those corporations would establish mining agreements among
> themselves to ensure none of the participants could take over the system
> and compromise it, while at the same time keeping the operational costs to
> a minimum.  Bitcoin is now a great alternative to the wire transfer syste=
m,
> but has no value to the average person wanted to have cheap and private
> transactions over the Internet.  Maybe Litecoin starts to fill that niche.

What you are describing is either *voluntary* centralization, or won't
happen. Nothing in your scenario will stop people from transacting on
the Bitcoin network directly, it will just make it more expensive. For
instance suppose fees rose to the point where the value of the fees was
10x the value of the block reward today; miners would be taking in
$972,000/day, or $6750/block. At 1MiB/block that implies transaction
fees of $6.75/KiB, or about $2 per transaction. Even if the fees were
$20 per transaction that'd be pretty cheap for direct access to the
worlds bank-to-bank financial network; I can still transfer an unlimited
amount of money across the planet, and no-one can stop me. Importantly
there will be plenty of demand to have transactions mined from people
other than banks and large corporations.

Because there will continue to be demand, and because 1MiB blocks means
running a relay node is trivial enough that people can do it just for
fun, banks won't be able to force people to use their "high-speed
backbone". Not to say they won't create one, but it won't have any real
advantage over something that can be run in your basement.

On the mining side with 1MiB blocks the fixed costs for setting up a
mining operation are just a moderately powered computer with a bunch of
harddrive space and a slow internet connection. The marginal costs are
still there of course, but the cost of power and cooling are lower at
small scale than at larger industrial scales; power is often available
for free in small amounts, and cooling isn't a problem in small setups.
Because small-scale miners will still exist, there will still be a
market for "consumer" mining gear, and trying to regulate mining
equipment will just turn it into a black-market good. Small blocks let
you setup a mining operation anywhere in the world - good luck
controlling that. Mining also will remain a way to import Bitcoins into
places.

Banks can try setting up exclusive mining contracts, but unless they
control more than 50% of the network they'll still have to accept blocks
found by these highly decentralized, small-scale miners. They'd be
better off broadcasting their transactions to those miners as well so
they don't get double-spent. Thus decentralized miners still can profit
=66rom transaction fees, and still have an incentive to mine. Doesn't
sound like centralization to me at all.

On the other land, with large blocks, not only is mining solo
unprofitable due to the huge fixed costs required to process the blocks,
miners on pools can't effectively secure the network because they can't
independently verify that the blocks they are mining are valid. It would
be easy then to co-opt the relatively small number of pools, a number
that is not particularly large even now. Transaction relay nodes would
also be very expensive to run, and again the small number of them makes
them targets for control. Sure transactions will be cheap, but that
doesn't do you any good if the small number of miners out there are all
regulated and ignore your transactions.

Sounds like centralization to me.

--=20
'peter'[:-1]@petertodd.org

--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRIlVKAAoJEH+rEUJn5PoE+ScH/RYpWqcK3WauvNCodaAEceFU
DCp+fJuFHn0Mftw5IIpMzkekZEVaRo+tNTgbF9WGE9WTZttAXpHWiGRyaz5b2yV6
1ru5D/qnBtFOB8K8M2onYp5+R6IbCIKSCXNbZ5YfDqQDIBvrSaJW6qDHi7Q5ndDN
E9BPXV2xPAc1tfiDSTawrHKayoqP2PWdi+DENgEktAVAEVjYzo2jHEvf5bZ+jAZy
lp0/UjqAKE9pJBxzrK4LstRL1v7IsjCxzhRROEgcJt1QvqdTdH6z7zls55XFvw+F
auGQ4RRmwsAVNup22kvSfcDiadvPEZW5hsCbVjKlRZCzmmVsx49Axb/Bw1NksEg=
=M31Z
-----END PGP SIGNATURE-----

--FCuugMFkClbJLl1L--