diff options
author | Luke Dashjr <luke@dashjr.org> | 2015-11-14 21:11:22 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-11-14 21:11:36 +0000 |
commit | 2a1dfe0fbc09051f49aa215acdfd4444c6246cb8 (patch) | |
tree | e53dfb1d0191e2ec45dabf6cfff0eae6c7004c59 | |
parent | 47995a0746d5fa23cb8ebc644a6334ef156176b4 (diff) | |
download | pi-bitcoindev-2a1dfe0fbc09051f49aa215acdfd4444c6246cb8.tar.gz pi-bitcoindev-2a1dfe0fbc09051f49aa215acdfd4444c6246cb8.zip |
Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M
-rw-r--r-- | d8/7f5d58a57a5263622d4484fbd14f921fbb7074 | 83 |
1 files changed, 83 insertions, 0 deletions
diff --git a/d8/7f5d58a57a5263622d4484fbd14f921fbb7074 b/d8/7f5d58a57a5263622d4484fbd14f921fbb7074 new file mode 100644 index 000000000..3e6b85210 --- /dev/null +++ b/d8/7f5d58a57a5263622d4484fbd14f921fbb7074 @@ -0,0 +1,83 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 242D889E + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 14 Nov 2015 21:11:36 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id BDE6A134 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 14 Nov 2015 21:11:35 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id 5594C38A6FC2; + Sat, 14 Nov 2015 21:11:25 +0000 (UTC) +X-Hashcash: 1:25:151114:bitcoin-dev@lists.linuxfoundation.org::lSmbjWilGzP9SG=3:cHcm +X-Hashcash: 1:25:151114:jtimon@jtimon.cc::dVrH9F7CZpbuMbPv:vzKX +X-Hashcash: 1:25:151114:adam@cypherspace.org::qj0z6nOmuFAsvMZN:Cur7 +X-Hashcash: 1:25:151114:johnsock@gmail.com::4bKd1vzoT3aR46+1:QOTd +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, + Jorge =?iso-8859-15?q?Tim=F3n?= <jtimon@jtimon.cc> +Date: Sat, 14 Nov 2015 21:11:22 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) +References: <201511132228.47815.luke@dashjr.org> + <CALqxMTFE9W0nxGHvcJN_Wz88b00o-K29GRTbHJv+VSpYAJKUNQ@mail.gmail.com> + <CABm2gDo7D1rrsjRef173HVkwBrDQ0uJAhtWKk0SmRFaqzX5VTw@mail.gmail.com> +In-Reply-To: <CABm2gDo7D1rrsjRef173HVkwBrDQ0uJAhtWKk0SmRFaqzX5VTw@mail.gmail.com> +X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F +X-PGP-Key-ID: BD02942421F4889F +X-PGP-Keyserver: hkp://pgp.mit.edu +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-15" +Content-Transfer-Encoding: quoted-printable +Message-Id: <201511142111.24046.luke@dashjr.org> +X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: John Sacco <johnsock@gmail.com> +Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving + with max block size of 32M +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: Sat, 14 Nov 2015 21:11:36 -0000 + +On Saturday, November 14, 2015 10:52:12 AM Jorge Tim=F3n via bitcoin-dev wr= +ote: +> Currently bip99 recommends 95% miner upgrade confirmation with version bi= +ts +> (bip9) for uncontroversial hardforks just like it does for uncontroversial +> softforks. It is true that in the case of hardforks miners don't decide a= +nd +> it's the whole economy who has to upgrade before activation, but "the who= +le +> economy" and "all users" includes miners, so why not use the only upgrade +> confirmation mechanism that we have available? + +Actually, the economy does not necessarily include miners, and in fact the= +=20 +present miner community for the most part does not overlap significantly wi= +th=20 +economic activity. And at the same time, miners also have a tendency to=20 +upgrade at a different rate than the economy. It might make sense to=20 +incorporate a miner-trigger, but *only if* the flag is enabled in nodes by = +an=20 +option disabled by default, and the BIP clearly specifies that miners must = +not=20 +enable it until they perceive complete economic adoption of the change. + +Luke + |