Difference between revisions of "MinerID"
AlexMackay (talk | contribs) |
Todd Price (talk | contribs) |
||
| (10 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | MinerId is a protocol that allows a | + | MinerId is a protocol that allows a Miner to embed information inside the [[Coinbase|coinbase transaction]] of each block won by a particular node, to allow all blocks it wins to be associated with a pseudonymous identity which the Miner can optionally associate with a real world identity. |
==Description== | ==Description== | ||
| − | Currently, Bitcoin | + | Currently, Bitcoin Miners can embed identity data on the Bitcoin ledger by using space in the malleable input fields of the [[Coinbase|coinbase]] transaction in blocks that they mine. However, this data is not always accurate and can be trivially forged/spoofed. |
| + | The MinerId protocol provides a way of ''cryptographically'' associating a block to a specific Miner's pseudo identity. A minerId is simply a public key from an ECDSA keypair. These keys are used to sign minerID [[metadata]] contained in a [[False Return]] output of the coinbase transaction in a block. | ||
| − | + | Use of ECDSA cryptography to sign minerId metadata (as opposed to generating unsigned arbitrary data) provides data non-repudiation, linking Miner identity to mined blocks in a reliable way. | |
| − | + | Whilst the minerId protocol is a useful infrastructure tool for the Bitcoin SV network, '''it is not mandatory'''. It is a voluntary protocol providing a public key infrastructure for Bitcoin SV that Miners can use to secure additional services around the ledger. | |
| − | |||
| − | Whilst the minerId protocol is a useful infrastructure tool for the Bitcoin SV network, | ||
===Definitions=== | ===Definitions=== | ||
| − | * '''MinerId''' - An ECDSA public key (based on [[secp256k1]] parameters) used by the | + | * '''MinerId''' - An ECDSA public key (based on [[secp256k1]] parameters) used 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). The VcTx is a feature that allows a | + | * '''VcTx''' - (Validity check transaction) A transaction that determines the validity of the minerId based on whether it is unspent (valid) or spent (invalid/revoked). The VcTx is a feature that allows a Miner to instantly revoke their minerId (if the private key is compromised for example). Naively, the Miner could add a field in the coinbase document specifying if the minerId is still valid or not. However, by doing that, the Miner would have to wait until they mine a block to revoke their minerId key. Using the VcTx, the Miner can at any time revoke the validity of their minerId key without needing to generate [[Proof of Work|proof of work]]. |
| − | * '''Coinbase document''' - A formatted data packet in the OP_RETURN (provably unspendable) output in the | + | * '''Coinbase document''' - A formatted data packet in the OP_RETURN (provably unspendable) output in the Miner’s [[Coinbase| coinbase transaction]]. All Miner identity information is stored in this document. |
| − | ===Security | + | ===Security=== |
| − | 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 | + | Ideally, the minerId (by extension of 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 | + | 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 the entire coinbase document and replay it in another block, potentially in a block that damages reputation e.g. an empty block that reduces network throughput. Because the block height is included in the coinbase document, the cost of replaying coinbase document data becomes as difficult as successfully forking the network (see [[Re-org]]), which is very expensive. This cost should be enough to drastically reduce the likelihood of this attack. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Examples== | ==Examples== | ||
| − | The | + | The minerId protocol has been supported by TAAL mining ltd. since 20th December 2019. |
* https://whatsonchain.com/tx/17a8b9994f1e89855b34660ea1d17061ae65833f1ded395c4c6a72d2d98832a6 | * https://whatsonchain.com/tx/17a8b9994f1e89855b34660ea1d17061ae65833f1ded395c4c6a72d2d98832a6 | ||
| Line 43: | Line 34: | ||
* Medium.com blog post - https://medium.com/@jadwahab/6578046ac88? | * Medium.com blog post - https://medium.com/@jadwahab/6578046ac88? | ||
| − | |||
| − | |||
Latest revision as of 05:50, 25 April 2022
MinerId is a protocol that allows 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 a pseudonymous identity which the Miner can optionally associate with a real world identity.
Description
Currently, Bitcoin Miners can embed identity data on the Bitcoin ledger by using space in the malleable input fields of the coinbase transaction in blocks that they mine. However, this data is not always accurate and can be trivially forged/spoofed.
The MinerId protocol provides a way of cryptographically associating a block to a specific Miner's pseudo identity. A minerId is simply a public key from an ECDSA keypair. These keys are used to sign minerID metadata contained in a False Return output of the coinbase transaction in a block.
Use of ECDSA cryptography to sign minerId metadata (as opposed to generating unsigned arbitrary data) provides data non-repudiation, linking Miner identity to mined blocks in a reliable way.
Whilst the minerId protocol is a useful infrastructure tool for the Bitcoin SV network, it is not mandatory. It is a voluntary protocol providing a public key infrastructure for Bitcoin SV that Miners can use to secure additional services around the ledger.
Definitions
- MinerId - An ECDSA public key (based on secp256k1 parameters) used 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). The VcTx is a feature that allows a Miner to instantly revoke their minerId (if the private key is compromised for example). Naively, the Miner could add a field in the coinbase document specifying if the minerId is still valid or not. However, by doing that, the Miner would have to wait until they mine a block to revoke their minerId key. Using the VcTx, the Miner can at any time revoke the validity of their minerId key without needing to generate proof of work.
- Coinbase document - A formatted data packet in the OP_RETURN (provably unspendable) output in the Miner’s coinbase transaction. All Miner identity information is stored in this document.
Security
Ideally, the minerId (by extension of 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 the entire coinbase document and replay it in another block, potentially in a block that damages reputation e.g. an empty block that reduces network throughput. Because the block height is included in the coinbase document, the cost of replaying coinbase document data becomes as difficult as successfully forking the network (see Re-org), which is very expensive. This cost should be enough to drastically reduce the likelihood of this attack.
Examples
The minerId protocol has been supported by TAAL mining ltd. since 20th December 2019.
See Also
- Medium.com blog post - https://medium.com/@jadwahab/6578046ac88?