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 9F0AA282 for ; 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 ; 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 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 , Bitcoin Dev References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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-----