Auditor Role

[average-gary]

Goal: Outline a new role to enable auditing of shares.

Hopefully discussion of associated messaging and implementation for this role can be hashed out in this thread.

Within a mining operation there are many points at which auditing could be conducted, it is my belief that a separate role (daemon) can be run alongside existing roles and connected via protocol extensions and new message definitions. An Auditor role could be tied to any existing role but we will focus on two specific roles to narrow scope for a PoC implementation.

The protocol extension ideally is abstracted enough to support an Auditor opening messaging channels ("channel") with a variety of existing and future roles. However, this initial post will focus on an Auditor having two primary channels: 1. with the pool role 2. with the translator role (mining-proxy may also be appropriate).

The mechanism for auditing will be similar to this Delving Bitcoin post but excludes details on how a Pool does the accounting.

1. Auditor establishes connection with Translator and Pool.
2. Auditor receives current block keyset from Pool.
3. Translator sends all share data to Auditor.
4. Auditor saves share data and assigns blinding factor (x) and pubkey from keyset from Pool
5. Auditor submits blinded message and share hash (combined for xShare) for signing by Pool
6. Pool validates and signs, saving to its DB the blinded signature and associated share (bShare).
7. Pool sends blinded signature back and Auditor unblinds, saving alongside the associated share.
8. This process continues until a block is found by the Pool, then a new keyset if rotated by the pool.
9. If the pool stops signing (attesting) to shares, the Auditor will alert the Translator via a defined message type. In this initial implementation, the Translator will fall back to other pools/solo mining.
10. Once a keyset is rotated/block found, the Pool publishes entire list of bShare.
11. Auditor checks all local xShare against published list.
12. Auditor exchanges list of local xShare with other Auditors of same Pool.
13. Auditor checks all remote xShare against published list.
14. Auditor should find 1:1 matching of xShares

In this, the Pool knows of the shares and cryptographically attests to them via a blinded signing. Auditors know all of their own shares and all blinding factors. Auditors are able to verify that all published bShares match their own list. With collaboration, multiple Auditors can coordinate to ensure a complete list and accounting is done for every share submitted. In an exchange between Auditors, a number of shares could be exchanged at a minimum for verification (i.e. validated X number of shares), although a complete list of blindings factors correlated to shares would allow for each Auditor to comprehensively validate the published list of bShares.

---

This is just one perspective of how an Auditor might be used for hash rate shares.
Other use cases could be:

• Firmware connects to Auditor for inventory/device auditing
• Job Declaration Client/Server Connects to Auditor for coinbase output auditing
• Multiple roles could connect to an Auditor for logs dumping and/or configuration validation
• Power metering devices could interface with an Auditor for validating consumed power vs. actual hash rate

It is my belief that Sv2 provides an excellent framework and robust protocol to build out a transparent and auditable mining ecosystem beneficial to pleb miners as well as utility scale miners and everywhere in between.

[rrybarczyk]

Really great idea. The signing aspect is very smart.

Let's look into the actual messages that contain the information we want to give to the auditors, starting with just the messages containing the submitted shares. Then we can lock down which roles would be involved, if the auditor should be a separate role, etc. Also, we could look into message hooks via tracing which does support web sockets.

[TheBlueMatt]

Shouldn't the pool be providing these signed share acks directly to the translator (via some extension?) so that the translator can indirectly switch to a fallback if the pool stops doing so? Just sending it to an auditor and switching to a fallback means we waste 8 hours of hashing until a human wakes up and intervenes.

[TheBlueMatt]

Hmm, its prety weird for an "auditor" role to be able to control the proxy/mining roles. Instead of being an "auditor" we could make it a "controller" role that lets it control the miners more directly, or we could think of the auditing mechanism more as an extension that can be used in several different places in the stack but built into existing roles.

[average-gary]

I'm not sure where you read that the Auditor would be controlling other roles?

[TheBlueMatt]

However, you do point out a flaw in the proposed solution, there should be a mechanism for the Auditor role to alert roles it's receiving data from that the signing authority has stop provided signatures for whatever reason (malice or offline).

This implies control. Sure, the auditing spec may not explicitly say that miners should switch in response, but the miners sure as hell better actually do that.

More generally, if we're gonna go to the effort to build cryptographically authenticated share submissions, we need to actually use those. There's not a lot of point of having cryptographically authenticated share submissions that let a miner prove the pool didn't pay them if the pool can just stop signing...

[average-gary]

the miners sure as hell better actually do that.

Concur but I'll leave the reaction to individual miners to determine.

we need to actually use those.

Are you suggesting there's a way to force a pool to sign a message? Or there's a way of invalidating PoW if a share is not acknowledged?

Slight aside: Although I don't fully grasp how ZK-rollups work, my basic understand has made me ponder if they're applicable in hash share validation somehow.

Edit: Perhaps you mean a non-interactive protocol vs an interactive one?

[TheBlueMatt]

Concur but I'll leave the reaction to individual miners to determine.

Sure, but then we definitely can't pretend that the "auditor role" isn't controlling other roles, which makes it very much not an "auditing" protocol :). More generally, from a corpsec PoV, I really do want an auditing role that lets me audit, but once it has any kind of control all of a sudden the requirements for that system change drastically.

Are you suggesting there's a way to force a pool to sign a message? Or there's a way of invalidating PoW if a share is not acknowledged?

I'm just saying that we should include it in the mining protocol - if the share.Ack message going from the pool to the proxy is expected to include the signature (assuming that feature is negotiated/configured on the proxy), the miner can instantly switch to fallback pool. Then the miner can forward that signature and the share to the auditing system which can verify everything is working as expected without any ability to control anything.

