summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Dashjr <luke@dashjr.org>2018-03-07 14:43:11 +0000
committerbitcoindev <bitcoindev@gnusha.org>2018-03-07 14:43:18 +0000
commitc3329e6ce75eefd273169a2862393cbad7862a48 (patch)
treedb10c042ac6a4f2a4c4678b4d649895e9f5acc2c
parent05845186f2831ab529cec2600381e060b7e237ee (diff)
downloadpi-bitcoindev-c3329e6ce75eefd273169a2862393cbad7862a48.tar.gz
pi-bitcoindev-c3329e6ce75eefd273169a2862393cbad7862a48.zip
Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader
-rw-r--r--25/0551fe115c8e9fbcddb308dc25851c059fd427203
1 files changed, 203 insertions, 0 deletions
diff --git a/25/0551fe115c8e9fbcddb308dc25851c059fd427 b/25/0551fe115c8e9fbcddb308dc25851c059fd427
new file mode 100644
index 000000000..a1601ed8c
--- /dev/null
+++ b/25/0551fe115c8e9fbcddb308dc25851c059fd427
@@ -0,0 +1,203 @@
+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 685E110A6
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 7 Mar 2018 14:43:18 +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 315275F3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 7 Mar 2018 14:43:17 +0000 (UTC)
+Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265::71])
+ (Authenticated sender: luke-jr)
+ by zinan.dashjr.org (Postfix) with ESMTPSA id C47A038A0C5C;
+ Wed, 7 Mar 2018 14:43:14 +0000 (UTC)
+X-Hashcash: 1:25:180307:btcdrak@gmail.com::Eu76AhF0k1Em=9+m:dhRD
+X-Hashcash: 1:25:180307:bitcoin-dev@lists.linuxfoundation.org::LF9EqQZt9Uw6TE2b:gfiP
+From: Luke Dashjr <luke@dashjr.org>
+To: Btc Drak <btcdrak@gmail.com>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Date: Wed, 7 Mar 2018 14:43:11 +0000
+User-Agent: KMail/1.13.7 (Linux/4.15.1-gentoo; KDE/4.14.37; x86_64; ; )
+References: <CADJgMzv85-So7F1+nyDP_xA2GH5erodA21PM-uAJw8P6_ix6hA@mail.gmail.com>
+In-Reply-To: <CADJgMzv85-So7F1+nyDP_xA2GH5erodA21PM-uAJw8P6_ix6hA@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: 7bit
+Message-Id: <201803071443.13417.luke@dashjr.org>
+X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
+ T_RP_MATCHES_RCVD, URIBL_DBL_SPAM,
+ URIBL_RHS_DOB 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] BIP proposal: Reserved nversion bits in
+ blockheader
+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: Wed, 07 Mar 2018 14:43:18 -0000
+
+Why are you posting this obsolete draft? You've already received review in
+private, and been given useful suggestions. There's even a shared Google Doc
+with the current draft:
+
+ https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9TV9LRqvStak/edit?usp=sharing
+
+Again:
+
+* This is no different from what Timo and Sergio proposed years ago, and as
+such should be based on their work instead of outright not-invented-here
+respecification. The current draft integrates their work while not trying to
+steal credit for it (they are included as primary authors).
+
+* The specification should be complete, including updates for GBT and the
+Stratum mining protocol. These are included in the current draft.
+
+Additionally, it is not appropriate to begin using a draft BIP on mainnet
+before any discussion or consensus has been reached. Doing so seems quite
+malicious, in fact. I hope DragonMint miners can still operate using the
+*current* Bitcoin protocol.
+
+Luke
+
+
+On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote:
+> Hi,
+>
+> The following proposal reduces the number of version-bits that can be used
+> for parallel soft-fork signalling, reserving 16 bits for non-specific use.
+> This would reduce the number of parallel soft-fork activations using
+> versionbits to from 29 to 13 and prevent node software from emitting false
+> warnings about unknown signalling bits under the versionbits signalling
+> system (BIP8/9). I chose the upper bits of the nVersion, because looking at
+> the versionbits implementation in the most widely deployed node software,
+> it is easier to implement than say annexing the lower 2 bytes of the field.
+>
+> The scope of the BIP is deliberately limited to reserving bits for general
+> use without specifying specific uses for each bit, although there have
+> previously been various discussions of some use-cases of nVersion bits
+> including version-rolling AsicBoost[1], and nonce rolling to reduce CPU
+> load on mining controllers because ntime-rolling can only be done for short
+> periods otherwise it could have negative side effects distorting time.
+> However, specific use cases are not important for this BIP.
+>
+> I am reviving discussion on this topic now, specifically, because the new
+> DragonMint miner uses version-rolling AsicBoost on mainnet[2]. It is
+> important to bring up so node software can adapt the versionbits warning
+> system to prevent false positives. This BIP has the added advantage that
+> when a new use for bits is found, mining manufacturers can play in the
+> designated area without causing disruption or inconvenience (as
+> unfortuntely, the use of version-rolling will cause until BIP8/9 warning
+> systems are adapted). I appologise for the inconvenience in advance, but
+> this is the unfortunate result of restraints while negotiating to get the
+> patent opened[3] and licensed defensively[4] in the first place.
+>
+> I believe there was a similar proposal[5] made some years ago, before the
+> advent of BIP9. This proposal differs in that it's primary purpose is to
+> remove bits from the versionbits soft-fork activation system and earmark 16
+> bits for general use without allocating fixed uses for each bit. The BIP
+> cites a couple of usecases for good measure, but they are just
+> informational examples, not part of a specification laid down. For this
+> reason, there no is mention of the version-rolling Stratum extension[6]
+> specifics within the BIP text other than a reference to the specification
+> itself.
+>
+> Refs:
+>
+> [1] https://arxiv.org/pdf/1604.00575.pdf
+> [2]
+> https://halongmining.com/blog/2018/03/07/dragonmint-btc-miner-uses-version-> rolling-asicboost/ [3]
+> https://www.asicboost.com/single-post/2018/03/01/opening-asicboost-for-defe
+> nsive-use/ [4] https://blockchaindpl.org/
+> [5] https://github.com/BlockheaderNonce2/bitcoin/wiki
+> [6] http://stratumprotocol.org/stratum-extensions
+>
+> <pre>
+> BIP: ?
+> Title: Reserved nversion bits in blockheader
+> Author: BtcDrak <btcdrak@gmail.com>
+> Comments-Summary: No comments yet.
+> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
+> Status: Draft
+> Type: Informational
+> Created: 2018-03-01
+> License: BSD-3-Clause
+> CC0-1.0
+> </pre>
+>
+> ==Abstract==
+>
+> This BIP reserves 16 bits of the block header nVersion field for
+> general purpose use and removes their meaning for the purpose of
+> version bits soft-fork signalling.
+>
+> ==Motivation==
+>
+> There are a variety of things that miners may desire to use some of
+> the nVersion field bits for. However, due to their use to coordinate
+> miner activated soft-forks, full node software will generate false
+> warnings about unknown soft forks if those bits are used for non soft
+> fork signalling purposes. By reserving bits from the nVersion field
+> for general use, node software can be updated to ignore those bits and
+> therefore will not emit false warnings. Reserving 16 bits for general
+> use leaves enough for 13 parallel soft-forks using version bits.
+>
+> ==Example Uses==
+>
+> The following are example cases that would benefit from using some of
+> the bits from the nVersion field. This list is not exhaustive.
+>
+> Bitcoin mining hardware currently can exhaust the 32 bit nonce field
+> in less than 200ms requiring the controller to distribute new jobs
+> very frequently to each mining chip consuming a lot of bandwidth and
+> CPU time. This can be greatly reduced by rolling more bits. Rolling
+> too many bits from nTime is not ideal because it may distort the
+> timestamps over a longer period.
+>
+> Version-rolling AsicBoost requires two bits from the nVersion field to
+> calculate 4-way collisions. Any two bits can be used and mining
+> equipment can negotiate which bits are to be used with mining pools
+> via the Stratum "version-rolling" extension.
+>
+> ==Specification==
+>
+> Sixteen bits from the block header nVersion field, starting from 13
+> and ending at 28 inclusive (0x1fffe000), are reserved for general use
+> and removed from BIP8 and BIP9 specifications. A mask of 0xe0001fff
+> should be applied to nVersion bits so bits 13-28 inclusive will be
+> ignored for soft-fork signalling and unknown soft-fork warnings.
+>
+> This specification does not reserve specific bits for specific purposes.
+>
+> ==Backwards Compatibility==
+>
+> This proposal is backwards compatible, and does not require a soft
+> fork to implement.
+>
+> ==References==
+>
+> [[bip-0008.mediawiki|BIP8]]
+> [[bip-0009.mediawiki|BIP9]]
+> [https://arxiv.org/pdf/1604.00575.pdf AsicBoost white paper]
+> [https://github.com/BlockheaderNonce2/bitcoin/wiki nNonce2 proposal]
+> [http://stratumprotocol.org/ Stratum protocol extension for
+> version-rolling]
+>
+> ==Copyright==
+>
+> This document is dual licensed as BSD 3-clause, and Creative Commons
+> CC0 1.0 Universal.
+