path: root/2f/6692d71436cce91621ce7796b4858d2db08944

Return-Path: <venzen@mail.bihthai.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F0AA282
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Aug 2015 10:38:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bihthai.net (unknown [5.255.87.165])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 251EFED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Aug 2015 10:38:35 +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 4D8F120C0E;
	Sun,  2 Aug 2015 12:40:09 +0200 (CEST)
Message-ID: <55BDF31D.1010803@mail.bihthai.net>
Date: Sun, 02 Aug 2015 17:38:21 +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: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>	<CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com>	<bbdbc08925ca3416f0f9982466b98413@xbt.hk>
	<CAPg+sBhQV7ymm3sDW44DWr1FEfgoGoTfMva1iTbZXHcf==mYbw@mail.gmail.com>
In-Reply-To: <CAPg+sBhQV7ymm3sDW44DWr1FEfgoGoTfMva1iTbZXHcf==mYbw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,LOTS_OF_MONEY,
	RDNS_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal
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: Sun, 02 Aug 2015 10:38:37 -0000

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

+1 on every point, sipa

On 08/02/2015 05:32 PM, Pieter Wuille via bitcoin-dev wrote:
>>>> 2. Starting date: 30 days after 75% miner support, but not
>>>> before 2016-01-12 00:00 UTC
>>>> 
>>>> Rationale: A 30-day grace period is given to make sure
>>>> everyone has enough time to follow. This is a compromise
>>>> between 14 day in BIP101 and 1 year in BIP103. I tend to
>>>> agree with BIP101. Even 1 year is given, people will just do
>>>> it on the 364th day if they opt to procrastinate.
>>> 
>>> 
>>> Given the time recent softforks have taken to deploy, I think
>>> that's too soon.
>> 
>> 
>> Since I'm using "30 days after 75% miner support", the actual
> deployment period will be longer than 30 days. Anyway, if all
> major exchanges and merchants agree to upgrade, people are forced
> to upgrade immediately or they will follow a worthless chain.
> 
> If we don't want it to go fast, why let them? A hardfork is a means
> for the community to agree on the rules that different parties have
> to obey.
> 
>>>> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and 
>>>> multiplied by 1.414213 by every 2^23 seconds (97 days) until
>>>> exactly 8MB is reached on 2017-05-11.
>>>> 
>>>> Rationale: Instead of jumping to 8MB, I suggest to increase
>>>> it gradually to 8MB in 16 months. 8MB should not be
>>>> particularly painful to run even with current equipment (you
>>>> may see my earlier post on bitctointalk: 
>>>> https://bitcointalk.org/index.php?topic=1054482.0 ). 8MB is
>>>> also
>>>> 
>>>> agreed by Chinese miners, who control >60% of the network.
>>> 
>>> 
>>> I have considered suggesting a faster ramp-up in the beginning,
>>> but I don't think there is indisputable evidence that we can
>>> currently deal with significantly larger blocks. I don't think
>>> "painful" is the right criterion either; I'm sure my equipment
>>> can "handle" 20 MB blocks too, but with a huge impact on
>>> network propagation speed, and even more people choosing the
>>> outsource their full nodes.
>>> 
>>> Regarding "reasonable", I have a theory. What if we would have
>>> had 8 MB blocks from the start? My guess is that some more
>>> people would have decided to run their high-transaction-rate
>>> use cases on chain, that we'd regularly see 4-6 MB blocks,
>>> there would be more complaints about low full node counts,
>>> maybe 90% instead of 60% of the hash rate would be have SPV
>>> mining agreements with each other, we'd somehow have accepted
>>> that even worse reality, but people would still be complaining
>>> about the measly 25 transactions per second that Bitcoin could
>>> handle on-chain, and be demanding a faster rampup to a more 
>>> "reasonable" 64 MB block size as well.
>> 
>> 
>> Since the block reward is miners' major income source, no
>> rational
> miner would create mega blocks unless the fee could cover the
> extra orphaning risk. Blocks were not constantly full until recent
> months, and many miners are still keeping the 750kB soft limit.
> This strongly suggests that we won't have 4MB blocks now even
> Satoshi set a 8MB limit.
> 
> I disagree. I think "demand" is strongly influenced by the
> knowledge of space that looks available. If you look at historic
> block sizes, you see it follows a series of block functions, not
> nice organic growth. My theory is that this is changed defaults in
> software, new services appearing suddenly, and people reacting to
> it. Demand fills the available space.
> 
> Also, SPV mining has nearly zero orphaning risk, only brief chance
> of loss of fees as income.
> 
>> I don't have the data now but I believe the Satoshi Dice model
>> failed
> not primarily due to the 1MB cap, but the raise in BTC/USD rate.
> Since minting reward is a fixed value in BTC, the tx fee must also
> be valued in BTC as it is primarily for compensating the extra
> orphaning risk. As the BTC/USD rate increases, the tx fee measured
> in USD would also increase, making micro-payment (measured in USD)
> unsustainable.
> 
> I agree, but how does that matter? I don't think high fees and
> full blocks should be the goal, but I think it would be a healthier
> outcome than what we have now.
> 
>> We might have less full nodes, but it was Satoshi's original
>> plan: "At
> first, most users would run network nodes, but as the network
> grows beyond a certain point, it would be left more and more to
> specialists with server farms of specialized hardware. A server
> farm would only need to have one node on the network and the rest
> of the LAN connects with that one node." Theoretically, we only
> require one honest full node to prove wrongdoing on the blockchain
> and tell every SPV nodes to blacklist the invalid chain.
> 
> Theoretically, we also only need one central bank, then? Sorry, if
> the outcome is one (or just a few) entities that keep the system in
> check, I think it loses any benefit it has over other systems,
> while still keeping its costs and disadvantages (confirmation
> speed, mining infrastructure, subsidy...).
> 
> I know that 8 MB blocks do not immediately mean such a dramatic
> outcome. But I do believe that as a community setting the block
> size based on observed demand (which you do by saying "8 is a more
> reasonable size than 2" as argument) is the wrong way. What do you
> do when your 8 MB starts to look "full", before your schedule says
> it can increase?
> 
> The block size and its costs - bandwidth, processing,
> centralization effects for miners, ... - are the things that should
> be constrained. Demand will fill it.
> 
>> I think SPV mining exists long before the 1MB block became full,
>> and I
> don't think we could stop this trend by artificially suppressing
> the block size. Miners should just do it properly, e.g. stop mining
> until the grandparent block is verified, which would make sure an
> invalid fork won't grow beyond 2 blocks.
> 
> That would be a huge reduction in security as a mechanism itself,
> and even worse due to needing to trust miners to follow that
> protocol. Without proper incentives, miners become a trusted party,
> and due to needed SPV mining agreements, potentially a closed group
> too. That is not an interesting future.
> 
>> If you believe Bitcoin should become a global settlement network,
>> 32MB
> would be the very minimum as that is only 75% of current SWIFT
> traffic.
> 
> See my BIP text about advantages of Bitcoin, please. A future where
> it has to compete with the existing system - using that system's
> own strengths - is not interesting.
> 
> -- Pieter
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVvfMbAAoJEGwAhlQc8H1mzNwH/RqAWfpio7eMrgrtF9Itstp2
6aSC5wMWlmG9lfusbRD75Ks+27C7ZH1AHcjI1H7V0tvWkYZHsZGQLlVH3fTbcZM8
LVC650sEAlCAenxV+5q6Gn9GW65CpKDmTkWOiLs5Z2/sQaDFWsxk4F7Em8D0JDRe
H3RPYRQg2eGW8r1s/pZU0gLrqduHTpigWNrL4znPqNFBfAXChdH1xrMnTiB6vJGA
73d/N/XrklzqLAHrSakhjctxRo4Ya57/uLW6FP/ey/UDKytG2DqhsakCPn73J/mI
Im7xbMtUBnCXxB6Ow8n78lxE1+ib/ntjoX9MqDmqNxRLFViWIO34vmVsHpC2RS4=
=kQ2U
-----END PGP SIGNATURE-----