Will we need an EIP to allow Hashpower signaling, and Node operator Signaling?

I am working on the signalling team and two of the signals we want to include is Miner Hash-rate Signaling, and Node Operator signalling. I was listening in on last weeks core-dev call and there was discussion about the competing mining reward reductions, and a communicated desire to hear how the mining community felt about these changes. Seeing as this sort of signaling is on our Roadmap I am doing some digging into what we would need if any EIP development to support these two signals.

Requirements Draft

  • Signal support for an arbitrary set of EIPs
    • Any set up EIPS can be signaled
    • It is okay if that set be size limited due to implementation requirements
  • Three positions supported
    • Yay
    • Nay
    • Either

On the ethereum governance gitter I was pointed to this having already existed.

There was some open questions regarding whether an arbitrary set would affect consensus.

A formalized system for encoding these may fit for an EIP. Also, if we needed to make any changes would any of them require a hard fork?

I am happy to cowrite an EIP with anyone for either of the two signals.

James (madeof_tin)

1 Like

I will never support a signalling proposal that doesn’t have these options:

• Yay
• Nay
• Abstain
• No vote

Having data on how many “voters” actively choose to abstain from the vote as opposed to not participating at all is a critical signal.

Also, I don’t see why “node operator” signalling is or even can be a real thing. How is this possible sybil resistant? You can lock coins in contracts, do some proof of work, or be a public figure who openly displays their vote, but I really can’t think of any other valid signals.

Can you clarify the difference between these?
I envisioned “either” representing those who don’t care if it is Yay, or Nay, but choose to vote. Abstain may be a better word for this.

I believe “abstain” means you are actively voting, but you are not picking a side while “no vote” means you never even showed up (you likely don’t know how to vote, or you don’t care enough to pay attention, or similar).

As I have argued elsewhere I am against miner signalling because we shouldn’t care what they want. They are a service provider, not economic participants.

To echo what @AtLeastSignificant said, node signalling is not Sybil resistant. I can simulate running as many nodes as I want.

Not every signal has to be an aggregate; an important sources of signals could be from a stakeholder group or working group / Ring. Such a group would come to consensus about what to signal internally by their own governance, and the result recorded in a contract that they control.

I agree that signals from individuals and especially groups should have options (e.g. Yay, Nay, Abstain). And also a short text statement explaining the rationale behind their signal.

And ultimately it is up to the client implementers and other readers/users of signals to determine how to interpret signals, whether aggregated or from a stakeholder group.

I really like the addition of an optional statement being included. That will be something else I will investigate.

If you simulate running a full node does it require the same amount of resources as running a full node?

I can’t think of a good way to prove that you’re running multiple full nodes rather than just 1 without doing some kind of Proof of X, but then you need to incentivize doing Proof of X because doing it inherently has a cost, and oh wait now we are just talking about miners XD

@jpitts I agree that having signals from private/non-aggregate parties is important, and the inclusion of a message would go well with that sort of thing. However, I see some potential for confusion/manipulation with this because anybody can then create a signal for whatever and talk about it as if it holds the same weight as others, simply because they are both valid signals.

Can’t these private/non-aggregate entities simply make a public statement instead? Or what is the added value of “signalling” as opposed to anything else for these groups?

That is the correct difference between “abstain” and “no vote”. I honestly find this data to be some of the most important because it allows clients to have a valid default setting for users - no vote.

We can then observe the level of signalling participation, which is immensely important when trying to measure decentralization and creating governance processes. It dispels a lot of FUD (or confirms it) whenever there is a contentions decision, and would highlight what I think is one of the biggest issues with this network (that the vast majority of miners/users/coin holders/or otherwise “valid voters” are completely apathetic).

I am against miner signalling because we shouldn’t care what they want

I still believe this is a bit more nuanced, but as the market grows miners lose power to make decisions by themselves and shape the landscape for the market in their favor. I think it’s fair to say they are slaves at this point, and miner signalling is really just as valid as full-node operator signalling.

However, we can actually do miner signalling since there is sybil resistance built-in. I think that alone is a good enough reason to include it in any signalling effort.

I actually wrote a spec for hashpower signaling based on BIP-9 back in 2017. Just re-submitted this as an EIP in case this is useful.