path: root/e1/ef63f656664429d64ced30e1e6d87ef820d1c5

Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F417CFF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 14:59:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com
	[209.85.213.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 001131AE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 14:58:59 +0000 (UTC)
Received: by igk11 with SMTP id 11so33718960igk.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 07:58:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=vinumeris.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=6PqCgCNwu9OhLXcElrYqlkchKN2JMj26OFKRHFYpKWI=;
	b=Iai3y2hDnPWnRqDvMTZwsD2EHYH2h34rXiRiiy+utWtaKsrSk6CE4xV/hvpo425Syt
	AmjdDsHH4je/HdoHB32iU2VrbKlW0h9+b3YcOu+1RX0qaJ29WV0F/RsR2Da+m+Tf8pEh
	XEZtDJCDG0IRy4ttyW18LDO/4Tn4WrGGTaf5g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=6PqCgCNwu9OhLXcElrYqlkchKN2JMj26OFKRHFYpKWI=;
	b=mSga0YX2MW0pd+lGOaO539Q6yc06WnTgVzx1LKygRGZUOPq/GnlwfsWujleEEejW7L
	Lgn8cjrl5JdV61wAjGaAf1jjFOYhy+3RnygOrE384K8fTXCGqPJPZc+Npdm8cZnH4VVj
	L3tdeBEsF8GWHRYJP7aQs54SCbN4pjH+D4fg9RNyAYuUGhHI0XdQ5QdxYg8nj0xMnpXt
	S3POy0Xsr5o/gweNF46V7q/gi89Q4thy459fbpI3VDAoSgKLyCJ6ZrB8kSZZYRdDP/p9
	skoPuskv/nl4O6pqztwjJmGUogMELZfm7AKuxZXhFWuGS5Sx+788fykFRiKYTPJYhDML
	3vRw==
X-Gm-Message-State: ALoCoQkqKpI9RpfGpE+T1jVNYxUtgjAPc0moRC20NFkfeeoTUq03e2UV/anjZaKy4C8FkSMZka3e
MIME-Version: 1.0
X-Received: by 10.50.43.199 with SMTP id y7mr6267890igl.69.1438354739315; Fri,
	31 Jul 2015 07:58:59 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Fri, 31 Jul 2015 07:58:59 -0700 (PDT)
In-Reply-To: <CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
	<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
	<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
	<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
	<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
	<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
	<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
Date: Fri, 31 Jul 2015 16:58:59 +0200
Message-ID: <CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=089e011849e64c60a0051c2d0fcd
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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] Block size following technological growth
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: Fri, 31 Jul 2015 14:59:01 -0000

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

>
> How more users or more nodes can bring more miners, or more importantly,
> improve mining decentralization?
>

Because the bigger the ecosystem is the more interest there is in taking
part?

I mean, I guess I don't know how to answer your question. When Bitcoin was
new it had almost no users and almost no miners. Now there are millions of
users and factories producing ASICs just for Bitcoin. Surely the
correlation is obvious?

I'm sorry, but until there's a simulation that I can run with different
> sizes' testchains (for example using #6382) to somehow compare them, I wi=
ll
> consider any value arbitrary.
>

Gavin did run simulations. 20mb isn't arbitrary, the process behind it was
well documented here:

http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-cen=
tralized

*I chose 20MB as a reasonable block size to target because 170 gigabytes
per month comfortably fits into the typical 250-300 gigabytes per month
data cap=E2=80=93 so you can run a full node from home on a =E2=80=9Cpretty=
 good=E2=80=9D broadband
plan.*
Did you think 20mb was picked randomly?


> Agreed on the first sentence, I'm just saying that the influence of
> the blocksize in that function is monotonic: with bigger sizes, equal
> or worse mining centralization.
>

I have a hard time agreeing with this because I've seen Bitcoin go from
blocks that were often empty to blocks that are often full, and in this
time the number of miners and hash power on the network has gone up a huge
amount too.

You can argue that a miner doesn't count if they pool mine. But if a miner
mines on a pool that uses exactly the same software and settings as the
miner would have done anyway, then it makes no difference. Miners can
switch between pools to find one that works the way they like, so whilst
less pooling or more decentralised pools would be nice (e.g.
getblocktemplate), and I've written about how to push it forward before, I
still say there are many more miners than in the past.

If I had to pick between two changes to improve mining decentralisation:

1) Lower block size
2) Finishing, documenting, and making the UX really slick for a
getblocktemplate based decentralised mining pool

then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.


> you should be consequently advocating for full removal of the limit rathe=
r
> than changes towards bigger arbitrary values.
>

I did toy with that idea a while ago. Of course there can not really be no
limit at all because the code assumes blocks fit into RAM/swap, and nodes
would just end up ignoring blocks they couldn't download in time anyway.
There is obviously a physical limit somewhere.

But it is easier to find common ground with others by compromising. Is 8mb
better than no limit? I don't know and I don't care much:  I think Bitcoin
adoption is a slow, hard process and we'll be lucky to increase average
usage 8x over the next couple of years. So if 8mb+ is better for others,
that's OK by me.



> Sorry, I don't know about Pieter, but I was mostly talking about
> mining centralization, certainly not about payment services.
>

