path: root/f4/9c2124b16b419eade539596fc094885291575d

Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 89FEC405
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 10:16:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 626051A0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 10:16:17 +0000 (UTC)
Received: from mail-qg0-f54.google.com ([209.85.192.54]) by mrelay.perfora.net
	(mreueus001) with ESMTPSA (Nemesis) id 0MEm44-1Z5D2o1mxu-00FzsD for
	<bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 12:16:16 +0200
Received: by qgeh16 with SMTP id h16so42011034qge.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Jul 2015 03:16:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.141.23.199 with SMTP id z190mr2961381qhd.34.1438337775576;
	Fri, 31 Jul 2015 03:16:15 -0700 (PDT)
Received: by 10.96.226.68 with HTTP; Fri, 31 Jul 2015 03:16:15 -0700 (PDT)
Received: by 10.96.226.68 with HTTP; Fri, 31 Jul 2015 03:16:15 -0700 (PDT)
In-Reply-To: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
Date: Fri, 31 Jul 2015 12:16:15 +0200
Message-ID: <CALqxMTFhfwvcqY0dSoq489kA9G8YkQZPkzJDEU1eQHsupq-31g@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a114237542e3771051c291c7d
X-Provags-ID: V03:K0:Ab6asVuQKxYohyh1az+yyKz21WnWwAQLZDfcmAyMMhxnbD6cNfu
	5XHcJQROgB4hk+df9eWhAXJTjfXx9gDL8oCFy8Hcn/CboU4u+qwTGxpqXQNkts3oR4jre80
	8R6YzEErbbErhmCgkNYezqNmD7eOg2N8LN9GdR4D2QoTOWoKx4kT6Zx7llEkGa1l6rPQYSG
	TFQJ8xAqtTvAvzsImXhIg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:zfs/vEJ9jGQ=:TOwODSVe1gUVfZVLiY1QZ4
	f0dkKtNsYyn3AchhslLL8k6ml6TOjAecdmtGKj8xt18ge+ed4crf3xpWUj3kXxOTDkISf861s
	+AJuiMYStJrfYT5c1VCzRLtdluwepwBiC3ZUrAMMfntRLjd0yBn1KKzSEjGHlKuDdgvaSIBUV
	scwEcgIZ1Z5jLtjd8WpH+c7C9M6UcK1ncyl2l2W9WuEoEDh2wGrNk9c5jgDwNSo1PmDNgc/uW
	szvnyl/X5/PsR1+jg4l2UKrRyHBU06C3/Dsj8HvTq131PbstqWt2kYKh3lXzlBzhyHzDHXIpS
	BG1jpGv976SteAScBuADzj/d+qK6oNUTVJh9HWkcRRztQOXofac8akwNha/C4H0YqGeiBdQ7g
	Fn60HfmQBFImzCu0X6cpVyXlcoGLJKXQ64WiktoNYdaS8XmkH9q17UbGfLW1vQ2+RUeY2Ujp/
	bJnbKIPwyyEOn2OYhkgWJSlZ8tSDbKVozVTEpHUJhwz0YrSOzArT0vE/VW5gFNPngZXaTmXDA
	T3JN+AGJGrkMIajP1MlMjydUeEghOktX3EMFm+V0r+TdlDN2BHPVbzIHlFh9kA38OGTfo5C0D
	6pKUsR7sPAr6eooWNpjnpWcEyoYUFGC0RxFx66qmO9wtOzUpgWr+4to/q5ew5QMHOsEVWeo4n
	k3DgcvutGx/KJTWZpUnOX+VcZE8izL89F72ELcvlraI9UZA==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	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: Fri, 31 Jul 2015 10:16:18 -0000

--001a114237542e3771051c291c7d
Content-Type: text/plain; charset=UTF-8

I think trust the data-center logic obviously fails, and I was talking
about this scenario in the post you are replying to.  You are trusting the
data-center operator period.  If one could trust data-centers to run
verified code, to not get hacked, filter traffic, respond to court orders
without notifying you etc that would be great but that's unfortunately not
what happens.

