From c40d804793cb627cdf370182b75525b5e1dd31e2 Mon Sep 17 00:00:00 2001
From: Alexander Block <ablock84@gmail.com>
Date: Thu, 22 Nov 2018 06:33:49 +0100
Subject: [PATCH 1/4] 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.
---
 dip-0006.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dip-0006.md b/dip-0006.md
index 80aaff29..b3fe3fcd 100644
--- a/dip-0006.md
+++ b/dip-0006.md
@@ -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, the quorum commitment inside the block must have the quorumHash set to the correct quorumHash and quorumVvecHash 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 quorumVvecHash field ensures that all null commitments result in a different transaction hash.
 
 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.
 

From d80583f90951350763aad61e4279117969902331 Mon Sep 17 00:00:00 2001
From: Alexander Block <ablock84@gmail.com>
Date: Mon, 26 Nov 2018 16:50:57 +0100
Subject: [PATCH 2/4] Include "height" in commitment special transaction
 payload

---
 dip-0006.md | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/dip-0006.md b/dip-0006.md
index b3fe3fcd..aeaf171c 100644
--- a/dip-0006.md
+++ b/dip-0006.md
@@ -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 the correct quorumHash and quorumVvecHash 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 quorumVvecHash field 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,21 @@ 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.
 
 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 |
+|--|--|--|--|
+| height | int | 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.

From e751aadfdbc4eed495f839ee54082aac4144da0f Mon Sep 17 00:00:00 2001
From: Alexander Block <ablock84@gmail.com>
Date: Mon, 26 Nov 2018 16:51:33 +0100
Subject: [PATCH 3/4] Mention validation of the commitment payload

---
 dip-0006.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dip-0006.md b/dip-0006.md
index aeaf171c..9c80ba8e 100644
--- a/dip-0006.md
+++ b/dip-0006.md
@@ -382,6 +382,7 @@ Every node, that receives a block, must verify that these consensus rules are fo
 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.
 

From 56724be8630145ebf7b36cbbf48c7a35fdfc7c7a Mon Sep 17 00:00:00 2001
From: Alexander Block <ablock84@gmail.com>
Date: Mon, 26 Nov 2018 17:04:17 +0100
Subject: [PATCH 4/4] Add version field and change height field to uint32_t

---
 dip-0006.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dip-0006.md b/dip-0006.md
index 9c80ba8e..8ab4a52a 100644
--- a/dip-0006.md
+++ b/dip-0006.md
@@ -390,7 +390,8 @@ The format of the "quorum commitment" special TX payload with type=6 is:
 
 | Field | Type | Size | Description |
 |--|--|--|--|
-| height | int | 4 | The height of the block in which this commitment is included
+| 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