OK. I write these emails for other readers too :) In the past for instance,
developers who run services without running their own nodes has come up.

Re: exchange profit. You can pick some other useful service provider if you
like. Payment processors or cold storage providers or the TREZOR
manufacturers or whoever.

My point is you can't have a tiny high-value-transactions only currency AND
all the useful infrastructure that the Bitcoin community is making. It's a
contradiction. And without the infrastructure bitcoin ceases to be
interesting even to people who are willing to pay huge sums to use it.

--089e011849e64c60a0051c2d0fcd
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">How more users or more nodes can bring more mine=
rs, or more=C2=A0importantly, improve mining decentralization?<br></blockqu=
ote><div><br></div><div>Because the bigger the ecosystem is the more intere=
st there is in taking part?</div><div><br></div><div>I mean, I guess I don&=
#39;t know how to answer your question. When Bitcoin was new it had almost =
no users and almost no miners. Now there are millions of users and factorie=
s producing ASICs just for Bitcoin. Surely the correlation is obvious?</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">I&#39;m sorry, but until the=
re&#39;s a simulation that I can run with=C2=A0different sizes&#39; testcha=
ins (for example using #6382) to somehow=C2=A0compare them, I will consider=
 any value arbitrary.<br></blockquote><div><br></div><div>Gavin did run sim=
ulations. 20mb isn&#39;t arbitrary, the process behind it was well document=
ed here:</div><div><br></div><div><a href=3D"http://gavinandresen.ninja/doe=
s-more-transactions-necessarily-mean-more-centralized">http://gavinandresen=
.ninja/does-more-transactions-necessarily-mean-more-centralized</a></div><d=
iv><p style=3D"line-height:1.5;margin:20px auto;color:rgb(77,77,77);font-fa=
mily:proxima-nova,Helvetica,Avenir,Arial,sans-serif;padding-left:10px;paddi=
ng-right:10px;max-width:600px"><i>I chose 20MB as a reasonable block size t=
o target because 170 gigabytes per month comfortably fits into the typical =
250-300 gigabytes per month data cap=E2=80=93 so you can run a full node fr=
om home on a =E2=80=9Cpretty good=E2=80=9D broadband plan.</i></p></div><di=
v>Did you think 20mb was picked randomly?</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">Agreed on the first sentence, I&#39;m just saying that =
the influence of<br>
the blocksize in that function is monotonic: with bigger sizes, equal<br>
or worse mining centralization.<br></blockquote><div><br></div><div>I have =
a hard time agreeing with this because I&#39;ve seen Bitcoin go from blocks=
 that were often empty to blocks that are often full, and in this time the =
number of miners and hash power on the network has gone up a huge amount to=
o.</div><div><br></div><div>You can argue that a miner doesn&#39;t count if=
 they pool mine. But if a miner mines on a pool that uses exactly the same =
software and settings as the miner would have done anyway, then it makes no=
 difference. Miners can switch between pools to find one that works the way=
 they like, so whilst less pooling or more decentralised pools would be nic=
e (e.g. getblocktemplate), and I&#39;ve written about how to push it forwar=
d before, I still say there are many more miners than in the past.</div><di=
v><br></div><div>If I had to pick between two changes to improve mining dec=
entralisation:</div><div><br></div><div>1) Lower block size</div><div>2) Fi=
nishing, documenting, and making the UX really slick for a getblocktemplate=
 based decentralised mining pool</div><div><br></div><div>then I&#39;d pick=
 (2) in a heartbeat. I think it&#39;d be a lot more effective.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">you should be=C2=A0consequently =
advocating for full removal of the limit rather than=C2=A0changes towards b=
igger arbitrary values.<br></blockquote><div><br></div><div>I did toy with =
that idea a while ago. Of course there can not really be no limit at all be=
cause the code assumes blocks fit into RAM/swap, and nodes would just end u=
p ignoring blocks they couldn&#39;t download in time anyway. There is obvio=
usly a physical limit somewhere.=C2=A0</div><div><br></div><div>But it is e=
asier to find common ground with others by compromising. Is 8mb better than=
 no limit? I don&#39;t know and I don&#39;t care much: =C2=A0I think Bitcoi=
n adoption is a slow, hard process and we&#39;ll be lucky to increase avera=
ge usage 8x over the next couple of years. So if 8mb+ is better for others,=
 that&#39;s OK by me.</div><div>=C2=A0</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span class=3D"">
</span>Sorry, I don&#39;t know about Pieter, but I was mostly talking about=
<br>
mining centralization, certainly not about payment services.<br></blockquot=
e><div><br></div><div>OK. I write these emails for other readers too :) In =
the past for instance, developers who run services without running their ow=
n nodes has come up.</div><div>=C2=A0</div><div>Re: exchange profit. You ca=
n pick some other useful service provider if you like. Payment processors o=
r cold storage providers or the TREZOR manufacturers or whoever.</div><div>=
<br></div><div>My point is you can&#39;t have a tiny high-value-transaction=
s only currency AND all the useful infrastructure that the Bitcoin communit=
y is making. It&#39;s a contradiction. And without the infrastructure bitco=
in ceases to be interesting even to people who are willing to pay huge sums=
 to use it.</div></div><br></div></div>

--089e011849e64c60a0051c2d0fcd--