From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E9B8812CF for ; Wed, 7 Mar 2018 08:20:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yb0-f195.google.com (mail-yb0-f195.google.com [209.85.213.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD9A05C2 for ; Wed, 7 Mar 2018 08:20:18 +0000 (UTC) Received: by mail-yb0-f195.google.com with SMTP id i13-v6so460789ybl.9 for ; Wed, 07 Mar 2018 00:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8Jc5wPda+X0+OPCkqRn8PFGCPoYKP1uYmMJ6PVmf3L0=; b=DW0y1a4Az3rTWanOL+Xj68deIuuOdQUj5t8tRPLayKQVoluk4lZIv1JD/qfQt5TIiL 7ZIVv2Y11SZ3oW3kYeBWceTYWojSn2LN4vEnOtxSb+IAznAXlxZg4EZ3RKLknPMJvSGn 07PYE89vge/+X0lerXzTAXl/hACrWw+zu0YsJLGaBh79iAeX2ETLkxcSKu2UJw3tr+ds buCria2JBsWv43OwYBBjQZZY9o2bfSDjCB0ZdfrZl35CQir/2cd2o4afRMCcpXEU/PYU lctI6spRieCt94z/xSoiSTVNle7XKQexD0nbsfCMjHQgDBeIxo8IS9neoM2A9kzOKz6g w4zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8Jc5wPda+X0+OPCkqRn8PFGCPoYKP1uYmMJ6PVmf3L0=; b=mVDUOK9tV4MsLQOkuI9ql7iinX6kd7mcWgv+qTY3aUPojnICNupW6FJqM+wb7/8jKT 7SpNXbsLzihFT2z48iuKhCQ4yCSYnRyi5pxGew1/wKj56xqrjpnqXMnom7eFXrfpXKq/ /hyaLdAPzfgfu0dAweC74mXiJu5WW9AaMcEcuUlX1wRm12VOMaGYeukB/PT/95Ovaspx mpLoT29Y/oqfJW3RigZYcSC5k2+fVoZLfXPjQEqCYKPTBiZkLtXgPUAgUTfpCvcM/v1V 3SKCkiB19dC3RGsTq/nfscWmN/NUVQWb213VaOhA7+5hhAnQT/G7OphyCo0cixsxpvM/ MWvQ== X-Gm-Message-State: AElRT7EJ2DbXaYpEJuVX0o+k2Agf5pqWicM1RMEYvAKpxVm5bhA33Z1e rLeL72yxrXpTeeZJmlCRdKQfVYNNS2qyMXwnhm0T9BWspgQ= X-Google-Smtp-Source: AG47ELvr53kBXLW3Bn+8UI/13TnB/aJdsGVS+4C2gkC/9dK43MEy72531HfW4xMSIGjIgM7MEodgxhbt4yV/OSbb4Ag= X-Received: by 2002:a25:c8c6:: with SMTP id y189-v6mr2769679ybf.377.1520410817541; Wed, 07 Mar 2018 00:20:17 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:ab0f:0:0:0:0:0 with HTTP; Wed, 7 Mar 2018 00:19:57 -0800 (PST) From: Btc Drak Date: Wed, 7 Mar 2018 08:19:57 +0000 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary="000000000000b13a6c0566ce3aed" X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, URIBL_DBL_SPAM, URIBL_RHS_DOB autolearn=no version=3.3.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 07 Mar 2018 13:03:17 +0000 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 08:20:20 -0000 --000000000000b13a6c0566ce3aed Content-Type: text/plain; charset="UTF-8" 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-defensive-use/ [4] https://blockchaindpl.org/ [5] https://github.com/BlockheaderNonce2/bitcoin/wiki [6] http://stratumprotocol.org/stratum-extensions 
  BIP: ?
  Title: Reserved nversion bits in blockheader
  Author: BtcDrak 
  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
==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. --000000000000b13a6c0566ce3aed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The following proposal reduces the number of ve= rsion-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-f= ork activations using versionbits to from 29 to 13 and prevent node softwar= e from emitting false warnings about unknown signalling bits under the vers= ionbits signalling system (BIP8/9). I chose the upper bits of the nVersion,= because looking at the versionbits implementation in the most widely deplo= yed 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 bi= t, although there have previously been various discussions of some use-case= s of nVersion bits including version-rolling AsicBoost[1], and nonce rollin= g to reduce CPU load on mining controllers because ntime-rolling can only b= e done for short periods otherwise it could have negative side effects dist= orting 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 im= portant to bring up so node software can adapt the versionbits warning syst= em 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 r= esult of restraints while negotiating to get the patent opened[3] and licen= sed 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 version= bits soft-fork activation system and earmark 16 bits for general use withou= t allocating fixed uses for each bit. The BIP cites a couple of usecases fo= r good measure, but they are just informational examples, not part of a spe= cification laid down. For this reason, there no is mention of the version-r= olling Stratum extension[6] specifics within the BIP text other than a refe= rence 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-as= icboost-for-defensive-use/
[4] https://blockchaindpl.org/
[5] https://github.com/BlockheaderNonce2/bitcoin/wik= i
[6] http= ://stratumprotocol.org/stratum-extensions

<pre>
  BIP: ?
  Title: Reserved nversion bits in blockheader
  Author: BtcDrak <btcdrak@gmail.co=
m>
  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>

=3D=3DAbstract=3D=3D

This BIP reserves 16 bits of the block header nVersion field for general pu=
rpose use and removes their meaning for the purpose of version bits soft-fo=
rk signalling.

=3D=3DMotivation=3D=3D

There are a variety of things that miners may desire to use some of the nVe=
rsion field bits for. However, due to their use to coordinate miner activat=
ed soft-forks, full node software will generate false warnings about unknow=
n 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 ca=
n be updated to ignore those bits and therefore will not emit false warning=
s. Reserving 16 bits for general use leaves enough for 13 parallel soft-for=
ks using version bits.

=3D=3DExample Uses=3D=3D

The following are example cases that would benefit from using some of the b=
its from the nVersion field. This list is not exhaustive.

Bitcoin mining hardware currently can exhaust the 32 bit nonce field in les=
s than 200ms requiring the controller to distribute new jobs very frequentl=
y to each mining chip consuming a lot of bandwidth and CPU time. This can b=
e 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 calc=
ulate 4-way collisions. Any two bits can be used and mining equipment can n=
egotiate which bits are to be used with mining pools via the Stratum "=
version-rolling" extension.

=3D=3DSpecification=3D=3D

Sixteen bits from the block header nVersion field, starting from 13 and end=
ing at 28 inclusive (0x1fffe000), are reserved for general use and removed =
from BIP8 and BIP9 specifications. A mask of 0xe0001fff should be applied t=
o nVersion bits so bits 13-28 inclusive will be ignored for soft-fork signa=
lling and unknown soft-fork warnings.

This specification does not reserve specific bits for specific purposes.

=3D=3DBackwards Compatibility=3D=3D

This proposal is backwards compatible, and does not require a soft fork to =
implement.

=3D=3DReferences=3D=3D

[[bip-0008.mediawiki|BIP8]]
[[bip-0009.mediawiki|BIP9]]
[https://arxiv.org/pdf/160=
4.00575.pdf AsicBoost white paper]
[https://gith=
ub.com/BlockheaderNonce2/bitcoin/wiki nNonce2 proposal]
[http://stratumprotocol.org/ St=
ratum protocol extension for version-rolling]

=3D=3DCopyright=3D=3D

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.=
0 Universal.


--000000000000b13a6c0566ce3aed--