+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-----

+