path: root/73/b74ac8d6e4c6d783de96a12f8592be4e6af8bf

Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 11143FF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Aug 2015 08:03:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDF80EA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Aug 2015 08:03:42 +0000 (UTC)
Received: from cotinga.riseup.net (unknown [10.0.1.161])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "*.riseup.net",
	Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.riseup.net (Postfix) with ESMTPS id 5F41C41B11;
	Sun,  2 Aug 2015 08:03:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1438502622; bh=k/ont7LsmRa8DdJD11thInrTzcinXlOIw76rH3+G6Qg=;
	h=Date:From:To:CC:Subject:References:In-Reply-To:From;
	b=RbPhtTk7IAmB5evnqn9OLLRokzYRm37TDrCnhtFqMhV+NEdVBb99hWgFCac9iWZC6
	9Kc8fyQCYP12IzxduTTTA9n8UlwgUdZd48UM+/z7/SfVsT0puIurn2LguF6Apju4vB
	fBXgznPegU7bJmMsyipu/MDDe/i+3kETzFvvan1Y=
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: odinn.cyberguerrilla)
	with ESMTPSA id 92DD91C0093
Message-ID: <55BDCEDC.8060908@riseup.net>
Date: Sun, 02 Aug 2015 01:03:40 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: jl2012@xbt.hk, Pieter Wuille <pieter.wuille@gmail.com>
References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>	<CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com>
	<bbdbc08925ca3416f0f9982466b98413@xbt.hk>
In-Reply-To: <bbdbc08925ca3416f0f9982466b98413@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, LOTS_OF_MONEY, RCVD_IN_DNSWL_LOW,
	RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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@lists.linuxfoundation.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 08:03:44 -0000

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

I am in favor of a more gradual (longer) period and a softforking
solution... that is, more than 30 days of grace period (some period
between 60 days and a year), ...

... and given the number of valid softforking proposals out there it
seems to me that it would be rather simple to see one or more (e.g.
Cameron Garnham's dynamic block size adjustment (needing soft fork
only)) in a BIP.

It is also worthwhile to add that some of the softforking proposals,
and I believe Garnham's to be one of them, are not incompatible with
proposals such as Jeff Garzik's BIP 100, that is to say, there is
nothing keeping you from doing the Garnham dynamic block size
adjustment (softfork) right now today, examining its progress and
effect, while also preparing for a Garzik (BIP 100) for example.

- - Odinn

On 08/02/2015 12:16 AM, jl2012 via bitcoin-dev wrote:
> Pieter Wuille 於 2015-08-01 16:45 寫到:
>> On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev 
>> <bitcoin-dev@lists.linuxfoundation.org> 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.
> 
> 
>> 
>>> 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 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.
> 
> 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.
> 
> 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.
> 
> 
> 
>>> Global bandwidth is expected to grow by 37%/year until 2021 so 
>>> 27.67% should be safe at least for the coming 10 years. 
>>> Source:
>>> 
>> https://www.telegeography.com/research-services/global-bandwidth-fore
cast-service/
>>
>
>> 
>> 
>> I'd rather be conservative here. My primary purpose is trying to 
>> create an uncontroversial proposal that introduces an expectation
>> of growth with technology.
> 
> If we could have a longer initial ramp up period, we may adopt a
> slower long term parameter. I think we should at least restore the
> original 32MB limit in a reasonable time frame, say 6-8 years,
> instead of 20 years in your proposal. 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. 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVvc7bAAoJEGxwq/inSG8CPIMH/RjIEWuig7oBQxA3sX0TNoDL
ohNcXyaa69lTJ8M5kfihWEgxKrEBJ8H/yp0rxIz/B5SfOCgTho9Yzyj4KrJ+qTvs
M4x2/9YthVvIBuJ5g8IbYVH73pNNR+xPnR1VikbffmGsWNIN3kYgDWUeO1qVWswd
y0eySo/8KdaPR7ojyF03l028Uejv4uSHCy8W0FHo6lyEBUAfIOeQULMYllyUbN2S
B3K5si6Swar93EQZ510PfB1u4DMK26ITXhK+Hxx67cjHu7F1lvyl+zzncUlpXrDM
b30f0kYImFV96vIGlEh+MVLzS1SAkaPW/S5K9fdZ97tYfwXC5az1ki0hUapnujU=
=6VEW
-----END PGP SIGNATURE-----