* This adds two sections to dip 0008. The first section considers the security of Chain Locks and provides the calculations needed to evaluate the security. The second added sections provides mitigations of situtaions when
attackers do not own the collatoral of the masternodes.
* Update dip-0008.md
* Fix hyperlinks
* Update dip-0008.md
* Update dip-0008.md
correction of word.
Co-Authored-By: UdjinM6 <UdjinM6@users.noreply.github.com>
* Update dip-0008.md
Need to make sure it's always big choose small.
Co-Authored-By: UdjinM6 <UdjinM6@users.noreply.github.com>
* Fixes inconsistantcy in gifs
* Update dip-0008/quorum_attack.py
fix tpyo
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008.md
Changing titles, todo change table.
Co-Authored-By: UdjinM6 <UdjinM6@users.noreply.github.com>
* Clarify table
This handles the edge case of witholding a ChainLock correctly, it takes 161 nodes to withold a ChainLock.
Also makes table clearer to read.
* Clarify malicious chainlock
Based on suggestions from AndyFreer a second paragraph is added to explain what can go wrong.
* Update dip-0008.md
Add line break.
Co-Authored-By: UdjinM6 <UdjinM6@users.noreply.github.com>
* Apply suggestions of thephez
The calculations were updated to refelct the fact that 161 masternodes are needed to withhold a chainlock
in a previous commit. This commit updates the text and displayed formulas to reflect this fact.
We also alert the reader that we assume that all uncompromised nodes are behaiving as expected. We include the effect of relaxing this
assumption, however the calculations are left to the reader. The python function provided makes it easy.
* Fix two typos
* Update dip-0008.md
one missed 160->161
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008.md
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Correct C size in sumation formula
* Update dip-0008/quorum_attack.py
correct spelling
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
correct spelling
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
correct spelling
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
correct spelling
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
correct spelling
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
* Update dip-0008/quorum_attack.py
Co-Authored-By: thephez <thephez@users.noreply.github.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: thephez <thephez@users.noreply.github.com>
* 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.
* Add "Used LLMQ type" section to DIP8
* Describe safe transactions in DIP8
* Update dip-0008.md
* Review suggestions from thephez
* Move "Current LLMQ types" into its own section
Shouldn't have been a sub-section of the "Finalization phase" section.
* Update/fix DIP0006 Table of Contents
* Update "Current LLMQ type" table to contain all relevant parameters
* Add description of new LLMQ merkle roots to DIP4
* Rename deletedMNcount -> deletedMNsCount
* Add quorumType to parameter description and DIP6 P2P messages
* Remove quorumMinMemberAge from parameter description
This was never implemented
* Rename badVotesThreshold -> quorumDkgBadVotesThreshold
* Update testing LLMQ type to LLMQ_5_60
* Better describe active LLMQs in DIP6 and DIP7
* Bump CbTx version
* Handle review comments
* 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
* Update bls_signature_scheme.md with BLS12-381-reversed
* Update DIP3/DIP4 to use BLS operator keys
* Update DIP5 to use BLS keys for user keys
Also add the "Size" column to all serialization specs to align with other DIPs.
* Update BLS primitives serialization size in DIP6/7
* DIP3 - Correct PubKeyOperator type
* DIP4 - Correct PubKeyOperator type
* Remove trailing e from integere
I propose to change DIP3 in a way that splits funds handling and DMN registration.
Pros:
1. no need to move collaterals;
2. no need to update HW wallet firmware to support.
Cons:
1. the logic is going to be slightly more complicated;
2. the process of MN registration is going to be split between using HW wallet and Core;
3. `ProRegTx` payload size is going to be slightly higher (+32 bytes).
This change proposes to remove non-alphanumeric characters for the first mainnet release of DIP 0005 Blockchain Users, with the option to add them in later.
The reasoning is based on securing future compatibility when integrating with global name based systems outside of the Dash protocol:
- Periods (.) are compatible with email but will complicate DNS records using BU names, for example user evan.duffield.xyz.tld requires 2 subdomains for a single BU, whereas evanduffield.xyz.tld requires 1 subdomain per BU
- Underscores (_) are not compatible with DNS. They could be translated to hyphens (-) but this would complicate the implementation and is not a clean solution
- We could implement hyphens (-) but this would break email compatibility
- Adding these non-alphanumeric characters at mainnet release is making assumptions for the benefit of aesthetics (more choice of characters for users) - but I do not believe this outways the benefits to securing future compatibility with global name based systems we probably want to integrate with in future
- It is a lot easier to not launch with these special characters and play safe, and add them in later (via HF) if required. Obviously, BU names are digital assets with a value themselves, so we cannot remove characters later (which would invalidate existing names and essentially seize/liquidate that property)
