The nVersion field of a block never affects the rules applied, so a miner can always be free to set the nVersion to anything.

@sipa Which part are you referring to? GBT servers may very well want to restrict the nVersion to things they can handle.

I had interpreted "the server requires support for" as rules the server demanded you to enforce, rather than rules the server demands you to set bits for. It's a bit confusing that rules and rulesenforced are about consensus rules, and rulesrequires is about nVersion bits to be set. Perhaps replace rulesrequired with versionrequired, with an integer of bits the server requires you to set in nversion?

I would have grouped "rules" and "rulesrequired" together, since they deal with bits available/allowed and required; vs "rulesenforced" which is the actual consensus rules being used. Maybe "vbits" and "vbitsrequired"?

ACK BIP141

@luke-jr vbits would just be the same as version, I think?

Isn't this sufficient:

• vbrequired: bits in nVersion that the server demands to be set (so an integer)
• rules: list of strings of deployments whose rules are in effect

?

@sipa How will clients know what bits are available and what they mean in context?

@luke-jr What do you mean by "available"?

@sipa Bits which have a defined meaning.

@luke-jr Why does that matter? If the bits are not active, they have no relevance for mining the block, as there are never any consensus rules in BIP9 that prevent you from setting any combination at all of version bits. The server may insist that you set some to vote for, but apart from that, that information is not relevant to the client.

The client needs the information to know which bits it wants to or doesn't want to set.

So put each and every BIP into the GBT client, even before it has activated?

Consider that the server trusted for name:bit mappings could very well be your own local bitcoind.

Also, even if each BIP were put into the GBT client, the client doesn't have the required blockchain context to determine if the BIP has activated or is still pending.

If the client software doesn't know about a BIP, why does it care?

How does it help that the server says "these arbitrary string names exist",
if the client doesn't know what protocol changes they correspond to? If
they care about the rules, they know the rule's name too.

@luke-jr Yes, saying with rules are active is useful. Saying which exist
isn't. They're just arbitrary strings with no meaning to the client. If
they do know about them, they don't need to be told.

For example, a miner might want to use --veto-vbits=bip109 to instruct their software to automatically unset the BIP 109 bit, and reject pools that require it. Or --require-vbits=bip109 for the opposite.

@luke-jr What if the server doesn't know about a particular BIP yet, but the miner does? If the miner has an opinion about a particular BIP/deployment, they also know what bits to use.

If the server doesn't support it, it shouldn't be indicating it does regardless.

The changes in BIP22 are just formatting?

Yes, someone noticed the {{templates}} were not rendering on GitHub.

ACK 141

Concept ACK on GBT changes. It's a bit hazy though as to what the server should do if a softfork rule is missing from the request, and there's the possibility of altering the block (potentially in a nasty way, like coinbase-only) to make it compatible. In segwit's case, would the lack of a "segwit" rule in the request cause an error post-activation, or would witness transactions be filtered out?

It's a bit hazy though as to what the server should do if a softfork rule is missing from the request, and there's the possibility of altering the block (potentially in a nasty way, like coinbase-only) to make it compatible. In segwit's case, would the lack of a "segwit" rule in the request cause an error post-activation, or would witness transactions be filtered out?

The server has a few options:

• Filter out witness transactions and use rules/force
• Produce the full witness-enabled template, and do not use rules/force. The client in this case must refuse to proceed unless it can handle segwit (listed in "rules")
• Throw an error

Right, and that ambiguity is kinda nasty without a proposed implementation. I'd go as far as saying that it should never throw an error if there's the possibility of somehow creating a valid block. Maybe another input flag could be added for "fail for degraded blocks".

Regardless, this needs to be laid out in the BIP.

Which method a server uses in this situation is implementation-specific, not part of the standard. In any case, it is already documented clearly here: https://github.com/bitcoin/bips/pull/365/files#diff-6a9961b118279d111faf86ad6ebbfedbR204

Please feel free to proposed improved language.

NACK that. Where preferences can be communicated, they should be, and they should be respected by the server. Otherwise what ends up being "part of the standard" is the default behavior of the leading implementation.

I don't understand what you're NACKing.

I'm NACKing the language that makes the behavior implementation-specific. I'm suggest changes to either:

• Add a rules/degraded value to the template, so that the miner is aware that the block has been downgraded in some way as a result of a missing input rule. This is different from the rules/force key, in that the latter does not necessarily mean that the block has been degraded.
  or
• Add an optional "error_degraded" key to the request that signals that the server should not try to degrade the block as a result of a missing input rule, but throw an error instead.

Along with the addition of text along the lines of Unless signaled (by whichever mechanism above), the server should always attempt to provide the client with a template that will allow the client to create a valid block, degraded only as much as is necessary. Only in the case where no solution from the client would be valid should the server return an error.

With those changes, it would be clear what the implementation for Core should look like.

Any item in "rules" the client does not understand implies it must error or (if "rules/force" is allowed) "is degraded".

Force (as I read it) doesn't necessarily mean degraded. It could simply mean that a serialization change would break the block, but that transactions haven't been removed. For example some future soft-fork that specifies a required order for transactions.

More importantly though, the text above guarantees backwards-compatibility when possible, as opposed to letting the implementation decide.

A softfork requiring ordered transactions would necessarily need to a new "rules" entry. When there are no rules that the client doesn't understand, "rules/force" is a no-op.

It's not the business of the spec to force backward compatibility. Implementations that don't want to provide it should be free not to.

@theuni Have your concerns been addressed?

ACK