path: root/ad/dced539c0121e6a52826dd791737fd7d3d6a6f

Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 32741267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Aug 2015 10:32:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com
	[209.85.213.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EF6C7F2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Aug 2015 10:32:54 +0000 (UTC)
Received: by igk11 with SMTP id 11so56350986igk.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 02 Aug 2015 03:32:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=WJflGUAIK2Qtr/8InzfWzJsWKEqs3h7k1Jv77jsMX2I=;
	b=a+KxSIpowzC+AFDSo1MFZmgrOP6t8DnF6oG1MUAjNp62DdirICMFKVEMLAdTv55OZO
	y/W599+1r8HBg0pkDLwl9HdbCQe0FAXlBajsH0VA6kcwBVPRXPiOhu/U7y5XmE9a4+ho
	SYjQOQuue2fkGYZm8tiI+S3BooZ1768GPDhK0ELl7p/46Mn87dVLbqQpjpXzcGaMutbs
	DxW+PaWoCo/NgdVNP29uCvr7YR/GNVBez/jR4q7udE/3Pp7A+CR+vceJxIzYeD/gfTQU
	xPwsx0eIWsmMk2Vob3Q6u8YlOydPpmrantVPkYUrYqNImgiT8dguYPjnOVjVx3ZyoEt5
	7cFA==
MIME-Version: 1.0
X-Received: by 10.50.93.69 with SMTP id cs5mr17042828igb.4.1438511574357; Sun,
	02 Aug 2015 03:32:54 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Sun, 2 Aug 2015 03:32:53 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Sun, 2 Aug 2015 03:32:53 -0700 (PDT)
In-Reply-To: <bbdbc08925ca3416f0f9982466b98413@xbt.hk>
References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
	<CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com>
	<bbdbc08925ca3416f0f9982466b98413@xbt.hk>
Date: Sun, 2 Aug 2015 12:32:53 +0200
Message-ID: <CAPg+sBhQV7ymm3sDW44DWr1FEfgoGoTfMva1iTbZXHcf==mYbw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=089e01537ed8651c34051c5193bf
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
	RCVD_IN_DNSWL_LOW 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 <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 10:32:56 -0000

--089e01537ed8651c34051c5193bf
Content-Type: text/plain; charset=UTF-8

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

--089e01537ed8651c34051c5193bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">&gt;&gt;&gt; 2. Starting date: 30 days after 75% miner suppo=
rt, but not before<br>
&gt;&gt;&gt; 2016-01-12 00:00 UTC<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Rationale: A 30-day grace period is given to make sure everyon=
e has<br>
&gt;&gt;&gt; enough time to follow. This is a compromise between 14 day in =
BIP101<br>
&gt;&gt;&gt; and 1 year in BIP103. I tend to agree with BIP101. Even 1 year=
 is<br>
&gt;&gt;&gt; given, people will just do it on the 364th day if they opt to<=
br>
&gt;&gt;&gt; procrastinate.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Given the time recent softforks have taken to deploy, I think that=
&#39;s<br>
&gt;&gt; too soon.<br>
&gt;<br>
&gt;<br>
&gt; Since I&#39;m using &quot;30 days after 75% miner support&quot;, the a=
ctual deployment period will be longer than 30 days. Anyway, if all major e=
xchanges and merchants agree to upgrade, people are forced to upgrade immed=
iately or they will follow a worthless chain.</p>
<p dir=3D"ltr">If we don&#39;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.</p>
<p dir=3D"ltr">&gt;&gt;&gt; 3. The block size at 2016-01-12 will be 1,414,2=
13 bytes, and<br>
&gt;&gt;&gt; multiplied by 1.414213 by every 2^23 seconds (97 days) until e=
xactly<br>
&gt;&gt;&gt; 8MB is reached on 2017-05-11.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Rationale: Instead of jumping to 8MB, I suggest to increase it=
<br>
&gt;&gt;&gt; gradually to 8MB in 16 months. 8MB should not be particularly<=
br>
&gt;&gt;&gt; painful to run even with current equipment (you may see my ear=
lier<br>
&gt;&gt;&gt; post on bitctointalk:<br>
&gt;&gt;&gt; <a href=3D"https://bitcointalk.org/index.php?topic=3D1054482.0=
">https://bitcointalk.org/index.php?topic=3D1054482.0</a> ). 8MB is also<br=
>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; agreed by Chinese miners, who control &gt;60% of the network.<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I have considered suggesting a faster ramp-up in the beginning, bu=
t I<br>
&gt;&gt; don&#39;t think there is indisputable evidence that we can current=
ly deal<br>
&gt;&gt; with significantly larger blocks. I don&#39;t think &quot;painful&=
quot; is the right<br>
&gt;&gt; criterion either; I&#39;m sure my equipment can &quot;handle&quot;=
 20 MB blocks too,<br>
&gt;&gt; but with a huge impact on network propagation speed, and even more=
<br>
&gt;&gt; people choosing the outsource their full nodes.<br>
&gt;&gt;<br>
&gt;&gt; Regarding &quot;reasonable&quot;, I have a theory. What if we woul=
d have had 8<br>
&gt;&gt; MB blocks from the start? My guess is that some more people would =
have<br>
&gt;&gt; decided to run their high-transaction-rate use cases on chain, tha=
t<br>
&gt;&gt; we&#39;d regularly see 4-6 MB blocks, there would be more complain=
ts about<br>
&gt;&gt; low full node counts, maybe 90% instead of 60% of the hash rate wo=
uld<br>
&gt;&gt; be have SPV mining agreements with each other, we&#39;d somehow ha=
ve<br>
&gt;&gt; accepted that even worse reality, but people would still be<br>
&gt;&gt; complaining about the measly 25 transactions per second that Bitco=
in<br>
&gt;&gt; could handle on-chain, and be demanding a faster rampup to a more<=
br>
&gt;&gt; &quot;reasonable&quot; 64 MB block size as well.<br>
&gt;<br>
&gt;<br>
&gt; Since the block reward is miners&#39; major income source, no rational=
 miner would create mega blocks unless the fee could cover the extra orphan=
ing risk. Blocks were not constantly full until recent months, and many min=
ers are still keeping the 750kB soft limit. This strongly suggests that we =
won&#39;t have 4MB blocks now even Satoshi set a 8MB limit.</p>
<p dir=3D"ltr">I disagree. I think &quot;demand&quot; is strongly influence=
d by the knowledge of space that looks available. If you look at historic b=
lock sizes, you see it follows a series of block functions, not nice organi=
c growth. My theory is that this is changed defaults in software, new servi=
ces appearing suddenly, and people reacting to it. Demand fills the availab=
le space.</p>
<p dir=3D"ltr">Also, SPV mining has nearly zero orphaning risk, only brief =
chance of loss of fees as income.</p>
<p dir=3D"ltr">&gt; I don&#39;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/U=
SD 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 r=
isk. As the BTC/USD rate increases, the tx fee measured in USD would also i=
ncrease, making micro-payment (measured in USD) unsustainable.</p>
<p dir=3D"ltr">I agree, but how does that matter? I don&#39;t think high fe=
es and full blocks should be the goal, but I think it would be a healthier =
outcome than what we have now.</p>
<p dir=3D"ltr">&gt; We might have less full nodes, but it was Satoshi&#39;s=
 original plan: &quot;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.&quot; Theoretically, we only require one honest full n=
ode to prove wrongdoing on the blockchain and tell every SPV nodes to black=
list the invalid chain.</p>
<p dir=3D"ltr">Theoretically, we also only need one central bank, then? Sor=
ry, 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 infrastruct=
ure, subsidy...).</p>
<p dir=3D"ltr">I know that 8 MB blocks do not immediately mean such a drama=
tic outcome. But I do believe that as a community setting the block size ba=
sed on observed demand (which you do by saying &quot;8 is a more reasonable=
 size than 2&quot; as argument) is the wrong way. What do you do when your =
8 MB starts to look &quot;full&quot;, before your schedule says it can incr=
ease?</p>
<p dir=3D"ltr">The block size and its costs - bandwidth, processing, centra=
lization effects for miners, ... - are the things that should be constraine=
d. Demand will fill it.</p>
<p dir=3D"ltr">&gt; I think SPV mining exists long before the 1MB block bec=
ame full, and I don&#39;t think we could stop this trend by artificially su=
ppressing the block size. Miners should just do it properly, e.g. stop mini=
ng until the grandparent block is verified, which would make sure an invali=
d fork won&#39;t grow beyond 2 blocks.</p>
<p dir=3D"ltr">That would be a huge reduction in security as a mechanism it=
self, and even worse due to needing to trust miners to follow that protocol=
. Without proper incentives, miners become a trusted party, and due to need=
ed SPV mining agreements, potentially a closed group too. That is not an in=
teresting future.</p>
<p dir=3D"ltr">&gt; If you believe Bitcoin should become a global settlemen=
t network, 32MB would be the very minimum as that is only 75% of current SW=
IFT traffic.</p>
<p dir=3D"ltr">See my BIP text about advantages of Bitcoin, please. A futur=
e where it has to compete with the existing system - using that system&#39;=
s own strengths - is not interesting.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>

--089e01537ed8651c34051c5193bf--