From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F417CFF for ; 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 ; Fri, 31 Jul 2015 14:58:59 +0000 (UTC) Received: by igk11 with SMTP id 11so33718960igk.1 for ; 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: References: Date: Fri, 31 Jul 2015 16:58:59 +0200 Message-ID: From: Mike Hearn To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
How more users or more nodes can bring more mine= rs, or more=C2=A0importantly, improve mining decentralization?

Because the bigger the ecosystem is the more intere= st there is in taking part?

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?

I'm sorry, but until the= re's a simulation that I can run with=C2=A0different sizes' testcha= ins (for example using #6382) to somehow=C2=A0compare them, I will consider= any value arbitrary.

Gavin did run sim= ulations. 20mb isn't arbitrary, the process behind it was well document= ed here:

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.

Did you think 20mb was picked randomly?
=C2=A0
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 to= o.

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 nic= e (e.g. getblocktemplate), and I've written about how to push it forwar= d before, I still say there are many more miners than in the past.

If I had to pick between two changes to improve mining dec= entralisation:

1) Lower block size
2) Fi= nishing, 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.
= =C2=A0
you should be=C2=A0consequently = advocating for full removal of the limit rather than=C2=A0changes towards b= igger arbitrary values.

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't download in time anyway. There is obvio= usly a physical limit somewhere.=C2=A0

But it is e= asier to find common ground with others by compromising. Is 8mb better than= no limit? I don't know and I don't care much: =C2=A0I think Bitcoi= n adoption is a slow, hard process and we'll be lucky to increase avera= ge usage 8x over the next couple of years. So if 8mb+ is better for others,= that's OK by me.
=C2=A0
=C2=A0
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 ow= n nodes has come up.
=C2=A0
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.
=
My point is you can't have a tiny high-value-transaction= s only currency AND all the useful infrastructure that the Bitcoin communit= y is making. It'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.

--089e011849e64c60a0051c2d0fcd--