From 2b248905173e985415388d2286f4f1a13773ccec Mon Sep 17 00:00:00 2001 From: Alexander Block Date: Fri, 3 May 2019 17:57:22 +0200 Subject: [PATCH 1/5] Update DIP8 to use "blockHeight" instead of prevBlockHash in request ids This prevents conflicting CLSIGs on temporary chain splits. The code was already using the block height, but the DIP was never updated. --- dip-0008.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/dip-0008.md b/dip-0008.md index f66b4fb1..ab001920 100644 --- a/dip-0008.md +++ b/dip-0008.md @@ -93,9 +93,10 @@ when receiving funds and removing the possibility of 51% mining attacks. When a new valid block is received by a masternode, it must invoke the [DIP007 `SignIfMember` operation](https://github.com/dashpay/dips/blob/master/dip-0007.md#void-signifmemberuint256-id-uint256-msghash-int-activellmqs). -The request id for the operation is `hash(prevBlockHash, attemptNum)` and the +The request id for the operation is `hash("clsig-attempt", blockHeight, attemptNum)` and the message hash is the hash of the new block (`newBlockHash`). The first time this -is attempted, `attemptNum` must be set to `0`. +is attempted, `attemptNum` must be set to `0`. "clsig-attempt" is a static string that +must be prepended by its length (13, as a compactSize uint). In most cases, the majority of the LLMQ will sign the same message hash in the first attempt and thus find consensus. This can be checked with the [DIP007 @@ -122,10 +123,10 @@ consensus has been reached. ## Finalization of signed blocks After a signing attempt has succeeded, another LLMQ must sign the successful -attempt. This is only performed once for each `prevBlockHash` and thus either +attempt. This is only performed once for each `blockHeight` and thus either succeeds or fails without performing additional attempts. -The request id is `prevBlockHash` and the message hash is the block hash of the +The request id is `hash("clsig", blockHeight)` and the message hash is the block hash of the previously successful attempt. After a LLMQ member has successfully recovered the final ChainLocks @@ -134,7 +135,7 @@ message is called `CLSIG` and has the following structure: | Field | Type | Size | Description | |--|--|--|--| -| prevBlockHash | uint256 | 32 | Hash of the previous block | +| height | int32 | 4 | Height of the signed block | | blockHash | uint256 | 32 | Hash of the signed block from the successful attempt | | sig | BLSSig | 96 | Recovered signature | @@ -143,14 +144,11 @@ This message is propagated through the inventory system. Upon receipt, each node must perform the following verification before announcing it to other nodes: - 1. `prevBlockHash` must refer to a block that is part of any locally known -chain - 2. Based on the deterministic masternode list at the chain height of -`prevBlockHash`, a quorum must be selected that was active at the time this -block was mined - 3. The signature must verify against the quorum public key and -`hash(llmqType, quorumHash, prevBlockHash, blockHash)`. `llmqType` and `quorumHash` -must be taken from the quorum selected in 2. + 1. Based on the deterministic masternode list at the given height, a quorum must be + selected that was active at the time this block was mined + 2. The signature must verify against the quorum public key and + `hash(llmqType, quorumHash, hash(height), blockHash)`. `llmqType` and `quorumHash` + must be taken from the quorum selected in 2. ## Handling of signed blocks From e60bea81b78b42cee945284cb66e91c13fd6cc3e Mon Sep 17 00:00:00 2001 From: Alexander Block Date: Fri, 3 May 2019 17:58:39 +0200 Subject: [PATCH 2/5] Add "Used LLMQ type" section to DIP8 --- dip-0008.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/dip-0008.md b/dip-0008.md index ab001920..861ed68a 100644 --- a/dip-0008.md +++ b/dip-0008.md @@ -15,6 +15,7 @@ 1. [Abstract](#abstract) 1. [Motivation](#motivation) 1. [Prior Work](#prior-work) +1. [Used LLMQ type](#used-llmq-type) 1. [Signing attempts](#signing-attempts) 1. [Finalization of signed blocks](#finalization-of-signed-blocks) 1. [Handling of signed blocks](#handling-of-signed-blocks) @@ -88,6 +89,10 @@ when receiving funds and removing the possibility of 51% mining attacks. - [DIP 006: Long Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md) - [DIP 007: LLMQ Signing Requests / Sessions](https://github.com/dashpay/dips/blob/master/dip-0007.md) +## Used LLMQ type + +All signing sessions/requests involved in ChainLocks must use the LLMQ_400_60 LLMQ type. + ## Signing attempts When a new valid block is received by a masternode, it must invoke the [DIP007 From f92c8f7b55b1126b2e7dc3b5935d19b79cb9ef83 Mon Sep 17 00:00:00 2001 From: Alexander Block Date: Fri, 3 May 2019 17:58:52 +0200 Subject: [PATCH 3/5] Describe safe transactions in DIP8 --- dip-0008.md | 41 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/dip-0008.md b/dip-0008.md index 861ed68a..d2cfc50c 100644 --- a/dip-0008.md +++ b/dip-0008.md @@ -16,6 +16,7 @@ 1. [Motivation](#motivation) 1. [Prior Work](#prior-work) 1. [Used LLMQ type](#used-llmq-type) +1. [Safe transactions](#safe-transactions) 1. [Signing attempts](#signing-attempts) 1. [Finalization of signed blocks](#finalization-of-signed-blocks) 1. [Handling of signed blocks](#handling-of-signed-blocks) @@ -93,9 +94,47 @@ when receiving funds and removing the possibility of 51% mining attacks. All signing sessions/requests involved in ChainLocks must use the LLMQ_400_60 LLMQ type. +## Safe transactions + +In general, all blocks which are considered valid could also be considered for ChainLocks. +There is however a small risk of transactions conflicting with InstantSend locks, which +requires some conflict resolution, which means that ChainLocks need to be prioritized over +InstantSend locks when conflicts arise. + +As such conflict resolution is quite severe and in some sense voids all the security gained +by InstantSend, it is desired to reduce the probability of such conflicts to practically zero. + +This can be achieved by a change in block template generation. Miners are encouraged to only +include transactions in blocks which are considered "safe". A transaction is considered safe +if it is InstantSend locked or locally known for at least 10 minutes without a conflicting +InstantSend lock appearing in the meantime. The default implementation for block template +generation (as found in Dash Core) will be changed to honor this. + +At the same time, masternodes should only try to sign/lock blocks which include only "safe" +transactions. This in turn means that ChainLocks will only be created when the whole block +is considered "safe", which means that the probability of a conflicting InstantSend lock +appearing after the creation of the ChainLock is practically zero. + +This assumes that [DIP-0010 LLMQ based InstantSend](https://github.com/dashpay/dips/blob/master/dip-0010.md) +is already implemented as it changes InstantSend behaviour to try to lock all transactions +instead of just a few selected ones. + +DIP-0010 also implements "retroactive signing of transactions", which guarantees that transactions +get InstantSend locked in a retroactive way when these were unknown before appearing in a +mined block. This prevents blocks which contain unlocked transaction to suppress ChainLocks, +as it allows the ChainLocks system to sign a block retroactively as well. + ## Signing attempts -When a new valid block is received by a masternode, it must invoke the [DIP007 +Each masternode should periodically try to sign the current chain tip. When the tip already got a valid +ChainLock, this can be skipped. + +Before actually signing the tip, each masternode should check if all transactions contained in all blocks +between the last ChainLocked block and the current chain tip are "safe" (see previous section). This check +should be limited to a depth of 6 blocks in case there is no known previous ChainLock or if the previous +ChainLock is deeper then 6 blocks. + +When these checks pass, each masternode must invoke the [DIP007 `SignIfMember` operation](https://github.com/dashpay/dips/blob/master/dip-0007.md#void-signifmemberuint256-id-uint256-msghash-int-activellmqs). The request id for the operation is `hash("clsig-attempt", blockHeight, attemptNum)` and the From 251d29dcc9b99a0abfd3239c469f2b768487f012 Mon Sep 17 00:00:00 2001 From: UdjinM6 Date: Sat, 4 May 2019 12:05:01 +0200 Subject: [PATCH 4/5] Update dip-0008.md Co-Authored-By: codablock --- dip-0008.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dip-0008.md b/dip-0008.md index d2cfc50c..e2bfe71a 100644 --- a/dip-0008.md +++ b/dip-0008.md @@ -134,7 +134,7 @@ between the last ChainLocked block and the current chain tip are "safe" (see pre should be limited to a depth of 6 blocks in case there is no known previous ChainLock or if the previous ChainLock is deeper then 6 blocks. -When these checks pass, each masternode must invoke the [DIP007 +When these checks pass, each masternode must invoke the [DIP0007 `SignIfMember` operation](https://github.com/dashpay/dips/blob/master/dip-0007.md#void-signifmemberuint256-id-uint256-msghash-int-activellmqs). The request id for the operation is `hash("clsig-attempt", blockHeight, attemptNum)` and the From 51863ed48709dafb69bf802c98afe6a4264d8d87 Mon Sep 17 00:00:00 2001 From: Alexander Block Date: Mon, 6 May 2019 16:34:44 +0200 Subject: [PATCH 5/5] Review suggestions from thephez --- dip-0008.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/dip-0008.md b/dip-0008.md index e2bfe71a..be24e171 100644 --- a/dip-0008.md +++ b/dip-0008.md @@ -96,23 +96,22 @@ All signing sessions/requests involved in ChainLocks must use the LLMQ_400_60 LL ## Safe transactions -In general, all blocks which are considered valid could also be considered for ChainLocks. -There is however a small risk of transactions conflicting with InstantSend locks, which -requires some conflict resolution, which means that ChainLocks need to be prioritized over -InstantSend locks when conflicts arise. +In general, all valid blocks could also be considered for ChainLocks. There is a small +risk of confirmed transactions conflicting with InstantSend locks. To resolve these conflicts, +ChainLocks need to be prioritized over InstantSend locks when conflicts arise. As such conflict resolution is quite severe and in some sense voids all the security gained -by InstantSend, it is desired to reduce the probability of such conflicts to practically zero. +by InstantSend, it is desirable to reduce the probability of such conflicts to practically zero. This can be achieved by a change in block template generation. Miners are encouraged to only -include transactions in blocks which are considered "safe". A transaction is considered safe -if it is InstantSend locked or locally known for at least 10 minutes without a conflicting -InstantSend lock appearing in the meantime. The default implementation for block template -generation (as found in Dash Core) will be changed to honor this. +include “safe” transactions in blocks. A transaction is considered safe if it is InstantSend +locked or locally known for at least 10 minutes without a conflicting InstantSend lock +appearing in the meantime. The default implementation for block template generation +(as found in Dash Core) will be changed to honor this. At the same time, masternodes should only try to sign/lock blocks which include only "safe" -transactions. This in turn means that ChainLocks will only be created when the whole block -is considered "safe", which means that the probability of a conflicting InstantSend lock +transactions. This means that ChainLocks will only be created when the whole block +is considered "safe". Consequently, the probability of a conflicting InstantSend lock appearing after the creation of the ChainLock is practically zero. This assumes that [DIP-0010 LLMQ based InstantSend](https://github.com/dashpay/dips/blob/master/dip-0010.md) @@ -120,19 +119,19 @@ is already implemented as it changes InstantSend behaviour to try to lock all tr instead of just a few selected ones. DIP-0010 also implements "retroactive signing of transactions", which guarantees that transactions -get InstantSend locked in a retroactive way when these were unknown before appearing in a -mined block. This prevents blocks which contain unlocked transaction to suppress ChainLocks, -as it allows the ChainLocks system to sign a block retroactively as well. +are InstantSend locked in a retroactive way if they were unknown before appearing in a +mined block. This prevents blocks which contain unlocked transactions from suppressing +ChainLocks, as it allows the ChainLocks system to sign blocks retroactively as well. ## Signing attempts -Each masternode should periodically try to sign the current chain tip. When the tip already got a valid +Each masternode should periodically try to sign the current chain tip. When the tip already has a valid ChainLock, this can be skipped. Before actually signing the tip, each masternode should check if all transactions contained in all blocks between the last ChainLocked block and the current chain tip are "safe" (see previous section). This check should be limited to a depth of 6 blocks in case there is no known previous ChainLock or if the previous -ChainLock is deeper then 6 blocks. +ChainLock is deeper than 6 blocks. When these checks pass, each masternode must invoke the [DIP0007 `SignIfMember` operation](https://github.com/dashpay/dips/blob/master/dip-0007.md#void-signifmemberuint256-id-uint256-msghash-int-activellmqs).