Reserve 16 bits of nversion in blockheader #12633
Conversation
This removes bits 13-28 inclusive (0x1fffe000) from the versionbits signalling system, preventing warnings from being generated for any miners using these bits. This effectively reserves 16 bit for miscellaneous use by miners for things like version-rolling and nonce-rolling and establishes a zone miners can use without causing unexpected disruption.
|
Concept ACK, assuming community support. It seems like having the 16 bits removed be on byte boundaries would be useful (but this may be more complicated). |
|
Without some kind of review in the form of several mining hardware manufacturers weighing in that they feel comfortable building in asicboost into their hardware, I don't think we can give this kind of implied approval of it's use (until then, we could maybe consider changing the warning message to something that implies someone is attacking the network, instead of "unknown rules").
…On March 7, 2018 3:40:11 PM UTC, "฿tcDrak" ***@***.***> wrote:
This will prevent versionbits false positive warnings for blocks mined
with version-rolling or any other known or unknown uses of those
nversion bits 0x1fffe000
You can view, comment on, or merge this pull request online at:
#12633
-- Commit Summary --
* Remove 16 bits from versionbits signalling
-- File Changes --
M src/chainparams.cpp (6)
M src/validation.cpp (2)
M src/versionbits.h (4)
M test/functional/feature_versionbits_warning.py (12)
-- Patch Links --
https://github.com/bitcoin/bitcoin/pull/12633.patch
https://github.com/bitcoin/bitcoin/pull/12633.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#12633
|
|
This needs a bip and mailing list discussion, I guess. |
|
NACK. Very strongly against this. This change is designed to make it easier for a business to use patented technology on the network. This change in Bitcoin Core substantially reduces the number of concurrent soft fork deployments. Rather than improve the Bitcoin network and its functionality, this pull request is designed to aid outside interests and give competitive advantage to a mining hardware business owned by the OP, thereby allowing him to make more money as a result. Merging this change would be an ultimate betrayal against the Bitcoin users, who depend on Bitcoin Core as trusted software that is supposed to be outside the influence of business interests. |
This change doesn't make it easier to use asicboost on the network. It only standardizes the overt type.
Soft fork deployment by miners' signaling is bunk, as we've already seen with recent segwit deployment. Moving on to time\block height based deployment is much safer and doesn't require nversion setting. Even if it would be needed to use nversion setting, there are still many of these bits for use.
Again, nothing stops anybody from using asicboost already. This proposal only standardizes overt asicboost using nversion rolling, which is the cleanest type of asicboost. It doesn't require small\empty blocks and is not dangerous in requiring transaction index permutation.
Let's wait for the rest of the community to react to this proposal before putting words in their mouths. |
|
@fivepiece: Getting into a discussion about whether nversion bits signalling is useful is beyond the scope of what's being discussed. We have to ask, who is this change benefiting? On a technical level, this change reduces the number of possible soft fork deployments from 29 to 13, so functionality is actually being diminished. The only beneficiary is the company owned by OP, which sells hardware implementing the patented version rolling ASICBOOST being standardized by this pull request and associated BIP. Without this, the company is likely to face a public relations nightmare when their use of the patented version roll triggers warnings for full node operators, as it rightly should. Bitcoin Core should not exist to help standardize patented tech, or aid in it's use. At the very least this should not be the default behavior. It's hard to not see how this pull request being merged would not significantly benefit the OP and his business. I ask you to consider if it where BITMAIN that had this optimization in their hardware, and they created a similar pull request. |
|
@Cobra-Bitcoin , are you taking this into account ? Bitmain already has asicboost in their hardware as we all know, but their implementation of covert asicboost only hurts the network (small blocks, incompatible with witness commitment). If they were to propose this same proposal of overt boost then I would be very much for it, taking into account the DPL. I don't believe the reduction from 29 to 13 concurrent soft forks is an issue, and even more so - I believe giving any miner a say in soft fork deployment is inherently broken, so nversion's use in soft fork deployment is even less of a concern for me. |
|
The review comments on pull requests are not meant for extended off-topic discussions. Please refer to the mailing list if you want to provide feedback on the BIP and keep this discussion for review comments on the code. |
This will prevent versionbits false positive warnings for blocks mined with version-rolling or any other known or unknown uses of those nversion bits 0x1fffe000