Data-center operators are bound to follow laws, including NSLs and gag
orders.  They also get hacked, employ humans who can be corrupt,
blackmailed, and themselves centralisation points for policy attack.
Snowden related disclosures and keeping aware of security show this is very
real.

This isn't much about bitcoin even, its just security reality for hosting
anything intended to be secure via decentralisation, or just hosting in
general while at risk of political or policy attack.

Adam
On Jul 31, 2015 10:39, "jl2012 via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There is a summary of the proposals in my previous mail at
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
>
> I think there could be a compromise between Gavin's BIP101 and Pieter's
> proposal (called "BIP103" here). Below I'm trying to play with the
> parameters, which reasons:
>
> 1. Initiation: BIP34 style voting, with support of 750 out of the last
> 1000 blocks. The "hardfork bit" mechanism might be used:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
>
> Rationale: This follows BIP101, to make sure the new chain is secure.
> Also, no miner would like to be the first one to mine a large block if they
> don't know how many others would accept it.
>
> 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.
>
> 2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China.
> Most pool operators and devs should be back from new year holiday and not
> sleeping. (If the initiation is delayed, we may require that it must be UTC
> Tuesday midnight)
>
> 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.
>
> 4. After 8MB is reached, the block size will be increased by 6.714% every
> 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or
> double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on
> 2042-11-17.
>
> Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
> p.a. of BIP101. This will take us almost 8 years from now just to go back
> to the original 32MB size (4 years for BIP101 and 22 years for BIP103)
>
> SSD price is expected to drop by >50%/year in the coming years. In 2020,
> we will only need to pay 2% of current price for SSD. 98% price reduction
> is enough for 40 years of 27.67% growth.
> Source:
> http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
>
> 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-forecast-service/
>
> The final cap is a compromise between 8192MB@2036 of BIP101 and
> 2048MB@2063 of BIP103
>
>
> -----------------------------------
>
> Generally speaking, I think we need to have a faster growth in the
> beginning, just to normalize the block size to a more reasonable one. After
> all, the 1MB cap was introduced when Bitcoin was practically worthless and
> with inefficient design. We need to decide a new "optimal" size based on
> current adoption and technology.
>
> About "fee market": I do agree we need a fee market, but the fee pressure
> must not be too high at this moment when block reward is still miner's main
> income source. We already have a fee market: miners will avoid building big
> blocks with low fee because that will increase the orphan risk for nothing.
>
> About "secondary layer": I respect everyone building secondary layer over
> the blockchain. However, while the SWIFT settlement network is processing
> 300tps, Bitcoin's current 7tps is just nothing more than an experiment. If
> the underlying settlement system does not have enough capacity, any
> secondary layer built on it will also fall apart. For example, people may
> DoS attack a Lightening network by provoking a huge amount of settlement
> request which some may not be confirmed on time. Ultimately, this will
> increase the risk of running a LN service and increase the tx fee inside
> LN. After all, the value of secondary layer primarily comes from instant
> confirmation, not scarcity of the block space.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<p dir=3D"ltr">I think trust the data-center logic obviously fails, and I w=
as talking about this scenario in the post you are replying to.=C2=A0 You a=
re trusting the data-center operator period.=C2=A0 If one could trust data-=
centers to run verified code, to not get hacked, filter traffic, respond to=
 court orders without notifying you etc that would be great but that&#39;s =
unfortunately not what happens.</p>
<p dir=3D"ltr">Data-center operators are bound to follow laws, including NS=
Ls and gag orders.=C2=A0 They also get hacked, employ humans who can be cor=
rupt, blackmailed, and themselves centralisation points for policy attack.=
=C2=A0 Snowden related disclosures and keeping aware of security show this =
is very real.</p>
<p dir=3D"ltr">This isn&#39;t much about bitcoin even, its just security re=
ality for hosting anything intended to be secure via decentralisation, or j=
ust hosting in general while at risk of political or policy attack.</p>
<p dir=3D"ltr">Adam</p>
<div class=3D"gmail_quote">On Jul 31, 2015 10:39, &quot;jl2012 via bitcoin-=
dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">There is a summary of the proposals in my prev=
ious mail at <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2015-July/009808.html" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html</a><br>
<br>
I think there could be a compromise between Gavin&#39;s BIP101 and Pieter&#=
39;s proposal (called &quot;BIP103&quot; here). Below I&#39;m trying to pla=
y with the parameters, which reasons:<br>
<br>
1. Initiation: BIP34 style voting, with support of 750 out of the last 1000=
 blocks. The &quot;hardfork bit&quot; mechanism might be used: <a href=3D"h=
ttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html=
" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2015-July/009576.html</a><br>
<br>
Rationale: This follows BIP101, to make sure the new chain is secure. Also,=
 no miner would like to be the first one to mine a large block if they don&=
#39;t know how many others would accept it.<br>
<br>
2. Starting date: 30 days after 75% miner support, but not before 2016-01-1=
2 00:00 UTC<br>
<br>
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 jus=
t do it on the 364th day if they opt to procrastinate.<br>
<br>
2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China. =
Most pool operators and devs should be back from new year holiday and not s=
leeping. (If the initiation is delayed, we may require that it must be UTC =
Tuesday midnight)<br>
<br>
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 20=
17-05-11.<br>
<br>
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: <a href=3D"=
https://bitcointalk.org/index.php?topic=3D1054482.0" rel=3D"noreferrer" tar=
get=3D"_blank">https://bitcointalk.org/index.php?topic=3D1054482.0</a>). 8M=
B is also agreed by Chinese miners, who control &gt;60% of the network.<br>
<br>
4. After 8MB is reached, the block size will be increased by 6.714% every 9=
7 days, which is equivalent to exactly octuple (8x) every 8.5 years, or dou=
ble every 2.9 years, or +27.67% per year. Stop growth at 4096MB on 2042-11-=
17.<br>
<br>
Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4% p.a.=
 of BIP101. This will take us almost 8 years from now just to go back to th=
e original 32MB size (4 years for BIP101 and 22 years for BIP103)<br>
<br>
SSD price is expected to drop by &gt;50%/year in the coming years. In 2020,=
 we will only need to pay 2% of current price for SSD. 98% price reduction =
is enough for 40 years of 27.67% growth.<br>
Source: <a href=3D"http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_A=
rchitectures" rel=3D"noreferrer" target=3D"_blank">http://wikibon.org/wiki/=
v/Evolution_of_All-Flash_Array_Architectures</a><br>
<br>
Global bandwidth is expected to grow by 37%/year until 2021 so 27.67% shoul=
d be safe at least for the coming 10 years.<br>
Source: <a href=3D"https://www.telegeography.com/research-services/global-b=
andwidth-forecast-service/" rel=3D"noreferrer" target=3D"_blank">https://ww=
w.telegeography.com/research-services/global-bandwidth-forecast-service/</a=
><br>
<br>
The final cap is a compromise between 8192MB@2036 of BIP101 and 2048MB@2063=
 of BIP103<br>
<br>
<br>
-----------------------------------<br>
<br>
Generally speaking, I think we need to have a faster growth in the beginnin=
g, just to normalize the block size to a more reasonable one. After all, th=
e 1MB cap was introduced when Bitcoin was practically worthless and with in=
efficient design. We need to decide a new &quot;optimal&quot; size based on=
 current adoption and technology.<br>
<br>
About &quot;fee market&quot;: I do agree we need a fee market, but the fee =
pressure must not be too high at this moment when block reward is still min=
er&#39;s main income source. We already have a fee market: miners will avoi=
d building big blocks with low fee because that will increase the orphan ri=
sk for nothing.<br>
<br>
About &quot;secondary layer&quot;: I respect everyone building secondary la=
yer over the blockchain. However, while the SWIFT settlement network is pro=
cessing 300tps, Bitcoin&#39;s current 7tps is just nothing more than an exp=
eriment. If the underlying settlement system does not have enough capacity,=
 any secondary layer built on it will also fall apart. For example, people =
may DoS attack a Lightening network by provoking a huge amount of settlemen=
t request which some may not be confirmed on time. Ultimately, this will in=
crease the risk of running a LN service and increase the tx fee inside LN. =
After all, the value of secondary layer primarily comes from instant confir=
mation, not scarcity of the block space.<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--001a114237542e3771051c291c7d--