path: root/61/db79807b34adba1b5079c3ed40fb95c7bc5322

Return-Path: <venzen@mail.bihthai.net>
Received: from smtp2.linuxfoundation.org (smtp2.linux-foundation.org
	[172.17.192.36])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6B7BD8D4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 12:11:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bihthai.net (unknown [5.255.87.165])
	by smtp2.linuxfoundation.org (Postfix) with ESMTPS id A0AC81DAA4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Aug 2015 12:11:24 +0000 (UTC)
Received: from [10.8.0.6] (unknown [10.8.0.6])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested) (Authenticated sender: venzen)
	by mail.bihthai.net (Postfix) with ESMTPSA id 10DB720DEA;
	Tue,  4 Aug 2015 14:12:39 +0200 (CEST)
Message-ID: <55C0ABC6.1020406@mail.bihthai.net>
Date: Tue, 04 Aug 2015 19:10:46 +0700
From: Venzen Khaosan <venzen@mail.bihthai.net>
Reply-To: venzen@mail.bihthai.net
Organization: Bihthai Bai Mai
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Hector Chu <hectorchu@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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>	<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>	<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>	<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>	<CAPg+sBjvzxGAPvk6PEhuxWzg00+krY_+goZbCLTWngvrCVCKvA@mail.gmail.com>
	<CAAO2FKFD8X9o3R9KRXdFiBmSiFRm4fHtS7YAJNygMFv5UAY3hg@mail.gmail.com>
In-Reply-To: <CAAO2FKFD8X9o3R9KRXdFiBmSiFRm4fHtS7YAJNygMFv5UAY3hg@mail.gmail.com>
OpenPGP: id=1CF07D66;
	url=pool.sks-keyservers.net
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,RDNS_NONE
	autolearn=no version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp2.linux-foundation.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: Tue, 04 Aug 2015 12:11:26 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2015 06:34 PM, Hector Chu via bitcoin-dev wrote:
> Things apparently aren't bad enough to prevent the majority from 
> clamoring for larger blocks.
> 
> If the majority agreed that things had got worse till this point, 
> and that this was to be blamed on the block size, they would be 
> campaigning for the other direction. Even yourselves aren't asking 
> for a reduction in the block size, as you know full well that you 
> would be laughed out.
> 

Hector, if you could provide data that convinces why 8MB is better
than 6.18MB or 1MB then we'd get out of the realm of opinion and
pointless rhetoric that threatens to keep this debate in a quagmire.
We'd have actual figures to work with and projections to go by.

But fetching "majority" agreement (where from?) does not cut it for
setting Bitcoin on a future path. If we go by that then we'd soon be
giving coinbase rewards to users for being "loyal supporters" because,
as a majority, they think that's what they'd like to see.

If a proposal is demonstrably, and provably, a good idea - and a
developer consensus agrees - then it should go to testing, and
eventually, code. Other than that it's just conjecture and words
without a research paper and data.

In the final analysis, do we want Bitcoin to be steered by an
uninformed and fickle majority, or do we want to use this list as a
forum to present research proposals containing repeatable, verifiable
facts? A progressive process of convincing those most familiar with
Bitcoin's code and operation so they may implement Good Ideas during
the next century and after is surely preferable to Vote-my-code-Coin. :)


