Jan Čapek [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-04-07 to 2018-05-17
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:12:21

- reply

📅 Original date posted:2018-05-17
📝 Original message:Hello,
we (at braiins systems/slushpool) would like to kindly re-open the
topic of stratum protocol extension that has been in fact implemented by
quite a few pools already (including us). This extension
currently allows configuring the stratum session for version rolling
and enables a generic mechanism for requesting protocol
extensions from the miners. More details are in the specification
below.
I am aware of LukeJr's comments on why we haven't used
https://en.bitcoin.it/wiki/Stratum_mining_protocol#mining.capabilities_.28DRAFT.29
We are aware that there has been some academic work done on
concentrating full stratum protocol specs in one BIP as referred here
e.g.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015728.html
Below is a copy of a full extension draft that has been published at
this URL:
https://github.com/slushpool/stratumprotocol/blob/master/stratum-extensions.mediawiki
We should probably join the effort and unify all the documents in one
single BIP if that would be seen as the most efficient way of having
the specs.
Kind regards,
Jan
<pre>
BIP: ????
Layer: Applications
Title: Stratum protocol extensions
Author: Pavel Moravec <pavel.moravec at braiins.cz>
Jan Capek <jan.capek at braiins.cz>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Informational
Created: 2018-03-10
License: BSD-3-Clause
CC0-1.0
</pre>
==Abstract==
This BIP provides a generic mechanism for specifying stratum protocol
extensions. At the same time, one of the important extensions that is
specified by this BIP is configuration of bits for "version rolling"
in nVersion field of bitcoin block header.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
==Motivation==
The initial motivation for specifying some general support for stratum
protocol extensions was a need to allow miners to do so called
"version rolling", changing value in the first field of the Bitcoin
block header.
Version rolling is backwards incompatible change to the stratum protocol
because the miner couldn't communicate different block version value to
the server in the original version of the stratum protocol. Similarly,
a server couldn't communicate safe bits for rolling to a miner. So
both miners and pools need to implement some protocol extension to
support version rolling.
Typically, if a miner sends an unknown message to a server, the server
closes the connection (not all implementations do that but some
do). So it is not very safe to try to send unknown messages to
servers.
We can use this opportunity to make one backwards incompatible
change to the protocol to support multiple extensions in the
future. In a way that a miner can advertise its capabilities and at
the same time it can request some needed features from the server.
It is preferable that the same mechanism for feature negotiation can
be used for not yet known features. It SHOULD be easy to implement in
the mining software too.
We introduce one new message to the stratum protocol
('''"mining.configure"''') which handles the initial
configuration/negotiation of features in a generic way. So that adding
features in the future can be done without a necessity to add new
messages to stratum protocol.
Each extension has its unique string name, so called '''extension
code'''.
==Specification==
Currently, the following extensions are defined:
* '''"version-rolling"'''
* '''"minimum-difficulty"'''
* '''"subscribe-extranonce"'''
===Additional data types===
The following names are used as type aliases, making the message
description easier.
* '''TMask''' - case independent hexadecimal string of length 8,
encoding an unsigned 32-bit integer (~<code>[0-9a-fA-F]{8}</code>)
* '''TExtensionCode''' - non-empty string with a value equal to the
name of some protocol extension.
* '''TExtensionResult''' - <code>true</code> / <code>false</code> /
''String''. ** <code>true</code> = The requested feature is supported
and its configuration understood and applied. ** <code>false</code> =
The feature is not supported or unknown. ** ''String'' = Error
message containing information about what went wrong.
===Request "mining.configure"===
This message (JSON RPC Request) SHOULD be the '''first message''' sent
by the miner after the connection with the server is established. The
client uses the message to advertise its features and to request/allow
some protocol extensions.
The reason for it being the first is that we want the implementation and
possible interactions to be as easy and simple as possible. An extension
can define explicitly what does a repeated configuration of that
extension mean.
Each extension code provides a namespace for its extension parameters
and extension return values. By convention, the names are formed from
extension codes by adding "." and a parameter name. The same applies
for the return values, which are transferred in a result map
too. E.g. "version-rolling.mask" is the name of the parameter "mask" of
extension "version-rolling".
'''Parameters''':
* '''extensions''' (REQUIRED, List of ''TExtensionCode'')
::- Each string in the list MUST be a valid extension code. The meaning
of each code is described independently as part of the extension
definition. A miner SHOULD advertise all its available features.
* '''extension-parameters''' (REQUIRED, ''Map of (String -> Any)'')
::- Parameters of the requested/allowed extensions from the first
parameter.
'''Return value''':
* ''Map of (String -> Any)''
::- Each code from the '''extensions''' list MUST have a defined return
value (''TExtensionCode'' -> ''TExtensionResult''). This way the
miner knows if the extension is activated or not. E.g.
<code>{"version-rolling":false}</code> for unsupported version
rolling. ::- Some extensions need additional information to be
delivered to the miner. The return value map is used for this purpose.
Example request (new-lines added):
<pre>
{"method": "mining.configure",
"id": 1,
"params": [["minimum-difficulty", "version-rolling"],
{"minimum-difficulty.value": 2048,
"version-rolling.mask": "1fffe000",
"version-rolling.min-bit-count": 2}]} </pre>
(The miner requests extensions <code>"version-rolling"</code> and
<code>"minimum-difficulty"</code>. It sets the parameters according to
the extensions' definitions.)
Example result (new-lines added):
<pre>
{"error": null,
"id": 1,
"result": {"version-rolling": true,
"version-rolling.mask": "18000000",
"minimum-difficulty": true}}
</pre>
=Defined extensions=
==Extension "version-rolling"==
This extension allows the miner to change the value of some bits in the
version field in the block header. Currently there are no standard bits
used for version rolling so they need to be negotiated between a
miner and a server.
A miner sends the server a mask describing bits which the miner is
capable of changing. 1 = changeable bit, 0 = not changeable
(<code>miner_mask</code>) and a minimum number of bits that it needs
for efficient version rolling.
A server typically allows you to change only some of the version bits
(<code>server_mask</code>) and the rest of the version bits are
fixed. E.g. because the block needs to be valid or some signaling is
in place.
The server responds to the configuration message by sending a mask
with common bits intersection of the miner's mask and its a mask
(<code>response = server_mask & miner_mask</code>)
Example request (a miner capable of changing any 2 bits from a 16-bit
mask):
{"method": "mining.configure", "id": 1, "params":
[["version-rolling"], {"version-rolling.mask": "1fffe000",
"version-rolling.min-bit-count": 2}]}
Example result (success):
{"error": null, "id": 1, "result": {"version-rolling": true,
"version-rolling.mask": "18000000"}}
Example result (unknown extension):
{"error": null, "id": 1, "result": {"version-rolling": false}}
'''Extension parameters''':
* '''"version-rolling.mask"''' (OPTIONAL, ''TMask'', default value
<code>"ffffffff"</code>) ::- Bits set to 1 can be changed by the
miner. This value is expected to be stable for the whole mining
session. A miner doesn't have to send the mask, in this case a
default full mask is used.
'''Extension return values''':
* '''"version-rolling"''' (REQUIRED, ''TExtensionResult'')
::- When responded with <code>true</code>, the server will accept new
parameter of '''"mining.submit"''', see later.
* '''"version-rolling.mask"''' (REQUIRED, ''TMask'')
::- Bits set to 1 are allowed to be changed by the miner. If a miner
changes bits with mask value 0, the server will reject the
submit. ::- The server SHOULD return the largest mask possible (as
many bits set to 1 as possible). This can be useful in a mining proxy
setup when a proxy needs to negotiate the best mask for its future
clients. There is a [Draft
BIP](https://github.com/bitcoin/bips/pull/661/files) describing
available nVersion bits. The server SHOULD pick a mask that
preferably covers all bits specified in the BIP.
* '''"version-rolling.min-bit-count"''' (REQUIRED, ''TMask'')
::- The miner also provides a minimum number of bits that it needs for
efficient version rolling in hardware. Note that this parameter
provides important diagnostic information to the pool server. If the
requested bit count exceeds the limit of the pool server, the miner
always has the chance to operate in a degraded mode without using
full hashing power. The pool server SHOULD NOT terminate miner
connection if this rare mismatch case occurs.
===Notification '''"mining.set_version_mask"'''===
Server notifies the miner about a new mask valid for the
connection. This message can be sent at any time after the successful
setup of the version rolling extension by the "mining.configure"
message. The new mask is valid '''immediately''', so that the server
doesn't wait for the next job.
'''Parameters''':
* ''mask'' (REQUIRED, ''TMask''): The meaning is the same as the
'''"version-rolling.mask"''' return parameter.
Example:
{"params":["00003000"], "id":null, "method": "mining.set_version_mask"}
===Changes in request '''"mining.submit"'''===
Immediately after successful activation of the version-rolling extension
(result to '''"mining.configure"''' sent by server), the server MUST
accept an additional parameter of the message '''"mining.submit"'''.
The client MUST send one additional parameter, '''version_bits''' (6th
parameter, after ''worker_name'', ''job_id'', ''extranonce2'',
''ntime'' and ''nonce'').
'''Additional parameters''':
* ''version_bits'' (REQUIRED, ''TMask'') - Version bits set by miner.
::- Miner can set only bits corresponding to the set bits in the last
received mask from the server either as response to
"mining.configure" or "mining.set_version_mask" notification
(<code>last_mask</code>). This must hold: version_bits & ~last_mask
== 0 ::- The server computes ''nVersion'' for the submit as follows:
nVersion = (job_version & ~last_mask) | (version_bits & last_mask)
where <code>job_version</code> is the block version sent to miner as
part of job with id <code>job_id</code>.
==Extension "minimum-difficulty"==
This extension allows miner to request a minimum difficulty for the
connected machine. It solves a problem in the original stratum
protocol where there is no way how to communicate hard limit of the
connected device.
'''Extension parameters''':
* '''"minimum-difficulty.value"''' (REQUIRED, ''Integer/Float'', >= 0)
::- The minimum difficulty value acceptable for the miner/connection.
The value can be 0 for essentially disabling the feature.
'''Extension return values''':
* '''"minimum-difficulty"''' (REQUIRED, ''TExtensionResult'')
::- Whether the minimum difficulty was accepted or not.
::- This extension can be configured multiple times by calling
"mining.configure" with "minimum-difficulty" code again.
==Extension "subscribe-extranonce"==
Parameter-less extension. Miner advertises its capability of receiving
message '''"mining.set_extranonce"''' message (useful for hash rate
routing scenarios).
==Extension "info"==
Miner provides additional text-based information.
'''Extension parameters''':
* '''"info.connection-url"''' (OPTIONAL, ''String'')
::- Exact URL used by the mining software to connect to the stratum
server.
* '''"info.hw-version"''' (OPTIONAL, ''String'')
::- Manufacturer specific hardware revision string.
* '''"info.sw-version"''' (OPTIONAL, ''String'')
::- Manufacturer specific software version
* '''"info.hw-id"''' (OPTIONAL, ''String'')
::- Unique identifier of the mining device
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons
CC0 1.0 Universal.
--
CEO Braiins Systems | Slushpool.com
email: jan.capek at braiins.cz
http://braiins.cz
http://slushpool.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180517/8f71b2a6/attachment-0001.sig>

2023-06-07 18:11:07

- reply

📅 Original date posted:2018-03-07
📝 Original message: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
<bitcoin-dev at lists.linuxfoundation.org> 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:
>
> 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 at 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
CEO Braiins Systems | Slushpool.com
tel: +420 604 566 382
email: jan.capek at braiins.cz
http://braiins.cz
http://slushpool.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180307/87b5929e/attachment-0001.sig>

2023-06-07 17:59:57

- reply

📅 Original date posted:2017-04-07
📝 Original message:Hi,
1 comment below
On Fri, 7 Apr 2017 17:52:17 -0300
Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> <pre>
> BIP: TBD
> Layer: Consensus
> Title: Inhibiting a covert optimization on the Bitcoin POW function
> Author: Sergio Demian Lerner <sergio.d.lerner at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2016-04-07
> License: PD
> </pre>
>
> ==Abstract==
>
> This proposal inhibits the covert use of a known optimization in
> Bitcoin Proof of Work function.
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119.
>
> ==Motivation==
>
> Due to a design oversight the Bitcoin proof of work function has a
> potential optimization which can allow a rational miner to save up-to
> 30% of their energy
> costs (though closer to 20% is more likely due to implementation
> overheads).
>
> Timo Hanke and Sergio Demian Lerner applied for a patent on this
> optimization. The company "Sunrise Tech Group, Llc" has offered to
> license it to any interested party in the past. Sunrise Tech Group
> has been marketing their patent licenses under the trade-name
> ASICBOOST. The document takes no position on the validity or
> enforceability of the patent.
>
> There are two major ways of taking advantage of this optimization, as
> described
> by the patent:
> One way which is highly detectable and is not in use on the network
> today and a covert way which has significant interaction and potential
> interference with the Bitcoin protocol. The covert mechanism is not
> easily detected except through its interference with the protocol.
>
> In particular, the protocol interactions of the covert method can
> block the implementation of virtuous improvements such as segregated
> witness.
>
> The use of this optimization could result in a big payoff, but the
> actual sum depends on the degree of research, investment and effort
> put into designing
> the improved cores.
>
> On the above basis the potential for covert use of this optimization
> in the covert form and interference with useful improvements presents
> a danger to the Bitcoin system.
>
> ==Background==
>
> The general idea of this optimization is that SHA2-256 is a merkle
> damgard hash
> function which consumes 64 bytes of data at a time.
>
> The Bitcoin mining process repeatedly hashes an 80-byte 'block
> header' while incriminating a 32-bit nonce which is at the end of
> this header data. This means that the processing of the header
> involves two runs of the compression function run-- one that consumes
> the first 64 bytes of the header and a second which processes the
> remaining 16 bytes and padding.
>
> The initial 'message expansion' operations in each step of the
> SHA2-256 function operate exclusively on that step's 64-bytes of
> input with no influence from prior data that entered the hash.
>
> Because of this if a miner is able to prepare a block header with
> multiple distinct first 64-byte chunks but identical 16-byte
> second chunks they can reuse the computation of the initial
> expansion for multiple trials. This reduces power consumption.
>
> There are two broad ways of making use of this optimization. The
> obvious way is to try candidates with different version numbers.
> Beyond upsetting the soft-fork detection logic in Bitcoin nodes this
> has little negative effect but it is highly conspicuous and easily
> blocked.
>
> The other method is based on the fact that the merkle root
> committing to the transactions is contained in the first 64-bytes
> except for the last 4 bytes of it. If the miner finds multiple
> candidate root values which have the same final 32-bit then they
> can use the optimization.
>
> To find multiple roots with the same trailing 32-bits the miner can
> use efficient collision finding mechanism which will find a match
> with as little as 2^16 candidate roots expected, 2^24 operations to
> find a 4-way hit, though low memory approaches require more
> computation.
>
> An obvious way to generate different candidates is to grind the
> coinbase extra-nonce but for non-empty blocks each attempt will
> require 13 or so additional sha2 runs which is very inefficient.
>
> This inefficiency can be avoided by computing a sqrt number of
> candidates of the left side of the hash tree (e.g. using extra
> nonce grinding) then an additional sqrt number of candidates of
> the right side of the tree using transaction permutation or
> substitution of a small number of transactions. All combinations
> of the left and right side are then combined with only a single
> hashing operation virtually eliminating all tree related
> overhead.
>
> With this final optimization finding a 4-way collision with a
> moderate amount of memory requires ~2^24 hashing operations
> instead of the >2^28 operations that would be require for
> extra-nonce grinding which would substantially erode the
> benefit of the optimization.
>
> It is this final optimization which this proposal blocks.
>
> ==New consensus rule==
>
> Beginning block X and until block Y the coinbase transaction of
> each block MUST either contain a BIP-141 segwit commitment or a
> correct WTXID commitment with ID 0xaa21a9ef.
>
> (See BIP-141 "Commitment structure" for details)
>
> Existing segwit using miners are automatically compatible with
> this proposal. Non-segwit miners can become compatible by simply
> including an additional output matching a default commitment
> value returned as part of getblocktemplate.
>
> Miners SHOULD NOT automatically discontinue the commitment
> at the expiration height.
>
> ==Discussion==
>
> The commitment in the left side of the tree to all transactions
> in the right side completely prevents the final sqrt speedup.
>
> A stronger inhibition of the covert optimization in the form of
> requiring the least significant bits of the block timestamp
> to be equal to a hash of the first 64-bytes of the header. This
> would increase the collision space from 32 to 40 or more bits.
> The root value could be required to meet a specific hash prefix
> requirement in order to increase the computational work required
> to try candidate roots.
Root value pow - Does this mean that every miner would be penalized in
this way regardless of the actual number of transactions in the block?
> These change would be more disruptive and
> there is no reason to believe that it is currently necessary.
>
> The proposed rule automatically sunsets. If it is no longer needed
> due to the introduction of stronger rules or the acceptance of the
> version-grinding form then there would be no reason to continue
> with this requirement. If it is still useful at the expiration
> time the rule can simply be extended with a new softfork that
> sets longer date ranges.
>
> This sun-setting avoids the accumulation of technical debt due
> to retaining enforcement of this rule when it is no longer needed
> without requiring a hard fork to remove it.
>
> == Overt optimization ==
>
> A BIP for avoiding erroneous warning messages when miners use the
> overt version
> of the optimization was proposed several years ago, in order to deter
> the covert
> use of the optimization. But that BIP was rejected.
> However, in light of the current discoveries, that BIP could be
> reconsidered.
>
> The over optimization does not generally interfere with improvements
> in the protocol.
>
> ==Backward compatibility==
>
>
> ==Implementation==
>
>
> ==Acknowledgments==
>
> Greg Maxwell <greg at xiph.org> for the original report, which contained
> several errors that were corrected in the present proposal.
>
> ==Copyright==
>
> This document is placed in the public domain.
--
CEO Braiins Systems | Slushpool.com
tel: +420 604 566 382
email: jan.capek at braiins.cz
http://braiins.cz
http://slushpool.com