diff options
author | s7r <s7r@sky-ip.org> | 2016-12-11 19:11:10 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-12-11 17:11:52 +0000 |
commit | be9547108c1cb241b3ab87f47a0a8ad79e3890c7 (patch) | |
tree | 66dca0888483bc7793a73038e3684d8d9c0c8f40 | |
parent | 53f91e6f7dde85d633a74f23dd37f4ce49a4640c (diff) | |
download | pi-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/9a618685d101118e2ad61377edc0b1eb08e729 | 164 |
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-- + |