Slight aside: Although I don't fully grasp how ZK-rollups work, my basic understand has made me ponder if they're applicable in hash share validation somehow.

I don't think you want to do any kind of ZKP thing here, they're too slow.

[mcelrath]

This is going to be a fairly naive review of this idea but...

IMHO this is far too complicated.

First, I don't understand the need for blind signing at all. There's no secret information in shares. Nor key rotation. Why?

Second, AFAIK StratumV2 doesn't validate block templates at all. Auditing of shares which may not become bitcoin blocks is not terribly useful. It makes me worry that e.g. shares submitted to a different pool might be submitted to the auditor, and the auditor wouldn't know.

Maybe the signing is intended to replace validation of block templates, but this still enables a number of ways that the pool could cheat. Auditing only unverifiable claims of the Pool operator is not auditing if you don't trust your pool.

I probably got all this horribly wrong, but I said I'd take a look at it...

[average-gary]

First, I don't understand the need for blind signing at all. There's no secret information in shares. Nor key rotation. Why?

From an auditing perspective, you want to break knowledge of the miner from the pool. By using blind signatures, the pool cannot censor or fudge numbers for a specific miner/user. When the unblinded signature is presented to the pool, it has no way of knowing where the signature originated from but knows it to be a valid signature.

[TheBlueMatt]

Second, AFAIK StratumV2 doesn't validate block templates at all.

Pools absolutely need to spot-validate block templates, but...

Auditing of shares which may not become bitcoin blocks is not terribly useful. It makes me worry that e.g. shares submitted to a different pool might be submitted to the auditor, and the auditor wouldn't know.

I think there's a bit of confusion here. AFAIU the "auditor" here is the miner's internal auditing department, not the pool or some third-party. The miner wishes to audit what the pool is doing as well as monitor their own hashrate. The audit trail should allow the miner to prove to the pool they are owed more funds, but the pool would still need to verify that claim and compare the audit log against the templates being mined.

[vnprc]

This is a great idea. With the blind signatures you are halfway to ecash tokens. The only thing remaining is to make these credentials tradeable. There are a lot of cool benefits to creating a mining share free market. I am working on a design to do this with Sv2 and the cashu protocol. The high level architecture looks like this:

                  miner                       mining pool
            __________________              ______________
ASIC ----> |  cashu wallet /  |            | cashu mint / |
ASIC ----> | translator proxy | <--------> |  pool role   |
ASIC ----> |__________________|            |______________|
                                                  ^
                                                  |
                                                  v
                                             auditor role

We can lean on the existing cashu mint and wallet implementations to do the blind signing and token storage. (We're calling mining share backed ecash tokens ehash.)¹

The scheme only works with PPLNS or similar payouts. There are two flows that need to be nailed down:

• token issuance
• token redemption

Issuance is fairly straightforward. The wallet/proxy submits a blinded token using the mint's keyset with each share it finds. The pool/mint validates the share then signs the blinded token and sends the signature to the wallet/proxy where it is stored in the wallet database.

To pay out mining rewards, each time the pool finds a block it should wait a few confirmations and then begin exchanging ehash tokens for bitcoin-backed ecash tokens, lightning payouts, or possibly on-chain payouts.². Hashrate verification is a crucial piece of the puzzle for keeping the pools honest. For this reason the pool's auditor role should release it's data with each block mined including:

• bShares
• block templates
• block headers
• nonces³

This data should be packaged up into some kind of a merkle tree or merkle sum tree for fast verification. This will be a lot of data⁴ so the pool will probably want to seed a torrent using the bittorent protocol to minimize this spiky bandwidth load. The pool should include an attestation to the cashu keysets in this merkle tree and and include the merkle hash in the coinbase output to prevent hashers from claiming shares with multiple pools at the same time. In this way it will be impossible to opaquely issue ehash tokens without the underlying proof of work required to mine a share. If the pool tries to cheat in this way anyone could prove it by demonstrating that the block header associated with any given ehash token does not meet the difficulty threshold or that there are duplicate ehash tokens issued for the same share.

When it comes to miner submitted block templates the pool only really needs to validate the coinbase transaction. With a scheme like this one the pool can directly compensate miners for mining on more valuable block templates and incorporate this calculation into the ehash <-> ecash exchange rate.

I am very happy to see independent developers take up the project of hashrate validation. It gives me conviction that this is a sound idea.

Footnotes

1. Personally, I favor calling them hashtokens because who doesn't like a weed double entendre but I think ehash is a more accessible name that regrettably avoids direct association with a socially stigmatized intoxicant. ↩

2. One of the most promising prospects of this whole proposal, in my opinion, is the possibility of exchanging ehash tokens for a coinbase output. Although there are some tricky problems to solve here. ↩

3. Including extranonce and any other data needed to recreate the block header hash. ↩

4. The pool can leverage its difficulty threshold to moderate the size of this data dump. ↩

[vnprc]

The pool should include an attestation to the cashu keysets in this merkle tree and and include the merkle hash in the coinbase output to prevent hashers from claiming shares with multiple pools at the same time.

In hindsight, I think this should be a separate merkle tree with the root hash included somewhere in the coinbase transaction. The share proof merkle tree will change too quickly to be included in the coinbase. We only need to attest to the cashu mint in the block template, which is what the keyset merkle tree accomplishes.

Both merkle trees will need to be packaged up and broadcast when the pool finds a block.