summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authors7r <s7r@sky-ip.org>2016-12-11 19:11:10 +0200
committerbitcoindev <bitcoindev@gnusha.org>2016-12-11 17:11:52 +0000
commitbe9547108c1cb241b3ab87f47a0a8ad79e3890c7 (patch)
tree66dca0888483bc7793a73038e3684d8d9c0c8f40
parent53f91e6f7dde85d633a74f23dd37f4ce49a4640c (diff)
downloadpi-bitcoindev-be9547108c1cb241b3ab87f47a0a8ad79e3890c7.tar.gz
pi-bitcoindev-be9547108c1cb241b3ab87f47a0a8ad79e3890c7.zip
Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)
-rw-r--r--16/9a618685d101118e2ad61377edc0b1eb08e729164
1 files changed, 164 insertions, 0 deletions
diff --git a/16/9a618685d101118e2ad61377edc0b1eb08e729 b/16/9a618685d101118e2ad61377edc0b1eb08e729
new file mode 100644
index 000000000..6609dc9b9
--- /dev/null
+++ b/16/9a618685d101118e2ad61377edc0b1eb08e729
@@ -0,0 +1,164 @@
+Return-Path: <s7r@sky-ip.org>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 194D05A7
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sun, 11 Dec 2016 17:11:52 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from ob3-6.mailhostbox.com (ob3-6.mailhostbox.com [162.222.225.28])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0201723B
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sun, 11 Dec 2016 17:11:42 +0000 (UTC)
+Received: from [0.0.0.0] (unknown [188.214.129.85])
+ (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
+ (No client certificate requested)
+ (Authenticated sender: s7r@sky-ip.org)
+ by outbound.mailhostbox.com (Postfix) with ESMTPSA id 45BB73604A9;
+ Sun, 11 Dec 2016 17:11:38 +0000 (GMT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org;
+ s=20110108; t=1481476300;
+ bh=4YOhrX3soz0GIczaAX5aFQrDdbqH+/y8Dc3PFPS8GRs=;
+ h=Reply-To:Subject:References:To:From:Date:In-Reply-To;
+ b=iyjxU10qX1J8p4ueghfeVpOR/yvm3zZ7p1LVJ9LqrBx/fdlhojPFH+ZTYJRwt8uGm
+ XhdiDXWFVBoLFjf2jgeoj7BbetRws9dBG5D0Xdavfa/SaMGcEz8MdUf0f4KoqV6yBX
+ l02TMaMoOcybwiMjzp6L7tc1Xtp/8eiEW+lqr1DY=
+Reply-To: s7r@sky-ip.org
+References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
+ <c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
+ <CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
+To: "t. khan" <teekhan42@gmail.com>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+From: s7r <s7r@sky-ip.org>
+Message-ID: <d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
+Date: Sun, 11 Dec 2016 19:11:10 +0200
+User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
+ Thunderbird/45.5.1
+MIME-Version: 1.0
+In-Reply-To: <CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
+Content-Type: multipart/signed; micalg=pgp-sha256;
+ protocol="application/pgp-signature";
+ boundary="ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7"
+X-CMAE-Score: 0
+X-CMAE-Analysis: v=2.1 cv=X4TyUDne c=1 sm=1 tr=0
+ a=dfow1bEn5MXyeC3yr4e2EQ==:117 a=dfow1bEn5MXyeC3yr4e2EQ==:17
+ a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10
+ a=13zjGPudsaEWiJwPRgMA:9 a=WbPmnYzAfxEA:10 a=5TDocmF06BmBDxw5PtEA:9
+ a=QEXdDO2ut3YA:10 a=XWp6eR1vF2W28LyIkrcA:9
+X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93
+X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,URIBL_BLACK 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] Managing block size the same way we do difficulty
+ (aka Block75)
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Protocol 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, 11 Dec 2016 17:11:52 -0000
+
+This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
+--ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7
+Content-Type: multipart/mixed; boundary="fT9s2cAmDuw6tH44n1A79Tbh86PgECAGJ";
+ protected-headers="v1"
+From: s7r <s7r@sky-ip.org>
+Reply-To: s7r@sky-ip.org
+To: "t. khan" <teekhan42@gmail.com>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Message-ID: <d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
+Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
+ (aka Block75)
+References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
+ <c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
+ <CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
+In-Reply-To: <CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
+
+--fT9s2cAmDuw6tH44n1A79Tbh86PgECAGJ
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: quoted-printable
+
+ t. khan wrote:
+> Miners 'gaming' the Block75 system -=20
+> There is no financial incentive for miners to attempt to game the
+> Block75 system. Even if it were attempted and assuming the goal was to
+> create bigger blocks, the maximum possible increase would be 25% over
+> the previous block size. And, that size would only last for two weeks
+> before readjusting down. It would cost them more in transaction fees to=
+
+> stuff the network than they could ever make up. To game the system,
+> they'd have to game it forever with no possibility of profit.
+>=20
+
+This is an incentive, if few miners agree to create a large conglomerate
+that will ultimately control the network.
+
+You miss something obvious that makes this attack actually free of cost.
+Nothing will "cost them more in transaction fees". A miner can create
+thousands of transactions paying to himself, and not broadcast them to
+the network, but hold them and include them in the blocks he mines. The
+fees are collected by him because transactions are included in a block
+that he mined and the left amount is in another wallet of the same
+person. Repeat this continuously to fill blocks.
+
+
+> Blocks would get too big -=20
+> Eventually, blocks would get too big, but only if bandwidth stopped
+> increasing and the cost of disk space stopped decreasing. Otherwise, th=
+e
+> incremental adjustments made by Block75 (especially in combination with=
+
+> SegWit) wouldn't break anyone's connection or result in significantly
+> more orphaned blocks.
+>=20
+
+Topology and bandwidth speed / hash rate of the network cannot be
+controlled - if we make assumptions about these it might have terrible
+consequences.
+
+Even if we take in consideration that bandwidth will only grow and disk
+space will only cost less (which is not something we can safely assume,
+by the way) the hard limit max. block size cannot grow to unlimited
+value (even if the growth happens over time). There is also a validation
+cost in time for each block, for the health of the network any node
+should be able to download _and_ validate a block, before next block
+gets mined.
+
+You said in another post that a permanent solution is preferred, rather
+than kicking the can down the road. I fully agree, as well as many
+others reading this list, but the permanent solution doesn't necessarily
+have to be increasing the max block size dynamically.
+
+If you think about it the other way around, dynamically growing the max
+block size is also kicking the can down the road ... just without having
+to touch it and get dust on the boot ;)
+
+
+--fT9s2cAmDuw6tH44n1A79Tbh86PgECAGJ--
+
+--ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7
+Content-Type: application/pgp-signature; name="signature.asc"
+Content-Description: OpenPGP digital signature
+Content-Disposition: attachment; filename="signature.asc"
+
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2.0.22 (MingW32)
+
+iQEcBAEBCAAGBQJYTYi7AAoJEIN/pSyBJlsRgd8H/jSULp50dLHHXxUJ0TAp9Gvw
+HXzuz40cvf8bvP0/slKdQwNCqMmsUHOWHLB8EIvBVtKlCXUXytvC8uQ1ge97ASeU
+PJTim2KUOnfh1YWe6ADtdLE4h1coyaPXBey06IrfHQBwKMjUWQn3NUPpAKgUR2ft
+/Kw33q/7kZuA6Tno0W4DGhm8j5oBA1LHM5VbA2lOGK7IKSPs7be3dZKaJjnOS0LB
+XUXBG5oRTrigWrdlJp/GkwC4PyyBRqzCdtflshZHQLXvG4lin/ZIQ9Xxdlyt2/Fu
+dtOqZTafVvOSnQzhcGyR5gh2oybl9ekzp1bM+DltYoj8czFf+DD2jaPlUjg82HA=
+=l4f1
+-----END PGP SIGNATURE-----
+
+--ov6uSsME7bK2q9w5Wv6lEcX2hhT3sg0c7--
+