MinerID

MinerID is a set of protocols that allow a miner to embed information inside the coinbase transaction of each block won by a particular node to allow all blocks it wins to be associated with an identity.

This will allow network users to see which nodes are the most proficient at mining enabling them to target those nodes to broadcast transactions and retrieve information about activity on the network such as incoming payments, merkle proofs, double spend queries and more.

Description

Definitions

• MinerId: An ECDSA public key used to by the miner to identify themselves
• VcTx(validity check transaction): A transaction that determines the validity of the minerId based on whether it is unspent (valid) or spent (invalid/revoked)
• Coinbase document: A formatted data packet in the OP_RETURN (provably unspendable)output in the miner’s coinbase transaction that includes all of the minerId info

Security Hardening (Optional)

Ideally, the minerId (by extension the coinbase transaction) should be specific to the block it is in. However, if this were enforced it would create a causality dilemma (chicken/egg scenario) since the header cannot be finalised and signed by the minerId key without the hash of the coinbase transaction which, in turn, cannot be created until the minerId key is finalised.

By making the minerId specific to the block it’s mined in, we effectively bind the signature to the block it’s contained in. Without this binding, a malicious miner could take your entire coinbase document and put it in another block, potentially in a block that damages reputation e.g. by including well known double spends. Because the block height is included in the coinbase document, the malicious miner would effectively have to orphan the block containing the signature they want to reuse (after it is mined) which is of course very expensive. This cost should be enough to make this edge case secure in most cases. However, as miner reputations become more valuable there could possibly be cases where the increased market share that comes from knocking a major miner out of the trusted network and causing them lose access to semi-trusted services has enough upside to justify the cost.

An easy countermeasure to mitigate this is similar to double spend transactions with the “first seen rule”. An attack like this should be fairly easy to detect, especially if there are two competing blocks signed by the same minerId where one includes double spends and the other doesn’t.

If a miner is still not satisfied with the security described above, they can optionally implement either of the following two extension techniques to harden security:

To get around the chicken/egg scenario described above we recalculate the Merkle tree but replace the coinbase hash with the hash of the public key thus ensuring that the header hash will be unique to the miner. Then we include that block header in the minerId extension fields. Recalculating a Merkle tree with a different 1st element is an inexpensive operation. The nonce field is also set to zero.

To more accurately and securely represent who is involved in the mining process, two messages and two signatures may be for the coinbase document. One belonging to the worker machine (hasher), while the other belonging to the block builder/operator (pool master):

Examples

The minerid protocol has been supported by TAAL mining ltd. since 20th December 2019.

• https://whatsonchain.com/tx/17a8b9994f1e89855b34660ea1d17061ae65833f1ded395c4c6a72d2d98832a6

• https://whatsonchain.com/tx/d898e7f3c198cefccf99e6ec982786f25af62aa86d6bc56c66a611660bf04942

See Also

• Medium.com blog post - https://medium.com/@jadwahab/6578046ac88?