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 77B671080 for ; Wed, 7 Mar 2018 15:43:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69D795FD for ; Wed, 7 Mar 2018 15:43:56 +0000 (UTC) Received: by mail-wr0-f194.google.com with SMTP id p104so2615430wrc.12 for ; Wed, 07 Mar 2018 07:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=braiins-cz.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version; bh=FMjcZVwZuXMQc/tKga+a2kg9jDzumOUXn6XDHDDLeOw=; b=qsCiFVbOBz56PAVPQJLak3q3osZH7eBMHp+OxnrNbQr1mrELtSphVZ/PivHXMjwCOr lws5hXkaX9G4bv8QjQ3R9GMMsjk3JfUw9iZCM6u7t+WmzYJnPDWo2z6kk1vtqWQNWz/e FfOHlvRzHCclWc2Bwy2pP3Ay/an+JZEYyY/h7fTTVipYfRMY+fOEWjALeUpOLw3fWdhQ H54FG6P9HSAbwYMi5DjFDZv2utA9/8OeSAUqgODTh64y4j8DuhHo1U18YWyoDINgKqpJ tayBrCCKifrGXU1epu0L5y7OCtH7BeMAMdNO7vTK2JDCUJEwbUv6gT1FO9qNSGLsf3vC 1Swg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version; bh=FMjcZVwZuXMQc/tKga+a2kg9jDzumOUXn6XDHDDLeOw=; b=grW3iKl5dZjsy3npImO199rA5+4Dv59BgJNFQN40cijYCHEADwgQoX9uxDaQYMRcva QYvuJb194PY/yC2sJMBgltAmf+2PyGUMF4N60ubi0DaUvz6u2z3rlyStMyFlN/Z+pDqW BINWrvv824FnYu4/BfozynaLvMcXa6Q2PbkMrGV6+KT8qQhtPsIBVgo6y3oKZGuXYluq ezGAeDOhCvCRlnIDKJMpXh40rJYml1AI5rP8+nqQQ5o/2TatXgUbzdEN781Ju8fbGWPO CGN2XBLjzNUGMqYY5j7VbiIRP9Vjk0Jap+GUGCTinJ911RCTYUXW/e/AIb4I9r3yQrb3 T1CQ== X-Gm-Message-State: APf1xPAn+ppQMdsNIcAG1xnqli5KlPeUddRHRAsG9YzY4D8aPABsfWdn bwdJaRAJOx51UCh6HeH9Kg/p/7VY X-Google-Smtp-Source: AG47ELtAGO1T6o1lCexXnsxtZw6MCxPkUolOv6gW2r1gYdcvcVfOzOsGQslbfbLvdByk/IHnQLmPOA== X-Received: by 10.223.175.44 with SMTP id z41mr18541288wrc.129.1520437434415; Wed, 07 Mar 2018 07:43:54 -0800 (PST) Received: from glum ([88.208.115.67]) by smtp.gmail.com with ESMTPSA id r1sm13223726wmg.22.2018.03.07.07.43.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 07:43:54 -0800 (PST) Date: Wed, 7 Mar 2018 16:43:49 +0100 From: Jan =?UTF-8?B?xIxhcGVr?= To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20180307164349.1cfa51b3@glum> In-Reply-To: <201803071443.13417.luke@dashjr.org> References: <201803071443.13417.luke@dashjr.org> Organization: braiins X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/cnXmGn.oI5iqL.vztaVri8b"; protocol="application/pgp-signature" X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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: Thu, 08 Mar 2018 14:53:06 +0000 Subject: Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure 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 15:43:57 -0000 --Sig_/cnXmGn.oI5iqL.vztaVri8b Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, Our reasoning for coming up with a new method for miner configuration was stated here: https://github.com/slushpool/stratumprotocol/issues/1 It is primarily the determinism of expecting the response. That is the reason why we chose a new method mining.configure instead of an existing mining.capabilities that was not being very well documented or used. On Wed, 7 Mar 2018 14:43:11 +0000 Luke Dashjr via bitcoin-dev wrote: > 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: >=20 > https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9T= V9LRqvStak/edit?usp=3Dsharing >=20 > Again: >=20 > * 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). >=20 > * The specification should be complete, including updates for GBT and > the Stratum mining protocol. These are included in the current draft. >=20 > 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. >=20 > Luke >=20 >=20 > On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote: > > Hi, > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > Refs: > >=20 > > [1] https://arxiv.org/pdf/1604.00575.pdf > > [2] > > https://halongmining.com/blog/2018/03/07/dragonmint-btc-miner-uses-vers= ion-> > > 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 > >=20 > > 
> >   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
> >
> >=20 > > =3D=3DAbstract=3D=3D > >=20 > > 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. > >=20 > > =3D=3DMotivation=3D=3D > >=20 > > 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. > >=20 > > =3D=3DExample Uses=3D=3D > >=20 > > The following are example cases that would benefit from using some > > of the bits from the nVersion field. This list is not exhaustive. > >=20 > > 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. > >=20 > > 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. > >=20 > > =3D=3DSpecification=3D=3D > >=20 > > 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. > >=20 > > This specification does not reserve specific bits for specific > > purposes. > >=20 > > =3D=3DBackwards Compatibility=3D=3D > >=20 > > This proposal is backwards compatible, and does not require a soft > > fork to implement. > >=20 > > =3D=3DReferences=3D=3D > >=20 > > [[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] > >=20 > > =3D=3DCopyright=3D=3D > >=20 > > This document is dual licensed as BSD 3-clause, and Creative Commons > > CC0 1.0 Universal. =20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=20 CEO Braiins Systems | Slushpool.com tel: +420 604 566 382 email: jan.capek@braiins.cz http://braiins.cz http://slushpool.com --Sig_/cnXmGn.oI5iqL.vztaVri8b Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJaoAi1AAoJEHsopSWtdWV87TcP/A7OJ3IBa/pYwunzacKMyy7C YltyNZ3+Z//mjPjAybxLvpMqbtLZRdH43T1FLPoskTrykuXtKF7oTF5xxwvD1N9j a7FUlRhUSNN1f/rv7cChnHpNKhNmRQPzajjKNeOiSVHHNgwo16wiYzUmqi84B+Yr MnLFwve3jMjgeUwoslaN7DPrkTXuVr0DEp+HIG/519hkyCQuANJ/2ksivInnH+pr q4psVMvaOyNm801lb7QoPGX3k9BLqjIQ4XLxR0p4tG2qyGYlLmaUsHtGTVBXZkT3 t9N7uMEIpQw7TkJ8ZUsfuX68fV9HXOZ8eTQZHLQ+RbkieNESy/AUAYNw6YV304py 5rRYIiKf0TXHi5JuukWg1U51QJzpF/z+7HBZdls/4ICRgEqI3aIpNalcNXF9jszf ipRXdKZMXfeCUZaCMYICHOiyz0dF0JvPzp3LluNOV1XelLRo9mkC3VYGh3hKRmOe o1pMGRWKeNIjTVbyxO3GJ5mbe5kplLnsp1F7bRCrqIdM5Ewcue+uUthFaruM/eM3 n+3sR50cJwdKTMXjk89fcCDA7oSQhVmq1D1s3dAhWPZHl1zjJP+gkuBb82Jm4KSJ S/Slp3MucC4wdQtBe73yloUY03AOdBsxK2GK/1ss8QubI0B4MyGM4tDgc/LGpzdH 9FDNpNqc2w2lrVLaeASm =RB5D -----END PGP SIGNATURE----- --Sig_/cnXmGn.oI5iqL.vztaVri8b--