joshua/dips
1
0
Fork 0
mirror of https://github.com/seigler/dips synced 2025-07-27 01:36:14 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

[DIP6] Use height in special TX payload to make commitment TXs unique (#31)

Browse source 
* Use quorumVvecHash instead of quorumHash to make null commitments unique

quorumHash is required to identify to which quorum the commitment belongs,
so we should not change the meaning of it. Instead, use quorumVvecHash
to make null commitments unique.

* Include "height" in commitment special transaction payload

* Mention validation of the commitment payload

* Add version field and change height field to uint32_t
This commit is contained in:
Alexander Block 2018-11-27 10:42:21 +01:00 • committed by GitHub
parent 3eef1d603a
commit 0afc096282
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

20
dip-0006.md
View file

@ -369,7 +369,7 @@ A final commitment is mined in the payload of a new special transaction (DIP2).
As this special transaction pays no fees, miners generally don’t have an incentive to include the transaction into a new block. To solve this, we make the special transaction mandatory by consensus rules, meaning that exactly one quorum commitment transaction MUST be included in every block while in the mining phase and until a valid commitment is present in a block.
If a DKG failed or a miner did not receive a final commitment in-time, the quorum commitment inside the block must have the quorumHash set to hash(quorumHash, newTipHeight). Also, the signers and validMembers bitsets should be set to the quorumSize and all bits set to zero. All other fields must be set to the null representation of the field’s types. The special handling of the quorumHash ensures that all null commitments result in a different transaction hash.
If a DKG failed or a miner did not receive a final commitment in-time, a null commitment has to be included in the special transaction payload. A null commitment must have the signers and validMembers bitsets set to the quorumSize and all bits set to zero. All other fields must be set to the null representation of the field’s types.
With these new consensus rules, the incentives for miners are turned around. Instead of requiring an incentive to include it in a block, we remove the incentive to leave it out. Whatever the miner decides, the space required for the commitment is always used. If a miner still decides to be dishonest, other honest miners will include the special transaction in one of the next blocks.
@ -377,13 +377,23 @@ These consensus rules are only applied while the DKG is in the mining phase. Aft
Every node, that receives a block, must verify that these consensus rules are followed. This means:
1. If the DKG is not in the mining phase and the new block contains a (null or non-null) commitment, the block should be rejected.
2. If no final commitment was mined for the current DKG yet and the new block does not include a (possibly null) commitment, the block should be rejected.
3. If in the current mining phase a previous block already mined a non-null commitment and the new block contains another (null or non-null) commitment, the block should be rejected.
4. If the block contains more than one commitment, the block should be rejected.
1. If the "height" field of the special transaction payload does not match the height of the block in which it the payload is included, the block should be rejected. This ensures that all commitment special transactions have a unique hash, including null commitments.
2. If the DKG is not in the mining phase and the new block contains a (null or non-null) commitment, the block should be rejected.
3. If no final commitment was mined for the current DKG yet and the new block does not include a (possibly null) commitment, the block should be rejected.
4. If in the current mining phase a previous block already mined a non-null commitment and the new block contains another (null or non-null) commitment, the block should be rejected.
5. If the block contains more than one commitment, the block should be rejected.
6. If the commitment inside the special transaction payload is not valid (see validation rules of the "qfcommit" P2P message), the block should be rejected.
After a block with a valid (non-null) commitment has been accepted and processed, the quorum belonging to the commitment must be added to the active quorums set. From this point on, the quorum is able to perform threshold signing of arbitrary messages and all nodes in the network are able to verify the result (recovered signature) of such signing sessions.
The format of the "quorum commitment" special TX payload with type=6 is:
| Field | Type | Size | Description |
|--|--|--|--|
| version | uint_16 | 2 | Commitment special transaction version number. Currently set to 1. Please note that this is not the same as the version field of qfcommit |
| height | uint32_t | 4 | The height of the block in which this commitment is included
| commitment | qfcommit | Variable | This equals the payload of the "qfcommit" P2P message
## Activated LLMQs and threshold signing
After a DKG finishes and the final commitment has been mined, a LLMQ becomes active and can start participating in signing requests/sessions.