> On 4 August 2015 at 12:27, Pieter Wuille <pieter.wuille@gmail.com 
> <mailto:pieter.wuille@gmail.com>> wrote:
> 
> I would say that things already demonstrately got terrible. The 
> mining landscape is very centralized, with apparently a majority 
> depending on agreements to trust each other's announced blocks 
> without validation. Full node count is at its historically lowest 
> value in years, and outsourcing of full validation keeps growing.
> 
> I believe that if the above would have happened overnight, people 
> would have cried wolf. But somehow it happened slow enough, and 
> "things kept working".
> 
> I don't think that this is a good criterion. Bitcoin can "work" 
> with gigabyte blocks today, if everyone uses the same few 
> blockchain validation services, the same few online wallets, and 
> mining is done by a cartel that only allows joining after signing
> a contract so they can sue you if you create an invalid block. Do
> you think people will then agree that "things got demonstratebly 
> worse"?
> 
> Don't turn Bitcoin into something uninteresting, please.
> 
> -- Pieter
> 
> On Aug 4, 2015 1:04 PM, "Hector Chu via bitcoin-dev" 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Mike's position is that he wants the block size limit to
> eventually be removed. That is of course an extreme view.
> Meanwhile, your view that the block size should be artificially
> constrained below the organic growth curve (in a way that will
> penalize a majority of existing and future users) lies at the other
> extreme. The majority position lies somewhere in between (i.e. a
> one-time increase to 8MB). This is the position that ultimately
> matters.
> 
> If the block size is increased to 8MB and things get demonstrably
> a whole lot worse, then you will have a solid leg to stand on. In 
> that case we can always do another hard fork later to reduce the 
> block size back to something smaller, and henceforth the block
> size will never be touched again.
> 
> On 4 August 2015 at 11:35, Jorge Timón 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn@vinumeris.com 
> <mailto:hearn@vinumeris.com>> wrote:
>>> 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?
> 
> As explained by Venzen, this is a non-sequitur.
> 
>> I mean, I guess I don't know how to answer your question.
> 
> I don't know the answer either, that's fine. It's the opposite 
> question that I've been insistently repeating and you've been 
> (consciously or not) consistently evading. But that's also fine 
> because I believe you finally answer it a few lines below.
> 
>> 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.
> 
> The emergence of a btc price enabled the emergence of professional
>  miners, which in turn enabled the emergence of sha256d-specialized
>  hardware production companies. Nothing surprising there. By no 
> means it consitutes an example of how a bigger consensus sizes can 
> cause less mining centralization.
> 
>> Surely the correlation is obvious?
> 
> Correlation does not imply causation. I will better leave it at 
> that...
> 
>>> 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 will 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-centralized
>
>>
>> 
> 
>> 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– so you can run a full node from 
>> home on a “pretty good” broadband plan.
>> 
>> Did you think 20mb was picked randomly?
> 
> No, I think 20 MB was chosen very optimistically, considering 3rd 
> party services rates (not the same service as self-hosting) in the
>  so-called "first world". And then 20 MB goes to 20 GB, again with
>  optimistic and by no means scientific expectations.
> 
> But where the number comes from it's not really what I'm demaning,
>  what I want is some criterion that can tell you that a given size
>  would be "too centralized" but another one isn't. I haven't read 
> any analysis on why 8GB is a better option than 7GB and 9GB for a 
> given criterion (nor one declaring 20 GB a winner over 19 GB or 21 
> GB). A simulation test passing 20 GB but not 21 GB would make it 
> far less arbitrary.
> 
>>> 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.
> 
> I'm of course talking about consensus maximum blocksize, not about
>  actual blocksize. Yes, again, when mining becomes profitable, 
> economic actors tend to appear and get those profits. But don't 
> confuse total hashrate improvements with an "increase in the
> number of miners" or with mining decentralization.
> 
>> 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
> 
> Finally, I think you finally answered my repetitive question here.
>  If I say "Mike Hearn understands that the consensus block size 
> maximum rule is a tool for limitting mining centralization" I'm not
> putting words in your mouth, right? I think many users advocating
> for an increase in the consensus limit don't understand this, which
> is extremely unfortunate for the debate.
> 
>> 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.
> 
> Great! Maybe after 2 mining centralization improves so much that 
> we're confortable not only not lowering it but rather increasing 
> it.
> 
>>> you should be consequently advocating for full removal of the 
>>> limit rather 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.
> 
> Did the fact that you "understand that the consensus block size 
> maximum rule is a tool for limitting mining centralization" 
> influenced your rejection of that idea at all?
> 
>> 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.
> 
> The only way that "not caring much whther we have a consensus
> limit or not" and "understand that the consensus block size maximum
> rule is a tool for limitting mining centralization" at the same
> time is by not caring about mining centralization at all. Is that
> your position?
> 
> If you don't care about having a limit but you don't want to limit
>  transaction volume, then ++current_size will ALWAYs be your 
> "compromise position" and no blocksize increase will ever be enough
> until the limit is completely removed. Is that your position?
> 
>> 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.
> 
> Yes, and I believe the same points stand.
> 
>> 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.
> 
> You keep talking about "high-value-transactions-only" like if 
> non-urgent transaction fees rising from zero to, say, 1 satoshi, 
> would automatically result in that "high-value-transactions-only" 
> Bitcoin. Please, stop talking as if someone was proposing a 
> "high-value-transactions-only" Bitcoin. That may happen but nobody
>  really knows. If it happens it may not be bad thing necessarily 
> (ie bitcoin microtransactions can still happen using trustless 
> payment channels and x is still cheaper than x% for any transacted 
> value higher than 100) but that's really not what we're talking 
> about here so it seems distraction that can only help further 
> polirizing this discussion.
> 
> What we're talking about here is that hitting the limit would 
> (hopefully) make miners start caring about fees. Enough that they 
> stop being irrational about free transactions. If both things 
> happen, non-urgent transaction fees will likely rise (as said, 
> above zero).
> 
> You think that would be a catastrophe for adoption and I disagree.
>  But (as Pieter has repeatedly explained) for any size there will 
> be use cases that will be eventually priced out. So when rising 
> this consensus limit, not increasing centralization should be the 
> priority and the potential impact in market fees a much more 
> secondary concern. Do you agree with this?
> 
> I'm sure there are many intermediate positions between "caring more
> about mining centralization than market fees when deciding about a
> consensus rule that limits mining centralization" and "not caring
> about mining centralization at all". I really don't want to put
> words in your mouth, but I honestly don't know what your position
> is. I don't really know how else can I ask the same question: you
> don't care the consensus maximum blocksize rule being here at all
> or not (you just said that). Is it because you don't think it
> limits mining centralization or because you don't care about
> limiting mining centralization with consensus rules at all? 
> _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> 
> _______________________________________________ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVwKvEAAoJEGwAhlQc8H1m2g4H/i3jcap3C1mt5hG964EWlF42
MC6/P23MWI6o5AO7Ugz6m35IDO+ZfegY3VlAmAaq0KSwKEoZSWV/FIPQPpVOCGeP
CdIGw4M+Q//kRBaxNEnfC3gM7IYHRFfOEwZtVsda5vriem+Yjb4Fk+YoXyONI2j1
0GqmPAIJ5+eA1H/t541/lUDHVzLyymlsWX34MIjX1BWnKQaap+eaMHucu+DrcRHd
GltkKrqRQ/Hngv7PtaQGTPjUHrQglHISl6BMXNMbmxoEHg2RfrRwifiJGnDmEty6
l/Yve6slLtaQA+SIyAun79SUU5+QJOOWDxU2PlXQTRldx+0YQJ60L0GanQ5CHc8=
=EarG
-----END PGP SIGNATURE-----