25 |
--------------------------------------------------------------------------------
/_includes/authorlist.html:
--------------------------------------------------------------------------------
1 | {%- assign authors=include.authors|split:"," -%}
2 | {%- for author in authors -%}
3 | {%- if author contains "<" -%}
4 | {%- assign authorparts=author|split:"<" -%}
5 | "}}">{{authorparts[0]|strip}}
6 | {%- elsif author contains "(@" -%}
7 | {%- assign authorparts=author|split:"(@" -%}
8 | {{authorparts[0]|strip}}
9 | {%- else -%}
10 | {{author}}
11 | {%- endif -%}
12 | {% if forloop.last == false %}, {% endif %}
13 | {%- endfor -%}
14 |
--------------------------------------------------------------------------------
/Gemfile:
--------------------------------------------------------------------------------
1 | source "https://rubygems.org"
2 |
3 | # Hello! This is where you manage which Jekyll version is used to run.
4 | # When you want to use a different version, change it below, save the
5 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
6 | #
7 | # bundle exec jekyll serve
8 | #
9 |
10 | # This is the default theme for new Jekyll sites. You may change this to anything you like.
11 | gem "minima", "~> 2.0"
12 |
13 | # If you have any plugins, put them here!
14 | group :jekyll_plugins do
15 | gem "jekyll-feed", "~> 0.11"
16 | gem "github-pages", "206"
17 | end
18 |
19 | # Windows does not include zoneinfo files, so bundle the tzinfo-data gem
20 | gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]
21 |
22 | # Performance-booster for watching directories on Windows
23 | gem "wdm", "~> 0.1.0" if Gem.win_platform?
24 | gem "html-proofer", '>=3.3.1'
25 |
--------------------------------------------------------------------------------
/qips/QIP010.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 10
3 | title: Change Quanta emission to 2
4 | author: Ottslayer (@Ottslayer)
5 | layer: core
6 | status: "draft/abandoned"
7 | comments_uri: https://github.com/theQRL/qips/pull/21
8 | type: emission
9 | created: 2019-11-09
10 | ---
11 |
12 | ## Abstract
13 |
14 | Emission is currently close to 6 Quanta per minute and will be exponentially reduced to 0 in aproximately 200 years. Reducing the emission to 2 Quanta per minute will reduce the availability of Quanta.
15 |
16 | ## Motivation
17 |
18 | Lower emission rate will most likely increase demand of Quanta, the price, and people who are willing to point their mining rigs to qrl which will enlarge the network.
19 |
20 | ## Specification
21 |
22 | To be determined by team if accepted.
23 |
24 | ## Backward compatibility
25 |
26 | Changing the emission is a hard fork upgrade?
27 |
28 | ## Implementation
29 |
30 | To be determined by team if accepted.
--------------------------------------------------------------------------------
/_includes/qiptable.html:
--------------------------------------------------------------------------------
1 |
10 | {% for status in site.data.statuses %}
11 | {% assign qips = include.qips | where:"status",status|sort:"qip" %}
12 | {% assign count = qips|size %}
13 | {% if count > 0 %}
14 |
27 | {% endif %}
28 | {% endfor %}
29 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | title: QRL Improvement Proposals
2 | description: >-
3 | QRL Improvement Proposals (QIPs) repository handles proposals
4 | to improve the QRL core protocol and other layers that effects
5 | most or all QRL technical implementations.
6 | url: "https://www.theqrl.org"
7 | twitter_username: qrledger
8 | github_username: theQRL
9 | repository: theqrl/qips
10 | header_pages:
11 | - all.html
12 | twitter:
13 | card: summary
14 | username: qrledger
15 | highlighter: rouge
16 | markdown: kramdown
17 | theme: minima
18 | kramdown:
19 | parse_block_html: false
20 | auto_ids: true
21 | auto_id_stripping: true
22 | syntax_highlighter: rouge
23 | permalink: /:slug
24 | defaults:
25 | -
26 | scope:
27 | path: "qips"
28 | values:
29 | layout: "qip"
30 | exclude:
31 | - .github
32 | - Gemfile
33 | - Gemfile.lock
34 | - node_modules
35 | - vendor/bundle/
36 | - vendor/cache/
37 | - vendor/gems/
38 | - vendor/ruby/
39 | - qip-specification.md
40 | - qip-template.md
41 | - qip-workflow.md
42 | - README.md
43 |
--------------------------------------------------------------------------------
/qips/QIP013.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 13
3 | title: "Protection from fishing(?) nodes"
4 | author: Cooper7777 (@cooper7777)
5 | layer: na
6 | comments_uri: https://github.com/theQRL/qips/pull/26
7 | status: "draft/incomplete"
8 | created: 2020-06-01
9 | ---
10 |
11 | ## Abstract
12 |
13 | Users are allowed to choose any node in wallet settings. We don't no if each node is trusted or not, and it can be critical due to OTS index.
14 |
15 | ## Motivation and implementation possibilities
16 |
17 | In order to counteract malicious nodes that may receive someone's transactions and not propagate it to the network, we should store all output transactions history in all wallets, whenever it is mobile wallet, or desktop wallet, instead of receiving last used OTS from blockchain.
18 |
19 | Even lightweight wallets for other blockchains do so(for example Metamask for Ethereum).
20 |
21 | In wallets that can't store data(web wallet) we should caution users every time they unblock their wallets, that they should check transaction history of current wallet, and move funds to another wallet if they don't find in blockchain any transaction that they made.
22 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2018 The Quantum Resistant Ledger
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/qips/QIP006.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 6
3 | title: "Implement dPoW"
4 | layer: core
5 | author: Machin (@bidulemachin)
6 | comments_summary:
7 | comments_uri: https://github.com/theQRL/qips/pull/10
8 | status: "draft/incomplete"
9 | created: 2019-03-27
10 | ---
11 |
12 | ## Abstract
13 |
14 | Purpose of this QIP is to implement a dPoW mechanisme to strengthen QRL protection against attacks like 51%
15 |
16 | ## Motivation
17 |
18 | Because security is the first concern of QRL project, we have to consider all solutions that can improve its security.
19 |
20 | Thanks to hash power provider like NiceHash, we know that it is possible to perform a 51% attack against QRL blockchain for little amount of money.
21 |
22 | A test done by a community member (curefrankosflue) demonstrates this figures : "20 MH/s @ 0.0090 BTC /(MH/s x day) means 0.0075 BTC/hour, which turns out the cost of a 5 hour attack at 20mhs to be at 0.0375 BTC or 150 $"
23 |
24 | Some projects like Komodo solves this issues by using BTC blockchain to benefit from its hash power.
25 |
26 | Also, some project like VeriBlock propose to better secure alternative crypto asset networks using Bitcoin blockchain (concept of proof-of-proof (PoP))
27 |
28 | QRL should evaluate the level of protection afforded by lowering the reorg limit versus a DPOW solution that would be based on BTC hashpower.
29 |
30 | ## Specification
31 |
32 | Lorum ipsum
33 |
34 |
35 | ## Backward compatibility
36 |
37 | Lorum ipsum
38 |
39 |
40 | ## Implementation
41 |
42 | Lorum ipsum
43 |
--------------------------------------------------------------------------------
/qips/QIP015.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 15
3 | title: "Implement privacy feature for QRL"
4 | author: sync (@successor1)
5 | layer: meta
6 | status: "draft/incomplete"
7 | comments_uri: https://github.com/theQRL/qips/pull/31
8 | comments_summary_uri: ~
9 | created: 2021-05-09
10 | ---
11 |
12 | # Implement privacy feature
13 |
14 | ## Abstract
15 |
16 | QRL currently has no privacy features. This means ***every transaction can be followed through the blockchain***. The identity of the original wallet holder can be revealed this way by for example tracing the transaction back to KYC required exchanges.
17 |
18 | ## Motivation
19 |
20 | QRL adding privacy features will most likely attract a new target audience: privacy conscious people.
21 |
22 | ***Edward Snowden: "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say"***
23 |
24 | ## Implementation
25 |
26 | Privacy as an optional feature is no privacy at all so would need to be the default transaction type.
27 |
28 | See Monero's privacy features, such as:
29 |
30 | - Stealth addresses
31 | - Untracable transaction outputs
32 | - Confidential transactions (hide amount sent)
33 | - TOR/onion (or similar) network layer.
34 |
35 | ## Considerations
36 |
37 | This will most likely require a hardfork.
38 |
39 | Bittrex doesn't allow privacy coins, this means that QRL will be removed from Bittrex. We have to find alternative exchanges.
40 |
41 | Other exchange(s):
42 | Binance, Tradeogre, Uniswap or other decentralized exchanges.
43 |
--------------------------------------------------------------------------------
/qips/QIP009.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 9
3 | title: Change mining algorithm to randomX
4 | author: doctor-gonzo
5 | layer: core
6 | status: "proposal/accepted/completed"
7 | comments_uri: https://github.com/theQRL/qips/pull/20
8 | comments_summary_uri:
9 | Created: 2019-11-7
10 | ---
11 |
12 | ## Abstract
13 |
14 | [RandomX](https://github.com/tevador/RandomX) is a proof-of-work algorithm that aims to achieve longer-term ASIC resistance than the current CryptoNight-based tweaks.
15 | It will be used in the Monero blockchain after their next upgrade. It has been [audited](https://ostif.org/four-audits-of-randomx-for-monero-and-arweave-have-been-completed-results/) by the people (x41) who audited the QRL cryptography.
16 |
17 | From [reddit thread](https://www.reddit.com/r/Monero/comments/aovypq/randomx_asic_resistant_pow_community_feedback/) announcing it: "RandomX is a proof-of-work (PoW) algorithm that is optimized for general-purpose CPUs. RandomX uses random code execution (hence the name) together with several memory-hard techniques to minimize the efficiency advantage of specialized hardware."
18 |
19 | ## Motivation
20 |
21 | A mining algorithm change would go a long way towards re-vitalizing the QRL mining community. Many people built rigs or pointed rigs at QRL initially but have seen their returns crushed by ASICs and FPGAs, and therefore no longer participate. The long term health of the network will be increased if mining rewards are being paid to community members, and it will create another way for people to get involved in QRL.
22 |
23 | ## Specification
24 |
25 | To be determined by team if accepted.
26 |
27 | ## Backward compatibility
28 |
29 | Changing the mining algorithm is a hard fork upgrade.
30 |
31 | ## Implementation
32 |
33 | To be determined by team if accepted.
34 |
--------------------------------------------------------------------------------
/assets/css/style.scss:
--------------------------------------------------------------------------------
1 | ---
2 | # Only the main Sass file needs front matter (the dashes are enough)
3 | ---
4 |
5 | @import 'minima';
6 |
7 | .page-content {
8 | a.anchor-link {
9 | width: 16px;
10 | height: 16px;
11 | display: inline-block;
12 | margin-left: -22px;
13 | &:hover {
14 | background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' class='anchor-link-icon' viewBox='0 0 16 16' version='1.1' width='16' height='16' aria-hidden='true'%3E%3Cpath fill-rule='evenodd' d='M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z'%3E%3C/path%3E%3C/svg%3E");
15 | }
16 | }
17 | }
18 |
19 | main.page-content {
20 | div.wrapper {
21 | max-width: unset;
22 | }
23 | }
24 |
25 | .status {
26 | border-radius: 6px;
27 | line-height: 18px;
28 | overflow: hidden;
29 | padding: 12px;
30 | display: inline-block;
31 | margin-bottom: 15px;
32 | }
33 |
34 | .draft {
35 | @extend .status;
36 | background-color: #fffbea;
37 | border: solid 1px #f1c40f;
38 | }
39 |
40 | .review {
41 | @extend .status;
42 | background-color: #f0f7fb;
43 | border: solid 1px #3498db;
44 | }
45 |
46 | .lastcall {
47 | @extend .status;
48 | background-color: #e7f6f0;
49 | border: solid 1px #27ae60;
50 | }
51 |
52 | .stagnant {
53 | @extend .status;
54 | background-color: #ffdead;
55 | border: solid 1px #ff6700;
56 | }
57 |
58 | .withdrawn {
59 | @extend .status;
60 | background-color: #f9e7e5;
61 | border: solid 1px #c0392b;
62 | }
63 |
64 | .qiptable {
65 | .qipnum {
66 | width: 50px;
67 | }
68 | }
--------------------------------------------------------------------------------
/qips/QIP005.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 5
3 | title: Extending message transaction functionality
4 | author: Peter Waterland (@surg0r)
5 | layer: core
6 | status: "draft/incomplete"
7 | comments_uri: https://github.com/theQRL/qips/pull/8
8 | created: 2019-02-21
9 | ---
10 |
11 |
12 | ## Abstract
13 |
14 | Message transactions sent on the QRL blockchain network allow broadcast and decentralised storage of 80 bytes of data per transaction for purposes such as notarisation and data stamping. This minor QIP extends the message transaction format to include an optional payee/receipt address.
15 |
16 | ## Motivation
17 |
18 | It would be useful to direct message transactions to a specific destination address rather than simply writing them into the chain in a broadcast manner.
19 |
20 | Potential benefits include:
21 | 1) allowing message-based interaction between user and smart contract addresses
22 | 2) enabling user addresses to exchange message data directly between themselves
23 |
24 | For example a smart contract may be scripted to perform certain actions based upon specific message transaction input from a given address. Or a smart contract address associated with a user address could alert a user address with a message transaction if certain thresholds are met (such as changes in balance) or to acknowledge receipt of a payment from a user address to a payee contract address.
25 |
26 | Adding a destination address also allows future consensus voting within the QRL network to be refined. (i.e. voting for a specific QIP proposal, contentious network decision or election of addresses to positions of authority within smart contract constructions such as multisignature contract wallets).
27 |
28 | ## Implementation
29 |
30 | Whilst a minor extension to the existing message transaction format this is not backwards compatible with existing versions of qrl-node and therefore requires a hard fork.
31 |
--------------------------------------------------------------------------------
/_includes/head.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | {% if page.layout == "qip" %}
6 | QIP-{{ page.qip }}: {{ page.title | escape }}
7 |
8 |
12 |
16 |
17 | {% else %}
18 | {{ page.title | escape }} | {{site.title}}
19 |
23 |
24 |
25 |
26 | {% endif %}
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
43 |
44 | {%- feed_meta -%}
45 |
46 |
47 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # QRL improvement proposals (QIPs)
2 |
3 | The QRL Improvement Proposals (QIPs) repository handles proposals to improve the QRL core protocol and other layers that effects most or all QRL technical implementations.
4 |
5 | It covers the following layers
6 |
7 | - **core**: Improvements requiring a consensus fork.
8 | - **networking**: Improvements around network components
9 | - **security**: Improvements and upgrades to to the security.
10 | - **meta**: QIP process, governance, and structure.
11 |
12 | For proposals that don't effect most or all of QRL technical implementations, such as client implementations (eg. wallets, explorers), as well as non-technical related proposals (design, advocacy), but where consensus is required, there is a QRL Enhancement Program (QEP) being developed over at The QRL Contributors modeled after QIPs.
13 |
14 | # Governance & Structure
15 |
16 | Anyone can and is encouraged to submit a QRL Improvement Proposal (QIP) if they have an idea to improve the QRL core protocol.
17 |
18 | Once an idea is put by the community, the QRL Improvement Proposal (QIP) starts and remains as a draft until it's to the point where the authors are happy with it (such as where it will likely gain widest acceptance) and which is sufficiently specified to the satisfaction of the QIP custodians Jack Matier (@jackalyst), James Gordon (@fr1t2), and JP Lomas (@jplomas).
19 |
20 | At this point the QIP enters a proposal, and parameters are set for on-chain governance. More can be read in our '[qip-workflow](qip-workflow.md)' document.
21 |
22 | # How to submit
23 |
24 | Please see the [qip-workflow](qip-workflow.md) for a detailed submission process guide.
25 |
26 | Other important documents include:
27 |
28 | - [qips/reference](qips/reference.md): Reference QIP to duplicate and build off of.
29 | - [qip-template](qip-template.md): Includes a kitchen sink of everything that can be included in a QIP.
30 | - [qip-specification](qip-specification.md): Expands on the specification of each section.
31 |
32 | # Special thanks
33 |
34 | QRL Improvement Proposals (QIP) have been heavily influenced by [Ethereum Improvement Proposals (EIPs)](https://github.com/ethereum/EIPs/) and [Bitcoin Improvement Proposals (BIPs)](https://github.com/bitcoin/bips), with some modification in areas to fit the needs of the QRL project.
35 |
36 | A special thanks goes out to Ethereum and Bitcoin for being so seminal to blockchain and decentralized governance.
--------------------------------------------------------------------------------
/qips/QIP011.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 11
3 | title: "Denomination ideograms for Quanta and Shor as svg, webfonts"
4 | layer: brand
5 | author: Jack Matier (@jackalyst)
6 | comments_uri: https://github.com/theQRL/qips/pull/23
7 | comments_summary:
8 | status: "draft/withdrawn"
9 | layer: na
10 | created: 2020-01-16
11 | superceded_by:
12 | ---
13 |
14 | ## Motivation
15 |
16 | Ideograms are useful in conveying an idea or concept which is independent of any particular language.
17 |
18 | Doing so as an SVG allows for usage in a wide variety of mediums. Further creating a webfont hosted either locally or from popular third-party services has the added advantage of being able to be easy to implement.
19 |
20 | ## Specification
21 |
22 | The reference asset format should follow the Scalable Vector Graphic (SVG v1.1) standard which has a wide userbase and can be incorporated into a font and hosted either locally and/or on third-party services.
23 |
24 | This will be then compiled into the Web Open Font Format (woff) and Web Open Font Format 2 (woff2) standards.
25 |
26 | In order to qualify whether a prospective ideogram is symbolic as a currency, it should be tested against a diverse background of people from different regions with a positive result being that it's recognised as a currency.
27 |
28 | For the test, every positive result can be recorded as 1 and negative as 0. These results would then be compiled and an average established with the final resulting floating point value between a 0 and 1. An overall result that's greater than a value that's to be determined through discussions will signify whether the ideogram works to represent a currency in a series of short-listing rounds.
29 |
30 | ## Backward compatibility
31 |
32 | Both SVG 1.1 and Woff/Woff2 are open standards and offer wide support.
33 |
34 | ## Implementation
35 |
36 | 1. Quanta and Shor ideograms should be uploaded as a gist in the SVG format and linked to in a comment as part of the comments-uri thread of this QIP.
37 |
38 | 2. A diverse team will be elected to do an initial round of testing as specified in the specification portion of this QIP with a process where the submitter of the ideogram wont be identified.
39 |
40 | 3. Ideograms would be short-listed and tested against a wider audience less familiar with QRL and short-listed further.
41 |
42 | 4. A vote would take place to identify favourite currency ideograms
43 |
44 | 5. The selected ideograms would be cleaned up and made into respective woff and woff2 files.
--------------------------------------------------------------------------------
/qips/QIP001.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 1
3 | title: Migrate to Cryptonote v8
4 | author: Andrew Chiw
5 | layer: core
6 | status: "proposal/rejected"
7 | comments_uri: https://github.com/theQRL/qips/pull/2
8 | comments_summary_uri:
9 | created: 2018-10-30
10 | ---
11 |
12 | ## Abstract
13 |
14 | This QIP explores the feasibility of migrating to Cryptonote v8, and continuing to change the POW algorithm just like Monero.
15 |
16 | ## Motivation
17 |
18 | ASIC resistance is the most obvious reason, so that GPU miners can participate, thus making mining truly decentralized, instead of the select few who can afford to buy and setup ASICs.
19 |
20 | ## Implementation at library level
21 |
22 | Currently, qryptonight implements Cryptonote v7 via hooking into a few important files in xmr-stak, and putting a SWIG wrapper around it.
23 |
24 | Since xmr-stak 2.5.0 (931bd5fef17f908afc62836ae7b6ea087d1441ca, unify cpu cryptonight implementations), the internals have changed enough that qryptonight needs to be modified, and xmr-stak needs to be forked.
25 |
26 | Once this is done, having qryptonight use Cryptonote v8 is as simple as changing this line:
27 |
28 | ```
29 | Cryptonight_hash<1>::template hash(input.data(), input.size(), output.data(), &context);
30 | ```
31 |
32 | to this:
33 | ```
34 | Cryptonight_hash<1>::template hash(input.data(), input.size(), output.data(), &context);
35 | ```
36 |
37 | ## Implementation at node level
38 | This breaks the following tests:
39 |
40 | ```
41 | TestChainManagerReal.test_add_block
42 | TestChainManagerReal.test_multi_output_transaction_add_block
43 | TestChainManagerReal.test_simple_add_block
44 | TestBlockHeader.test_hash
45 | TestBlockHeader.test_hash_nonce
46 | TestQryptonight.test_hash
47 | TestQryptonight.test_hash2
48 | TestQryptonight.test_hash3
49 | ```
50 |
51 | From these tests it appears that the code does not depend too much on the POW algorithm, which is good news.
52 |
53 | ## Backwards compatibility
54 | Both algorithms will need to be present in qryptonight, and qryptonight must be modified to accept an extra argument that specifies which hashing algorithm should be used.
55 |
56 | The best place for the node to decide which hashing algorithm should be used is `BlockHeader`, specifically `generate_headerhash()` and `validate()`.
57 |
58 | The exact block height from which Cryptonote v8 should be used instead of v7 should be defined in `config.dev`.
59 |
60 | ## Considerations
61 | This work will have to be duplicated in go-qrl.
62 |
63 | Should Monero's future POW algorithms require a different amount of memory than Cryptonight v7/v8, further modifications need to be made to qryptonight and xmr-stak in `cryptonote_alloc_ctx()`.
64 |
--------------------------------------------------------------------------------
/qips/reference.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 0
3 | title: Reference
4 | author: Jack Matier (@jackalyst), James Gordon (@fr1t2)
5 | layer: meta
6 | status: "draft/reference"
7 | comments_uri: ~
8 | created: 2021-08-13
9 | modified: 2021-08-30
10 | ---
11 |
12 | ## Overview (remove)
13 |
14 | This is the suggested template for new QIPs which is modeled closely after the Bitcoin Improvement Proposals (BIPs) and Ethereum Improvement Proposals (EIPs).
15 |
16 | - For the full QIP specification, see [specification document]({{site.github.repository_url}}/blob/master/qip-specification.md) page.
17 | - To get started, see the [workflow document]({{site.github.repository_url}}/blob/master/qip-workflow.md).
18 |
19 | See the repos [README.md]({{site.github.repository_url}}/blob/master/README.md) for more information on the structure.
20 |
21 | ## Abstract
22 |
23 | A short (~200 word) description of the technical issue being addressed. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
24 |
25 | ## Motivation
26 |
27 | The motivation section should describe the "why" of this QIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the QRL ecosystem? What use cases does this QIP address?
28 |
29 | ## Specification
30 |
31 | The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current QRL platforms to integrate.
32 |
33 | ## Rationale
34 |
35 | The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
36 |
37 | ## Backward compatibility
38 |
39 | All QIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
40 |
41 | ## Reference Implementation
42 |
43 | An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. If the implementation is too large to reasonably be included inline, then consider adding it as one or more files under the qips directory named after your padded qip number (ie QIP001/) or by including a link to your repository in this section.
44 |
45 | ## Security Considerations
46 |
47 | All QIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. QIP submissions missing the "Security Considerations" section will be rejected. An QIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
--------------------------------------------------------------------------------
/_includes/social.html:
--------------------------------------------------------------------------------
1 |
15 |
--------------------------------------------------------------------------------
/qips/QIP014.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 14
3 | title: Non-fungible token (NFT) support
4 | layer: core
5 | author: Peter Waterland (@surg0r)
6 | comments_summary_uri:
7 | comments_uri: https://github.com/theQRL/qips/pull/28
8 | status: "draft/incomplete"
9 | created: 2021-03-27
10 | ---
11 |
12 |
13 | ## Abstract
14 |
15 | It would be valuable to extend token support on qrl-mainnet to include non-fungible token (NFT) creation and transfer capabilities.
16 |
17 | ## Motivation and implementation possibilities
18 |
19 | A NFT is typically a token with a single transferrable owner address and a distribution of one. NFTs may be part of a class, but generally each NFT instance of the class has a single controlling owner address. The data payload of the contract address acts as a digital pointer to an URL, hash value for an IPFS lookup etc of which the NFT has some form of digital ownership rights.
20 |
21 | NFT's are now in common usage on smart contract platforms such as ethereum, linking decentralised blockchain ownership to digital collectibles such as art, app-based items, gaming artifacts or even real world physical objects. NFT's are possibly entering the mainstream as a useful decentralised application for public blockchain networks.
22 |
23 | Extending NFT support onto QRL would allow users and third parties to build functionality into QRL immediately. An example would be a digital game requiring a public blockchain with NFT support for in-game items and artifacts. Low or zero fees, minimal network congestion and ultra secure transactions with longevity guaranteed would potentially make QRL a popular network for such third party projects.
24 |
25 | ## Consensus changes required
26 |
27 | QRL mainnet currently supports quantum resistant token (QRT) native support. This is achieved through two transaction subtypes `TOKEN_CREATE_TX` and `TOKEN_TRANSFER_TX`. During token contract instantiation certain data fields are supplied including: `owner address`, `token name (30 bytes)`, `token symbol (10 bytes)`, `decimals`, `number` and a list of QRL addresses and initial token balances.
28 |
29 | To enable NFT support it is suggested for `TOKEN_CREATE_TX` to be used with custom data supplied including encoding. The explorer and wallet layer would be modified to identify such custom tokens created as NFTs, presenting them differently to existing standard QRT functionality.
30 |
31 | This can be achieved easily by forcing NFT creation to apply only to new token instantiations in which token supply is 1, parsing the `token symbol` for an encoding `4` byte sequence `0x00FF00FF`, with the remaining `6` bytes concatenated with the `30` bytes in `token name` to create a `36` byte data field. This is sufficient for `4` further encoding bytes and a `32` byte cryptographic hash digest.
32 |
33 | Projects building into the QRL may then register encoding byte sequences to enable qrl-explorer and wallet labelling / visibility.
34 |
35 | Changes to enable support for this NFT may include: additional qrl-explorer logic and presentation of NFT versus current token transaction support, a new wallet function to allow a user to easily create an NFT within the GUI, modification of the qrl-cli or existing API to simplify NFT token creation, parsing and transfer, whilst adhering to the new NFT specification.
36 |
37 | The above changes only occur in the data payload of existing token transaction subtypes and therefore are backwards compatible. They do not break existing consensus and are therefore soft fork changes requiring no base layer alteration at all.
38 |
39 |
40 | ## Recommendation and attribution
41 |
42 | It is recommended to implement the above changes as soon as is practical following team and community discussion. Precise encoding parameters require discussion. Attribution to JP Lomas for the initial idea.
43 |
44 |
45 |
46 |
47 |
--------------------------------------------------------------------------------
/qips/QIP007.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 7
3 | title: Support Tokenization of Securities
4 | author: IMac (@IMac318)
5 | layer: core
6 | status: "draft/incomplete"
7 | comments-cummary:
8 | comments-uri: https://github.com/theQRL/qips/pull/15
9 | created: 2019-04-19
10 | ---
11 |
12 | # Support Tokenization of Securities
13 |
14 | ## Abstract
15 |
16 | One of the biggest potential use cases of blockchains in the future is the tokenization of existing securities to be bought and sold by valid parties. Being the only existing blockchain that is quantum resistant from genesis and adding the functionality of smart contracts, QRL is in a unique spot to capitalize on this opportunity. The QRL team should evaluate whether the functionality of the smart contracts that are currently in progress can support the tokenization of securities on the QRL blockchain. If that is not the case, the team should consider adding additional functionality that allows for such tokenization.
17 |
18 |
19 | ## Motivation
20 |
21 | The current usefulness of blockchain is highly debated, and there is much conversation about what "killer app" will eventually drive adoption. One current use of blockchain is speculation, and it is very attractive in this area due to the ability to buy fractions of a coin or token. In contrast, many traditional assets require the purchase of an integer number of the asset. For example, it is difficult to obtain a fraction of a stock or real estate property.
22 |
23 | Traditional assets, including stocks, real estate, and derivatives, are estimated to be worth a combined amount of over one quadrillion dollars (source: https://money.visualcapitalist.com/worlds-money-markets-one-visualization-2017/). There is incentive to tokenize existing securites and offer new securities on the blockchain, including the "removal of middlemen... to lower fees, faster deal execution, free market exposure, larger potential investor base, automated service functions, and lack of financial institution manipulation" (source: https://medium.com/@apompliano/the-official-guide-to-tokenized-securities-44e8342bb24f). In addition, security tokenization would raise the credibility of blockchain in the eyes of many traditional investors, as there would be "real value" in the underlying assets.
24 |
25 | As of now, QRL is the only existing blockchain that is quantum resistance from genesis and implementing smart-contract functionality. Such functionality is necessary for the tokenization of securities, as the buying and selling of securities is restricted by KYC/AML laws. Given QRL's unmatched quantum resistance and future-oriented security, the QRL blockchain could be a very attractive platform for security tokenization.
26 |
27 | The purpose of this QIP is to urge the QRL team to evaluate whether or not the in-progress smart-contract functionality can support the creation and exchange of security tokens. QRL smart contracts are limited in functionality compared to ETH (where security token standards are currently being created), so the author does not automatically assume that such functionality currently exists. If it does not, consideration should be given to add such functionality.
28 |
29 |
30 | ## Specification
31 |
32 | QRL already has the ability to create tokens, but to be compliant with regulations, it must be possible to restrict transactions of security tokens between wallets if the sending and receiving wallets do not meet certain criteria (example: https://thesecuritytokenstandard.org/); therefore, it would have to be possible to make these checks before a token transaction is admitted to the blockchain.
33 |
34 |
35 | ## Implementation
36 |
37 | Several entities are working on platforms for tokenization of securities. Polymath, Harbor, Securrency, and tZero are prominent examples. It may be worth reaching out to them for evaluation and implementation.
38 |
--------------------------------------------------------------------------------
/qips/QIP016.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 16
3 | title: "Reduce emissions rate of the network"
4 | author: 4d5a (@4d5af)
5 | layer: meta
6 | status: "proposal/accepted/completed"
7 | comments_uri: https://github.com/theQRL/qips/pull/32
8 | comments_summary_uri: ~
9 | created: 2021-08-14
10 | modified: 2022-03-24
11 | ---
12 |
13 | # Reduce emissions rate of the network
14 |
15 | ## Abstract
16 |
17 | To reduce the emissions rate of the network by a multiplication factor of 0.4x which has been determined through both network and transaction analysis, and with regards to the future economic incentives of Proof-of-Stake.
18 |
19 | ## Motivation
20 |
21 | Network and transaction analysis has revealed that the majority of the network hashrate is made up of \~90% for profit miners, with 60% of that from auto-switching bots.
22 |
23 | This increases the sell pressure on exchanges compared to our demand, causing the value to drop, and as most of the network consists of for-profit miners, the hashrate drops along with it. Due to a negative value velocity, confidence also decreases, creating a negative market cycle with decreased demand, and importantly, a decrease in the overall hashrate.
24 |
25 | With the consideration of general interest to help with the longevity of the network through developer interest; Marketcap, its value direction, and velocity, commands attention in a mostly proportional manner. Coins with a higher marketcap, and with a positive velocity, assuming everything else is equal, will achieve more attention than one with a lower marketcap, with a negative value velocity. A positive value velocity can not only have a compounding effect, but also improve with development efforts by increasing interest.
26 |
27 | Additionally, QRL has emitted over 10m tokens in its first 3 years of the project, accounting \~25% of its total slated emissions over a 200 year period. It's possible to defer higher emissions for when Proof-of-Stake comes into play, in creating its value proposition, rather than distributing that further towards other projects through the effect of for-profit miners.
28 |
29 | ## Specification
30 |
31 | At present, QRL follows a per block exponential decay emission curve with a long tail.
32 |
33 | The proposal is an emission reduction by a multiplication factor of 0.4x of the current per block coinbase reward. This per block coinbase reward, rather than changing on a per block basis, would remain flat.
34 |
35 | The target total population will remain at 105m, with a period to be determined depending on the coinbase reward of the hardfork blockheight, but is estimated to be 28 years.
36 |
37 | Upon the release of Proof-of-Stake, this emission is to be further evaluated with consideration to its technical and economic factors.
38 |
39 | ### Considerations
40 |
41 | Time is a consideration. Through discussions, it's estimated that preparation and testing should take two weeks, though the exchange availability to manage a node update can vary depending other obligations, priorities, and staffing situations (such as through seasonal vacations & holidays).
42 |
43 | ## Backward compatibility
44 |
45 | N/A
46 |
47 | ## Implementation
48 |
49 | A relatively simple hard fork is required.
50 |
51 | ## Security considerations
52 |
53 | Dependent on how miners behave, it will reduce the hashrate, which reduces the cost of a 51% attack. However, this attack is negligible for a motivated adversary. This is primarily mitigated by a 300 block reorg limit as well as static and dynamic network protections from both the development team and the user community.
54 |
55 | Another possible consideration would be through the reduction in support from mining pools should there be enough contention with the hard fork. This may in turn reduce the diversity of hashrate, due to miners loyalty to certain mining pools.
--------------------------------------------------------------------------------
/qip-template.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip:
3 | title: (required)
4 | author: Author (platorm/username), Author> (required, can be plural, format defined in order of preference)
5 | layer: (required)
6 | status: (required)
7 | comments_uri:
8 | comments_summary_uri:
9 | created:
10 | updated:
11 | requires: (optional)
12 | replaces: (optional)
13 | superseded_by: (optional)
14 | ---
15 |
16 | This is the suggested template for new QIPs which is modeled closely after the Bitcoin Improvement Proposals (BIPs) and Ethereum Improvement Proposals (EIPs).
17 |
18 | - To get started, see the [workflow document](qip-workflow.md).
19 | - For the full specification, see [specification](qip-specification.md) page.
20 |
21 | See the repos [README.md](README.md) for more information on the structure.
22 |
23 | ## Abstract
24 |
25 | A short (~200 word) description of the technical issue being addressed. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
26 |
27 | ## Motivation
28 |
29 | The motivation section should describe the "why" of this QIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the QRL ecosystem? What use cases does this QIP address?
30 |
31 | ## Specification
32 |
33 | The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current QRL platforms to integrate.
34 |
35 | ## Rationale
36 |
37 | The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
38 |
39 | ## Backward compatibility
40 |
41 | All QIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The QIP must explain how the author proposes to deal with these incompatibilities. QIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
42 |
43 | ## Reference Implementation
44 |
45 | An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. If the implementation is too large to reasonably be included inline, then consider adding it as one or more files as under the qips directory named after your padded qip number (ie QIP001/) or including a link to your repository.
46 |
47 | ## Security Considerations
48 |
49 | All QIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. QIP submissions missing the "Security Considerations" section will be rejected. An QIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
--------------------------------------------------------------------------------
/qips/QIP008.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 8
3 | title: Ephemeral message format proposal
4 | layer: core
5 | author: Peter Waterland (@surg0r), Kaushal Singh (@cyyber)
6 | comments_uri: https://github.com/theQRL/qips/pull/17
7 | status: "draft/incomplete"
8 | created: 2019-04-24
9 | ---
10 |
11 | ## Abstract
12 |
13 | To extend functionality of the QRL beyond the ledger an off-chain network messaging system known as 'ephemeral' is proposed. These lifespan-limited internode broadcast messages may be relayed and stored optionally by agreeable qrl-nodes.
14 |
15 | A simple initial format with some DDOS protection is suggested, allowing custom implementations from users or applications wishing to interact with the QRL ledger/network.
16 |
17 |
18 | ## Specification
19 |
20 | A suggested message format is:
21 |
22 | Ephemeral message | ID | PAYLOAD |TTL |BLOCKHASH | POW
23 | --- | --- | --- | --- | --- | ---
24 |
25 | The **ID** field is a 64 byte identifier. It may be accessed as a complete ID field or two 32 byte separate identifiers (ID0 and ID1). The ID is intended to be a unique nonce.
26 |
27 | The **payload** is the body of the message containing user data. The precise contents are left open but some example schemes will be suggested in a future QIP to enable powerful end-end encrypted data channels. Max field length = 8192 bytes.
28 |
29 | **TTL** is a 32 bit network expiry timestamp following unix time specification. This 'time to live' value is a timestamp upon which the network renders the message invalid and proceeds with deletion. Whilst messages are relayed across the network by agreeable nodes they are only held transiently until they expire - hence 'ephemeral'. Alternatively, this could be replaced with a blockheight?
30 |
31 | The first 4 bytes of a recent QRL **block-header hash** must be supplied as a rough message timestamp. The chance of a random 4 byte guess being successful is `allowed_ephemeral_message_blockdepth/2^32`. In combination with POW this prevents a determined attacker grinding out a huge number of messages over a long period of time which are then used to flood the network.
32 |
33 | **POW**. Any broadcast protocol is susceptible to spam and each message passed through the network will require a variable amount of 'work' to be performed and verified via a supplied pow hash prepended by a byte pow algorithm identifier. This adds a small amount of computation time to confirm message validity. Furthermore, the amount of work required is linked to the TTL expiry timestamp - the longer the shelf-life of the message, the greater work must be expended to attain validity. The pow is performed on a cryptographic hash digest of the message `(SHA2_256(ID+PAYLOAD+TTL+BLOCKHASH))`, with the resultant pow hash (and prepended byte) appended as the final field of the message.
34 |
35 |
36 |
37 | ## Implementation
38 |
39 | Activating ephemeral messaging requires minor changes to the qrl-node python and go implementations to relay and prioritise additional traffic. It is anticipated the vast majority of traffic will occur using open source public off-chain centralised message repositories.
40 |
41 | New qrl-node configuration parameters for:
42 |
43 | 1. ephemeral traffic relay flag (enable or disable)
44 | 1. ephemeral traffic storage flag (enable or disable)
45 | 1. maximum TTL timestamp from current timestamp accepted
46 | 1. valid ephemeral message block depth limit (integer value from current blockheight)
47 | 1. specific pow algorithm support flag
48 | 1. proof of work variables for each algorithm in specification
49 | - numerical value for minimum valid computed work per message prior to adjustment
50 | - numerical factor applied based upon TTL timestamp
51 |
52 | Furthermore, to allow encrypted data channels via ephemeral messages across the network, lattice tx featuring embedded Dilithium and Kyber pk's must be activated. This requires a hard fork upgrade to all network nodes. Specific end-end data channel cryptographic implementations will be discussed in future QIPs.
53 |
--------------------------------------------------------------------------------
/qips/QIP017.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 17
3 | title: "A Proposed v3 Wallet Format & Use of scrypt/AES-256-GCM"
4 | author: "JP Lomas (@jplomas)"
5 | layer: "interface"
6 | status: "proposal/open"
7 | comments_uri: "https://github.com/theQRL/qips/pull/37"
8 | comments_summary_uri: "~"
9 | created: "2021-12-17"
10 | ---
11 |
12 | # A Proposed v3 Wallet Format & Use of scrypt/AES-256-GCM
13 |
14 | ## Abstract
15 |
16 | This QIP proposes a 'version 3' wallet file format with enhancements to the encryption to reduce the risk of funds loss when an encrypted wallet file is publicly exposed.
17 |
18 | ## Motivation
19 |
20 | Encrypted wallet files exfiltrated from a target system are at risk of (a) brute force/dictionary attacks and (b) theoretical man-in-the-middle / tampering attacks.
21 |
22 | The risk can be reduced by using scrypt in conjunction with the existing aes256 encryption, and by swapped the aes256 mode from CTR to GCM.
23 |
24 | Additionally, there has been no formal specification of the QRL wallet format.
25 |
26 | ## Specification
27 |
28 | ### 1. Wallet format
29 |
30 | Extraneous public data which can be derived from other elements, for example tree height/PK, is excluded.
31 |
32 | Plain ASCII text file containing valid JSON detailing the version number, whether the elements are encrypted and with an array of 1 or more wallets in the format:
33 |
34 | ``` json
35 | {
36 | "version": 3,
37 | "encrypted": ,
38 | "addresses": [
39 | {
40 | "address": "",
41 | "hexseed": "",
42 | "mnemonic": ""
43 | },
44 | {
45 | "address": "",
46 | "hexseed": "",
47 | "mnemonic": ""
48 | },
49 | ...
50 | ]
51 | }
52 | ```
53 |
54 | Retention of unencrypted wallet file support is retained for use where the environment is secured by another means (e.g. encrypted volume) but is not recommended for standard use cases.
55 |
56 | ### 2. Encryption
57 |
58 | Within the _addresses_ array, the elements are encrypted using scrypt and aes-256-gcm as per the reference implementation and presented as a string with elements separated by a colon, formatted as:
59 |
60 | ```
61 | [IV hexstring]:[authentication tag hexstring]:[salt hexstring]:[encrypted data:hexstring]
62 | ```
63 |
64 | Eg:
65 |
66 | The plain text address:
67 |
68 | ```
69 | Q010600beb663d164df6a4d984155df86ba2a938d5a57a364033a39e34ae47ec642d8f3ee900e08
70 | ```
71 |
72 | When encrypted with AES-256-GCM with scrypt, the password ```My Secret Password``` and formatted as per above results in the following:
73 |
74 | ```
75 | 87b448183d0924b7fcb4e5643097400f:79652dc221037d2a78198019defce625:bc36990b72b6a4e2127f57fab00bf03601bdd2ea7045a80ddbd883dee63a0a71:ef416f256fc4ab5a6da0a421e8cb26b7f81c99a4fea2f22384f679a93a03bf4f51bef137c2d9b6f9119bee9556f889c5923ae9e0dc05ec960c04a642b1c6fbd6f6bc87624bd1572e73f8324f227502
76 | ```
77 |
78 | ## Backward compatibility
79 |
80 | Existing wallet implementations should retain backwards compatibility for legacy wallet formats. It is preferable to offer the user the option to upgrade to a version 3 wallet file.
81 |
82 | ## Reference Implementation
83 |
84 | A worked example (with code peer review by @leongb - thank you Leon) is at [https://runkit.com/jplomas/aes-256-gcm-with-scrypt/6.0.0](https://runkit.com/jplomas/aes-256-gcm-with-scrypt/6.0.0)
85 |
86 | Additionally some work has been commenced in implementing this in [@theqrl/wallet-helpers NPM module](https://github.com/theQRL/wallet-helpers/blob/master/src/v3wallet.js)
87 |
88 | A Python reference implementation is underway.
89 |
90 | ## Security Considerations
91 |
92 | Implementation recommended by x41-D-sec; rationale, cryptography and reference code peer reviewed by @leongb. Both the existing and this use of AES256 is considered post-quantum secure.
93 |
94 | Clearly the most secure means of protecting funds are that wallet files remain solely in the possession of their owners. This implementation reduces to some degree the risk of loss should this principle be compromised.
95 |
--------------------------------------------------------------------------------
/_layouts/qip.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | ---
4 |
5 |
56 | {% comment %}
57 | Article schema specification:
58 | https://schema.org/TechArticle
59 | {% endcomment %}
60 |
77 |
--------------------------------------------------------------------------------
/qips/QIP004.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 4
3 | title: Multi-Signature Wallet
4 | author: Kaushal Singh (@cyyber), Peter Waterland (@surg0r)
5 | layer: core
6 | status: "proposal/accepted/completed"
7 | comments_uri: https://github.com/theQRL/qips/pull/7
8 | comments_summary_uri: ~
9 | created: 2019-02-11
10 | ---
11 |
12 | ## Abstract
13 |
14 | Purpose of this QIP is to initiate development of multi signature wallet support on QRL network, based on finalised specification.
15 |
16 | ## Motivation
17 |
18 | Currently, QRL doesn't have support to multi-signature wallet address. So to execute any transaction only a proof of signature is required either by the main address or the slave address. Thus the introduction of multi-signature wallet address will fill this gap and will allow multiple authorities to have a transaction from a single wallet once the consent has been established.
19 |
20 | ## Specification
21 |
22 | In order to create and spend from a multisig wallet new transaction types are required. multisig_create and multisig_spend are the two new transaction types which will be introducted to support multisig wallet.
23 |
24 | multisig_create transaction type will be used to create a new multi sig wallet. It will have following input fields other than common transaction fields.
25 |
26 | 1. **Signatories** - List of qrl addresses, will act as signatory. There could be maximum 100 signatories and minimum 2.
27 | 2. **Weights** - List of integer values which will be denoting the weightage of each signatory.
28 | 3. **Threshold** - Threshold value is an integer value and any successful multisig transaction must have sum of weights greater than or equals to threshold value.
29 |
30 | multisig_spend transaction type is to move funds from a multisig wallet to another address which could be a normal qrl address or another multisig address. It will have following input fields other than common transaction fields.
31 |
32 | 1. **Multi Sig Address** - Multi Sig Address from which amount needs to be spent
33 | 2. **Address To** - Address which will receive the amount. This could be a normal QRL address or another multi sig address.
34 | 3. **Amount** - Amount to be spent
35 | 4. **Shared Key** - Shared key refers to the multi sig spend transaction hash. In case a shared key is provided, this transaction, will not require other details such as multi sig address, address to and amount as these details will be derived from the shared key.
36 |
37 | multisig_spend transaction will only be executed once minimum required threshold is met.
38 |
39 | ### Address format of a multisig address
40 |
41 | MultiSig addresses will be derived by following to maintain the standard QRL address format.
42 |
43 | **Prefix 'Q'** + **3 bytes descriptor** + **hash of (descriptor + txn hash)** + **last 4 bytes of the hash of (descriptor + previous hash)**
44 |
45 | **Descriptor Format** (https://docs.theqrl.org/developers/address/)
46 |
47 | | **Name** | **Bits** | **Count** | **Description** |
48 | | --- | --- | --- | --- |
49 | | HF | 0 .. 3 | 4 | SHA2-256 |
50 | | SIG | 4 .. 7 | 4 | Signature Scheme |
51 | | P1 | 8 .. 11 | 4 | Height |
52 | | P2 | 12 .. 15 | 4 | Address Format |
53 | | P3 | 16 .. 23 | 8 | Not used |
54 |
55 | - **HF** will be 1 for SHA2-256.
56 | - **SIG** will be 1 to represent multisig addresses.
57 | - **P1** will be 0 as the multi sig addresses itself doesn't have any height.
58 | - **P2** will be 0.
59 | - **P3** will be 0 as it is unused.
60 |
61 |
62 | So a multi sig address generated by multisig_create transaction having transaction hash 5a4c37ef7e5b7cc5a2a58ab730269ed8f4cbf08a005dc3508e31465535e1d6bb will be derived by following
63 |
64 | **Prefix** = 'Q'
65 |
66 | **Descriptor** = 110000
67 |
68 | **SHA2_256(Descriptor+Txn hash)** = 3674370317e1cac0ca13f896ab5b6472a261ba0d2b2961d3adba1b9060f6e8f7
69 |
70 | **SHA2_256(Descriptor+Prev Hash)** = fe2088fb
71 |
72 | **MultiSig Address** = Q1100003674370317e1cac0ca13f896ab5b6472a261ba0d2b2961d3adba1b9060f6e8f7fe2088fb
73 |
74 | ## Backward Compatibility
75 |
76 | The introduction of multisig wallet on QRL Node will need a hard fork, as two new transaction will be introduced in it. Therefore, the changes will not be backward compatible.
77 |
78 | ## Implementation
79 |
80 | Implementation of Multisig wallet is in progress.
81 |
82 |
83 |
84 |
--------------------------------------------------------------------------------
/qips/QIP012.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 12
3 | title: "Implementing transaction replay attack protection"
4 | author: Peter Waterland (@surg0r)
5 | layer: "core/security"
6 | status: "draft/incomplete"
7 | comments_uri:
8 | comments_summary_uri: https://github.com/theQRL/qips/pull/25
9 | created: 2020-05-30
10 | ---
11 |
12 | ## Abstract
13 |
14 | Whilst currently an extremely low risk vulnerability, replay attack protection should ideally be considered and implemented in the next hard fork to completely mitigate this attack vector.
15 |
16 | ## Motivation
17 |
18 | Typically a replay attack involves a transaction from one instance of a blockchain network being maliciously retransmitted by an attacker onto another separate network (generally a persisting network fork). With a simple transaction sending funds from Alice to Bob on chain A, a replay attack of the transaction would also move funds from Alice to Bob's account on chain B (without permission of Alice).
19 |
20 | This is currently a potential risk between QRL mainnet and the public QRL testnet. However, it is not recommended to use the same QRL XMSS account on both testnet and mainnet due to the potential risk of OTS re-use. Furthermore, testnet balances are worthless and are not the same as the ledger balances on mainnet meaning there is no value in attempting a replay attack between QRL mainnet and testnet.
21 |
22 | QRL will fork from proof-of-work to proof-of-stake in the future (and it is possible other forks of QRL mainnet may be created) with the risk of both sides of the fork persisting and being potentially susceptible to replay attack.
23 |
24 | ## Implementation possibilities
25 |
26 | To mitigate a replay attack it is necessary to somehow associate a transaction with a specific instance of the network such that it will not be found to be valid on the forked network. This requires the addition of some network or chain specific data to be signed into the transaction.
27 |
28 | Examples include:
29 |
30 | **network ID** - A unique numerical identifier, nodes on each network would find any transaction not using the correct identifier invalid. An example would be `'0000' = devnet`, `'0001' = testnet`, `'0002' = mainnet`, `'0003' = mainnet pos`, or simply stamping the genesis block hash into each transaction. Note this does not prevent replay attacks in later forks of a network using the same identifier.
31 |
32 | **block hash** - each block in the chain has a unique hash value obtained from aggregating and hashing the block header (and incorporating the previous block header hash). Thus, stamping each transaction with the a recent 32 byte block header hash is a simple way of preventing a replay attack. The significant downside is this requires the transaction signer to know something about the current QRL chain which could be a problem for offline transaction signing. Another consideration is that choosing the most recent block could lead to a transaction entering the mempool only for the block to be discarded in a mini-fork and then the transaction become invalid. It would make sense then to choose a block hash at a given depth from the tip of the chain or specific epoch blocks at 1k intervals (or something suitable).
33 |
34 | **tx hash** - it is possible for each transaction to optionally include the txhash of the last transaction from the account. It would therefore force an attacker to replay all historical transactions since the fork to achieve success - if there are no transactions since the fork then this would not be effective at preventing a replay attack.
35 |
36 | ## Recommendation
37 |
38 | I would suggest adding a network ID to the transaction protocol at the next major release. This network ID would actually not need to be included in the transaction payload and so would not grow the transaction size. Pseudocode to demonstrate this functionality would be:
39 | `XMSS_SIGN(hash(existing+transaction+constituents+network ID))`
40 |
41 | After each subsequent hard fork the network ID would be updated to make transactions continually incompatible between hard forked networks..
42 |
43 | ## Consensus changes required
44 |
45 | Any changes to the base transaction format and construction are not backwards compatible with existing versions of qrl-node and this is therefore a hard fork upgrade to be introduced at the OCAML fork later this year.
46 |
47 | ## Thanks / Attribution
48 |
49 | Although this subject has previously been discussed at length by the core development team, I would like to thank Red4SEC for reminding us of this future attack vector.
50 |
--------------------------------------------------------------------------------
/_includes/toc.html:
--------------------------------------------------------------------------------
1 | {% capture tocWorkspace %}
2 | {% comment %}
3 | Version 1.0.10
4 | https://github.com/allejo/jekyll-toc
5 |
6 | "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
7 |
8 | Usage:
9 | {% include toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
10 |
11 | Parameters:
12 | * html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
13 |
14 | Optional Parameters:
15 | * sanitize (bool) : false - when set to true, the headers will be stripped of any HTML in the TOC
16 | * class (string) : '' - a CSS class assigned to the TOC
17 | * id (string) : '' - an ID to assigned to the TOC
18 | * h_min (int) : 1 - the minimum TOC header level to use; any header lower than this value will be ignored
19 | * h_max (int) : 6 - the maximum TOC header level to use; any header greater than this value will be ignored
20 | * ordered (bool) : false - when set to true, an ordered list will be outputted instead of an unordered list
21 | * item_class (string) : '' - add custom class(es) for each list item; has support for '%level%' placeholder, which is the current heading level
22 | * baseurl (string) : '' - add a base url to the TOC links for when your TOC is on another page than the actual content
23 | * anchor_class (string) : '' - add custom class(es) for each anchor element
24 |
25 | Output:
26 | An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
27 | generate the table of contents and will NOT output the markdown given to it
28 | {% endcomment %}
29 |
30 | {% capture my_toc %}{% endcapture %}
31 | {% assign orderedList = include.ordered | default: false %}
32 | {% assign minHeader = include.h_min | default: 1 %}
33 | {% assign maxHeader = include.h_max | default: 6 %}
34 | {% assign nodes = include.html | split: ' maxHeader %}
47 | {% continue %}
48 | {% endif %}
49 |
50 | {% if firstHeader %}
51 | {% assign firstHeader = false %}
52 | {% assign minHeader = headerLevel %}
53 | {% endif %}
54 |
55 | {% assign indentAmount = headerLevel | minus: minHeader %}
56 | {% assign _workspace = node | split: '' | first }}>{% endcapture %}
71 | {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
72 |
73 | {% assign space = '' %}
74 | {% for i in (1..indentAmount) %}
75 | {% assign space = space | prepend: ' ' %}
76 | {% endfor %}
77 |
78 | {% if include.item_class and include.item_class != blank %}
79 | {% capture listItemClass %}{:.{{ include.item_class | replace: '%level%', headerLevel }}}{% endcapture %}
80 | {% endif %}
81 |
82 | {% capture heading_body %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture %}
83 | {% capture my_toc %}{{ my_toc }}
84 | {{ space }}{{ listModifier }} {{ listItemClass }} [{{ heading_body | replace: "|", "\|" }}]({% if include.baseurl %}{{ include.baseurl }}{% endif %}#{{ html_id }}){% if include.anchor_class %}{:.{{ include.anchor_class }}}{% endif %}{% endcapture %}
85 | {% endfor %}
86 |
87 | {% if include.class and include.class != blank %}
88 | {% capture my_toc %}{:.{{ include.class }}}
89 | {{ my_toc | lstrip }}{% endcapture %}
90 | {% endif %}
91 |
92 | {% if include.id %}
93 | {% capture my_toc %}{: #{{ include.id }}}
94 | {{ my_toc | lstrip }}{% endcapture %}
95 | {% endif %}
96 | {% endcapture %}{% assign tocWorkspace = '' %}{{ my_toc | markdownify | strip }}
97 |
--------------------------------------------------------------------------------
/qips/QIP002.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 2
3 | title: "A standard message encoding format to indicate encoded data in MessageTransaction transactions"
4 | author: Scott Donald (@scottdonaldau)
5 | layer: core
6 | status: "proposal/accepted/completed"
7 | comments_uri: https://github.com/theQRL/qips/pull/4
8 | comments_summary_uri:
9 | Created: 2018-11-03
10 | Updated: 2018-11-12
11 | ---
12 |
13 | ## Abstract
14 |
15 | The QRL network supports arbitrary messages up to 80 bytes in length to be stored on chain through the [MessageTransaction](https://github.com/theQRL/QRL/blob/v1.1.6/src/qrl/core/txs/MessageTransaction.py#L8) transaction subtype.
16 |
17 | There is the capability for second layer clients to read and interpret the data contained within these message transactions, and format interfaces accordingly. This can be seen with the currently implemented `Document Notarisation` transaction type found on both the [QRL Wallet](https://github.com/theQRL/qrl-wallet/blob/v1.0.4/imports/ui/pages/tools/notarise/start.js#L71) and [QRL Explorer](https://github.com/theQRL/block-explorer/blob/2b11358f31415812bd374fb572c6ab9c8a06e9ad/imports/ui/components/tx/tx.html#L124) applications, and further implemented in the [explorer-helpers](https://github.com/theQRL/explorer-helpers/blob/v0.0.7/index.js#L356) repository.
18 |
19 |
20 | ## Motivation
21 |
22 | This QIP aims to create a new base layer for a standard message encoding format such that other usecases have a framework to build within - for example the [coinvote](https://github.com/theQRL/qips/pull/2#issuecomment-434810654) proposal mentioned by @surg0r.
23 |
24 | ## Specification
25 |
26 | The following will describe the base requirements to indicate a message contains encoded data, and provide further context on earlier usage as has been implemented in the `Document Notarisation` transaction type.
27 |
28 | There are a total of 80 bytes available in a MessageTransaction transaction that are usable. For the purposes of describing the format in this document, we will represent all data as HEX strings. It is worth noting however that the data is later converted to binary bytes for storage by a QRL node.
29 |
30 | To indicate a message is an encoded message, the first two bytes are reserved for the following HEX string:
31 |
32 | `0F0F`
33 |
34 | The subsequent two bytes should indicate a unique encoded message transaction type. Each proposal to the community for a new encoded message type will be allocated a unique HEX string for these bytes for client implementations.
35 |
36 | Eg: `0001`, `AA01` etc.
37 |
38 | The remaining 76 bytes contain any data relevant to the encoded message, and should be proposed to the community through a QIP.
39 |
40 | If this QIP is accepted, a record of accepted message transaction sub type and their respective QIP should be kept updated on [docs.theqrl.org](https://github.com/theQRL/docs.theqrl.org) such that client implementations have the technical detail available to implement with ease. A Github repository will be setup on https://github.com/theQRL/standard-message-encoding to allow community pull requests into this standard encoding format.
41 |
42 |
43 | #### Document Notarisation Specification
44 |
45 | The following describes the structure of the `Document Notarisation` message transaction sub type for historical purposes. There are approximately 25 transactions from early stages of the network that utilise this format. It is optional to implement for display purposes.
46 |
47 | First 2 Bytes: `AFAF` - Indicates encoded message.
48 | Subsequent Half Byte: `A` - Indicates this is a document notarisation message transaction sub type.
49 | Subsequent Half Byte: `1`, `2`, or `3` indicating which hash function has been used to notarise the document as per below:
50 |
51 | `1` - SHA1 (Now deprecated in user interfaces when notarising a document)
52 | `2` - SHA256
53 | `3` - MD5 (Now deprecated in user interfaces when notarising a document)
54 |
55 | The remaining 77 bytes are reserved for both the hash of the document, and a variable amount of free form text depending which hash function was use. For each hash function above, the following describes the remaining 77 bytes utilisation.
56 |
57 | `1` - SHA1 - Subsequent 20 bytes store the SHA1 hash, with the remaining 57 bytes available for free form text.
58 | `2` - SHA256 - Subsequent 32 bytes store the SHA256 hash, with the remaining 45 bytes available for free form text.
59 | `3` - MD5 - Subsequent 16 bytes store the SHA1 hash, with the remaining 61 bytes available for free form text.
60 |
61 | ## Implementation
62 |
63 | No immediate implementation work is required for this QIP as it simply states a standard for encoding messages using the QRL networks `MessageTransaction` transaction type.
64 |
65 | Eventual work will be required in any client implementations that wish to adhere to the standard encoding format, such as the public [QRL Wallet](https://wallet.theqrl.org/) or [Block Explorer](https://explorer.theqrl.org/)
66 |
67 |
--------------------------------------------------------------------------------
/_includes/anchor_headings.html:
--------------------------------------------------------------------------------
1 | {% capture headingsWorkspace %}
2 | {% comment %}
3 | Version 1.0.5
4 | https://github.com/allejo/jekyll-anchor-headings
5 |
6 | "Be the pull request you wish to see in the world." ~Ben Balter
7 |
8 | Usage:
9 | {% include anchor_headings.html html=content %}
10 |
11 | Parameters:
12 | * html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
13 |
14 | Optional Parameters:
15 | * beforeHeading (bool) : false - Set to true if the anchor should be placed _before_ the heading's content
16 | * anchorAttrs (string) : '' - Any custom HTML attributes that will be added to the `` tag; you may NOT use `href`, `class` or `title`
17 | * anchorBody (string) : '' - The content that will be placed inside the anchor; the `%heading%` placeholder is available
18 | * anchorClass (string) : '' - The class(es) that will be used for each anchor. Separate multiple classes with a space
19 | * anchorTitle (string) : '' - The `title` attribute that will be used for anchors
20 | * h_min (int) : 1 - The minimum header level to build an anchor for; any header lower than this value will be ignored
21 | * h_max (int) : 6 - The maximum header level to build an anchor for; any header greater than this value will be ignored
22 | * bodyPrefix (string) : '' - Anything that should be inserted inside of the heading tag _before_ its anchor and content
23 | * bodySuffix (string) : '' - Anything that should be inserted inside of the heading tag _after_ its anchor and content
24 |
25 | Output:
26 | The original HTML with the addition of anchors inside of all of the h1-h6 headings.
27 | {% endcomment %}
28 |
29 | {% assign minHeader = include.h_min | default: 1 %}
30 | {% assign maxHeader = include.h_max | default: 6 %}
31 | {% assign beforeHeading = include.beforeHeading %}
32 | {% assign nodes = include.html | split: '
47 | {% if headerLevel == 0 %}
48 |
49 | {% assign firstChunk = node | split: '>' | first %}
50 |
51 |
52 | {% unless firstChunk contains '<' %}
53 | {% capture node %}' | first }}>{% endcapture %}
66 | {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
67 |
68 |
69 | {% capture anchor %}{% endcapture %}
70 |
71 | {% if html_id and headerLevel >= minHeader and headerLevel <= maxHeader %}
72 | {% capture anchor %}href="#{{ html_id }}"{% endcapture %}
73 |
74 | {% if include.anchorClass %}
75 | {% capture anchor %}{{ anchor }} class="{{ include.anchorClass }}"{% endcapture %}
76 | {% endif %}
77 |
78 | {% if include.anchorTitle %}
79 | {% capture anchor %}{{ anchor }} title="{{ include.anchorTitle | replace: '%heading%', header }}"{% endcapture %}
80 | {% endif %}
81 |
82 | {% if include.anchorAttrs %}
83 | {% capture anchor %}{{ anchor }} {{ include.anchorAttrs }}{% endcapture %}
84 | {% endif %}
85 |
86 | {% capture anchor %}{{ include.anchorBody | replace: '%heading%', header | default: '' }}{% endcapture %}
87 |
88 |
89 | {% if beforeHeading %}
90 | {% capture anchor %}{{ anchor }} {% endcapture %}
91 | {% else %}
92 | {% capture anchor %} {{ anchor }}{% endcapture %}
93 | {% endif %}
94 | {% endif %}
95 |
96 | {% capture new_heading %}
97 |
2 |
3 | - [1. QIP](#1-qip)
4 | - [2. Title](#2-title)
5 | - [3. Status](#3-status)
6 | - [3.1. Drafts](#31-drafts)
7 | - [3.1.1. Incomplete (Open)](#311-incomplete-open)
8 | - [3.1.2. Abandoned](#312-abandoned)
9 | - [3.1.3. Deferred](#313-deferred)
10 | - [3.1.4. Withdrawn](#314-withdrawn)
11 | - [3.1.5. Rejected](#315-rejected)
12 | - [3.2. Proposals](#32-proposals)
13 | - [3.2.1. Open](#321-open)
14 | - [3.2.2. Under review](#322-under-review)
15 | - [3.2.3. Accepted](#323-accepted)
16 | - [3.2.4. Deferred](#324-deferred)
17 | - [3.2.5. Rejected](#325-rejected)
18 | - [4. Author](#4-author)
19 | - [5. Layer](#5-layer)
20 | - [6. Comments URI](#6-comments-uri)
21 | - [7. Comments URI Summary](#7-comments-uri-summary)
22 | - [8. Created](#8-created)
23 | - [9. Modified](#9-modified)
24 | - [10. Requires](#10-requires)
25 | - [11. Replaces](#11-replaces)
26 | - [12. Superseded By](#12-superseded-by)
27 |
28 | # 1. QIP
29 |
30 | Initially left blank and is assigned after the PR is submitted with the numerical ID of the *pull request*.
31 |
32 | Having the QIP ID reflect the pull request allows for easier tracking and avoids QIP ID collisions.
33 |
34 | # 2. Title
35 |
36 | The title of the QIP that describes the rest of the content.
37 |
38 | # 3. Status
39 |
40 | Status hierarchy is concatenated into a string with forward slashes.
41 |
42 | 1. draft
43 | 1. incomplete
44 | 2. abandoned
45 | 3. deferred
46 | 4. withdrawn
47 | 5. rejected
48 | 2. proposal
49 | 1. open
50 | 2. review
51 | 3. accepted
52 | 1. available
53 | 2. in_development
54 | 3. awaiting_hardfork
55 | 4. completed
56 | 4. deferred
57 | 5. rejected
58 |
59 | ## 3.1. Drafts
60 |
61 | ### 3.1.1. Incomplete (Open)
62 |
63 | Once an idea is vetted through the community, it can be formed into an initial draft.
64 |
65 | Drafts open to feedback are marked as incomplete and remain this state until fleshed out and ready for the request for proposal.
66 |
67 | ### 3.1.2. Abandoned
68 |
69 | If there's been no movement on a draft, it may be marked as abandoned during QIP maintenance.
70 |
71 | ### 3.1.3. Deferred
72 |
73 | A draft may be deferred for any number of reasons, such as new information that's presented itself or is still developing which may make the draft unsuitable.
74 |
75 | ### 3.1.4. Withdrawn
76 |
77 | At any point during the draft process, it can be withdrawn.
78 |
79 | ### 3.1.5. Rejected
80 |
81 | It's possible a draft gets merged, but doesn't meet the criteria for a QIP. In this case it may be rejected.
82 |
83 | ## 3.2. Proposals
84 |
85 | Before a proposal can be opened, it must first complete the draft stage and go through a request for proposal.
86 |
87 | ### 3.2.1. Open
88 |
89 | Public comment is invited on open proposals. Once the proposal is sufficiently mature it will be moved by the QRL Foundation maintainers to the next stage.
90 |
91 | ### 3.2.2. Under review
92 |
93 | Proposals under discussion will be considered at the next QRL Developer meeting. Particularly complex or in depth QIPs may require a separate meeting or face-to-face discussions by the QRL development team prior to decisions being made as to the outcome. As this point they may be returned to 2.1 for further refinement.
94 |
95 | ### 3.2.3. Accepted
96 |
97 | Accepted proposals require development until such a point when they are released
98 | or they are ready for release at the next hard fork of the network. As such, an
99 | accepted QIP may be in one of four states:
100 |
101 | 1. Available (for a developer/team to take on engineering the QIP; avoiding
102 | duplication of effort)
103 | 2. In development
104 | 3. Awaiting hard fork
105 | 4. Completed
106 |
107 | ### 3.2.4. Deferred
108 |
109 | Deferred proposals have merit to the project but for operational reasons are held back from entering development. Deferred proposals may enter development at a later date or may move into a different category as the network matures.
110 |
111 | ### 3.2.5. Rejected
112 |
113 | Rejected proposals will not enter development without commencing the QIP process from the beginning and re-working the proposal.
114 |
115 | # 4. Author
116 |
117 | The author of the QIP.
118 |
119 | # 5. Layer
120 |
121 | QRL Improvement Proposals are for core improvements, either to the network or security layers. This can be described as `core`, `core/networking` or `core/security`. Most use `core`.
122 |
123 | There is also a `meta` layer, which is for fundamental changes to the QIP Process, including its governance and structure.
124 |
125 | # 6. Comments URI
126 |
127 | Full URI of the comments.
128 |
129 | # 7. Comments URI Summary
130 |
131 | Full URI of the comment summary made after the proposals review process.
132 |
133 | # 8. Created
134 |
135 | Date that the draft was created.
136 |
137 | # 9. Modified
138 |
139 | Date that the QIP was modified.
140 |
141 | # 10. Requires
142 |
143 | The QIPs that this QIP depends on, by UUID.
144 |
145 | # 11. Replaces
146 |
147 | The QIPs that this QIP replaces, by UUID.
148 |
149 | # 12. Superseded By
150 |
151 | The QIPs that supersedes this QIP, by UUID.
--------------------------------------------------------------------------------
/qips/QIP003.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 3
3 | title: Extended address functionality from master XMSS wallet
4 | author: Peter Waterland (@surg0r), Kaushal Singh (@cyyber)
5 | layer: core
6 | status: proposal/accepted/completed
7 | comments_summary_uri:
8 | comments_uri: https://github.com/theQRL/qips/pull/5
9 | created: 2018-11-04
10 | ---
11 |
12 | # Title
13 |
14 | Extended address functionality from master XMSS wallet
15 |
16 | ## abstract
17 |
18 | A suggested change to generate multiple deterministic addresses which may be signed using the XMSS tree associated with a user master address.
19 |
20 | ## Motivation
21 |
22 | Currently QRL uses XMSS to sign transactions and create a single re-usable address for users. Prior to signing a transaction the XMSS tree must be generated with varying computational cost dependent upon the signature capability of the address. Further signature capability may be added by signing slave XMSS trees to extend this scheme infinitely.
23 |
24 | However, it would be valuable for users to have access to more than one address from which to send or receive QRL, without the prospect of adding significant computation time and worsening the user experience by generating additional XMSS trees. Given QRL is a public blockchain, such a facility would improve privacy for those not wishing to unnecessarily reveal their primary address balance and transaction history to a payor. i.e. a payor may be given an address to send funds to other than the user master address. Additionally, the easy creation of deterministic addresses allows privacy extension through deliberate usage of one of more change addresses to obfuscate user holdings.
25 |
26 | ## Specification
27 |
28 | A 51 byte unique seed is used to generate a user wallet in the node or webwallet. The first three bytes are extended seed encoding with the following 48 bytes of random entropy providing the cryptographic seed used in PRF generation of the XMSS tree and subsequent master address.
29 |
30 | In addition to the master XMSS tree, the 48 byte random seed may, in a cryptographically secure fashion, be used to generate a deterministic sequence of pseudorandom 32 byte values. This sequence can be trivially generated computationally yet retain the appearance of uniform random output when revealed to an external observer. Furthermore, the seed may not be determined using any or all of the PRF sequence values.
31 |
32 | Example solution:
33 |
34 | `prf_output = SHAKE128(SHA_256(SHA_256(SHA_256(seed[:32] ^ SHA_256(seed[32:])))))`
35 |
36 | i.e. the first 32 bytes of the seed are xored with a hash of the last 16 bytes of the seed and the result is iteratively hashed three times then passed as input into SHAKE128, where output may be derived as a 256 bit pseudorandom deterministic number sequence.
37 |
38 |
39 | Existing address format:
40 |
41 | An existing standard address is created with the following format (pseudocode):
42 |
43 | `QRL_address = encoding_bytes + hash_function(xmss_pk)`
44 |
45 | where `encoding_bytes` includes the required hash function, signature scheme, xmss tree height etc
46 |
47 | where `xmss_pk = master_xmss_tree_merkle_root + xmss_public_seed`
48 |
49 | Suggested new extensible address creation:
50 |
51 | Assuming a PRF sequence, `prf[n]`, an additional address may be simply created like:
52 |
53 | `extended_address_n = encoding_bytes + hash_function(xmss_pk + prf[n])`
54 |
55 | In this way, with each new value in the `prf` sequence a resultant new address is created for use.
56 |
57 | Additionally, a user field such as the hash of a pin or seed phrase may be added to generate a different series of addresses.
58 |
59 | i.e. `extended_address_n = encoding_bytes + hash_function(xmss_pk + prf[n] + hash_of_user_generated_data)`
60 |
61 | For ease the address `encoding_bytes` must match the master address XMSS tree encoding to allow appropriate decoding during spend transaction processing.
62 |
63 |
64 | ## Change addresses
65 |
66 | QRL uses re-usable addresses. An example transaction may move part of the funds from address `a` to `b`. After such a standard transfer transaction an outside observer can see precisely what funds remain in the user controlled master address `a`.
67 | The addition of multiple deterministic addresses to a master address means that the following is now possible: all funds may move from `a` to `b`, `c` and perhaps `d`. The balance of `a` is now zero, and an outside observer will not know that some funds were moved to address `b` and that the user controlling `a` actually controls the addresses `c` and `d`.
68 |
69 | Whilst the effective final balances of the two users in the transfer transaction remain the same -- to an outside observer the precise movements and control of funds are obfuscated.
70 |
71 | ## Backwards compatibility
72 |
73 | Optional fields (`.extended_pk_address_prf` and `.extended_pk_address_user`) to be concatenated and hashed with pk must be added into the transaction logic in the base `Transaction` class. Minor state changes required to associate extended addresses with existing master address pk's following a spend transaction (to preserve OTS safety).
74 |
75 | Higher level changes required in terms of tracking, displaying balances and allowing spend functionality from within the webwallet. This latter point will require internal discussion.
76 |
77 |
78 |
79 |
80 |
81 |
--------------------------------------------------------------------------------
/Gemfile.lock:
--------------------------------------------------------------------------------
1 | GEM
2 | remote: https://rubygems.org/
3 | specs:
4 | activesupport (6.0.6.1)
5 | concurrent-ruby (~> 1.0, >= 1.0.2)
6 | i18n (>= 0.7, < 2)
7 | minitest (~> 5.1)
8 | tzinfo (~> 1.1)
9 | zeitwerk (~> 2.2, >= 2.2.2)
10 | addressable (2.8.4)
11 | public_suffix (>= 2.0.2, < 6.0)
12 | coffee-script (2.4.1)
13 | coffee-script-source
14 | execjs
15 | coffee-script-source (1.11.1)
16 | colorator (1.1.0)
17 | commonmarker (0.17.13)
18 | ruby-enum (~> 0.5)
19 | concurrent-ruby (1.2.2)
20 | dnsruby (1.70.0)
21 | simpleidn (~> 0.2.1)
22 | em-websocket (0.5.3)
23 | eventmachine (>= 0.12.9)
24 | http_parser.rb (~> 0)
25 | ethon (0.16.0)
26 | ffi (>= 1.15.0)
27 | eventmachine (1.2.7)
28 | execjs (2.8.1)
29 | faraday (2.7.9)
30 | faraday-net_http (>= 2.0, < 3.1)
31 | ruby2_keywords (>= 0.0.4)
32 | faraday-net_http (3.0.2)
33 | ffi (1.15.5)
34 | forwardable-extended (2.6.0)
35 | gemoji (3.0.1)
36 | github-pages (206)
37 | github-pages-health-check (= 1.16.1)
38 | jekyll (= 3.8.7)
39 | jekyll-avatar (= 0.7.0)
40 | jekyll-coffeescript (= 1.1.1)
41 | jekyll-commonmark-ghpages (= 0.1.6)
42 | jekyll-default-layout (= 0.1.4)
43 | jekyll-feed (= 0.13.0)
44 | jekyll-gist (= 1.5.0)
45 | jekyll-github-metadata (= 2.13.0)
46 | jekyll-mentions (= 1.5.1)
47 | jekyll-optional-front-matter (= 0.3.2)
48 | jekyll-paginate (= 1.1.0)
49 | jekyll-readme-index (= 0.3.0)
50 | jekyll-redirect-from (= 0.15.0)
51 | jekyll-relative-links (= 0.6.1)
52 | jekyll-remote-theme (= 0.4.1)
53 | jekyll-sass-converter (= 1.5.2)
54 | jekyll-seo-tag (= 2.6.1)
55 | jekyll-sitemap (= 1.4.0)
56 | jekyll-swiss (= 1.0.0)
57 | jekyll-theme-architect (= 0.1.1)
58 | jekyll-theme-cayman (= 0.1.1)
59 | jekyll-theme-dinky (= 0.1.1)
60 | jekyll-theme-hacker (= 0.1.1)
61 | jekyll-theme-leap-day (= 0.1.1)
62 | jekyll-theme-merlot (= 0.1.1)
63 | jekyll-theme-midnight (= 0.1.1)
64 | jekyll-theme-minimal (= 0.1.1)
65 | jekyll-theme-modernist (= 0.1.1)
66 | jekyll-theme-primer (= 0.5.4)
67 | jekyll-theme-slate (= 0.1.1)
68 | jekyll-theme-tactile (= 0.1.1)
69 | jekyll-theme-time-machine (= 0.1.1)
70 | jekyll-titles-from-headings (= 0.5.3)
71 | jemoji (= 0.11.1)
72 | kramdown (= 1.17.0)
73 | liquid (= 4.0.3)
74 | mercenary (~> 0.3)
75 | minima (= 2.5.1)
76 | nokogiri (>= 1.10.4, < 2.0)
77 | rouge (= 3.19.0)
78 | terminal-table (~> 1.4)
79 | github-pages-health-check (1.16.1)
80 | addressable (~> 2.3)
81 | dnsruby (~> 1.60)
82 | octokit (~> 4.0)
83 | public_suffix (~> 3.0)
84 | typhoeus (~> 1.3)
85 | html-pipeline (2.14.3)
86 | activesupport (>= 2)
87 | nokogiri (>= 1.4)
88 | html-proofer (4.4.3)
89 | addressable (~> 2.3)
90 | mercenary (~> 0.3)
91 | nokogiri (~> 1.13)
92 | parallel (~> 1.10)
93 | rainbow (~> 3.0)
94 | typhoeus (~> 1.3)
95 | yell (~> 2.0)
96 | zeitwerk (~> 2.5)
97 | http_parser.rb (0.8.0)
98 | i18n (0.9.5)
99 | concurrent-ruby (~> 1.0)
100 | jekyll (3.8.7)
101 | addressable (~> 2.4)
102 | colorator (~> 1.0)
103 | em-websocket (~> 0.5)
104 | i18n (~> 0.7)
105 | jekyll-sass-converter (~> 1.0)
106 | jekyll-watch (~> 2.0)
107 | kramdown (~> 1.14)
108 | liquid (~> 4.0)
109 | mercenary (~> 0.3.3)
110 | pathutil (~> 0.9)
111 | rouge (>= 1.7, < 4)
112 | safe_yaml (~> 1.0)
113 | jekyll-avatar (0.7.0)
114 | jekyll (>= 3.0, < 5.0)
115 | jekyll-coffeescript (1.1.1)
116 | coffee-script (~> 2.2)
117 | coffee-script-source (~> 1.11.1)
118 | jekyll-commonmark (1.3.1)
119 | commonmarker (~> 0.14)
120 | jekyll (>= 3.7, < 5.0)
121 | jekyll-commonmark-ghpages (0.1.6)
122 | commonmarker (~> 0.17.6)
123 | jekyll-commonmark (~> 1.2)
124 | rouge (>= 2.0, < 4.0)
125 | jekyll-default-layout (0.1.4)
126 | jekyll (~> 3.0)
127 | jekyll-feed (0.13.0)
128 | jekyll (>= 3.7, < 5.0)
129 | jekyll-gist (1.5.0)
130 | octokit (~> 4.2)
131 | jekyll-github-metadata (2.13.0)
132 | jekyll (>= 3.4, < 5.0)
133 | octokit (~> 4.0, != 4.4.0)
134 | jekyll-mentions (1.5.1)
135 | html-pipeline (~> 2.3)
136 | jekyll (>= 3.7, < 5.0)
137 | jekyll-optional-front-matter (0.3.2)
138 | jekyll (>= 3.0, < 5.0)
139 | jekyll-paginate (1.1.0)
140 | jekyll-readme-index (0.3.0)
141 | jekyll (>= 3.0, < 5.0)
142 | jekyll-redirect-from (0.15.0)
143 | jekyll (>= 3.3, < 5.0)
144 | jekyll-relative-links (0.6.1)
145 | jekyll (>= 3.3, < 5.0)
146 | jekyll-remote-theme (0.4.1)
147 | addressable (~> 2.0)
148 | jekyll (>= 3.5, < 5.0)
149 | rubyzip (>= 1.3.0)
150 | jekyll-sass-converter (1.5.2)
151 | sass (~> 3.4)
152 | jekyll-seo-tag (2.6.1)
153 | jekyll (>= 3.3, < 5.0)
154 | jekyll-sitemap (1.4.0)
155 | jekyll (>= 3.7, < 5.0)
156 | jekyll-swiss (1.0.0)
157 | jekyll-theme-architect (0.1.1)
158 | jekyll (~> 3.5)
159 | jekyll-seo-tag (~> 2.0)
160 | jekyll-theme-cayman (0.1.1)
161 | jekyll (~> 3.5)
162 | jekyll-seo-tag (~> 2.0)
163 | jekyll-theme-dinky (0.1.1)
164 | jekyll (~> 3.5)
165 | jekyll-seo-tag (~> 2.0)
166 | jekyll-theme-hacker (0.1.1)
167 | jekyll (~> 3.5)
168 | jekyll-seo-tag (~> 2.0)
169 | jekyll-theme-leap-day (0.1.1)
170 | jekyll (~> 3.5)
171 | jekyll-seo-tag (~> 2.0)
172 | jekyll-theme-merlot (0.1.1)
173 | jekyll (~> 3.5)
174 | jekyll-seo-tag (~> 2.0)
175 | jekyll-theme-midnight (0.1.1)
176 | jekyll (~> 3.5)
177 | jekyll-seo-tag (~> 2.0)
178 | jekyll-theme-minimal (0.1.1)
179 | jekyll (~> 3.5)
180 | jekyll-seo-tag (~> 2.0)
181 | jekyll-theme-modernist (0.1.1)
182 | jekyll (~> 3.5)
183 | jekyll-seo-tag (~> 2.0)
184 | jekyll-theme-primer (0.5.4)
185 | jekyll (> 3.5, < 5.0)
186 | jekyll-github-metadata (~> 2.9)
187 | jekyll-seo-tag (~> 2.0)
188 | jekyll-theme-slate (0.1.1)
189 | jekyll (~> 3.5)
190 | jekyll-seo-tag (~> 2.0)
191 | jekyll-theme-tactile (0.1.1)
192 | jekyll (~> 3.5)
193 | jekyll-seo-tag (~> 2.0)
194 | jekyll-theme-time-machine (0.1.1)
195 | jekyll (~> 3.5)
196 | jekyll-seo-tag (~> 2.0)
197 | jekyll-titles-from-headings (0.5.3)
198 | jekyll (>= 3.3, < 5.0)
199 | jekyll-watch (2.2.1)
200 | listen (~> 3.0)
201 | jemoji (0.11.1)
202 | gemoji (~> 3.0)
203 | html-pipeline (~> 2.2)
204 | jekyll (>= 3.0, < 5.0)
205 | kramdown (1.17.0)
206 | liquid (4.0.3)
207 | listen (3.8.0)
208 | rb-fsevent (~> 0.10, >= 0.10.3)
209 | rb-inotify (~> 0.9, >= 0.9.10)
210 | mercenary (0.3.6)
211 | minima (2.5.1)
212 | jekyll (>= 3.5, < 5.0)
213 | jekyll-feed (~> 0.9)
214 | jekyll-seo-tag (~> 2.1)
215 | minitest (5.18.1)
216 | nokogiri (1.15.2-x86_64-linux)
217 | racc (~> 1.4)
218 | octokit (4.25.1)
219 | faraday (>= 1, < 3)
220 | sawyer (~> 0.9)
221 | parallel (1.23.0)
222 | pathutil (0.16.2)
223 | forwardable-extended (~> 2.6)
224 | public_suffix (3.1.1)
225 | racc (1.7.1)
226 | rainbow (3.1.1)
227 | rb-fsevent (0.11.2)
228 | rb-inotify (0.10.1)
229 | ffi (~> 1.0)
230 | rouge (3.19.0)
231 | ruby-enum (0.9.0)
232 | i18n
233 | ruby2_keywords (0.0.5)
234 | rubyzip (2.3.2)
235 | safe_yaml (1.0.5)
236 | sass (3.7.4)
237 | sass-listen (~> 4.0.0)
238 | sass-listen (4.0.0)
239 | rb-fsevent (~> 0.9, >= 0.9.4)
240 | rb-inotify (~> 0.9, >= 0.9.7)
241 | sawyer (0.9.2)
242 | addressable (>= 2.3.5)
243 | faraday (>= 0.17.3, < 3)
244 | simpleidn (0.2.1)
245 | unf (~> 0.1.4)
246 | terminal-table (1.8.0)
247 | unicode-display_width (~> 1.1, >= 1.1.1)
248 | thread_safe (0.3.6)
249 | typhoeus (1.4.0)
250 | ethon (>= 0.9.0)
251 | tzinfo (1.2.11)
252 | thread_safe (~> 0.1)
253 | unf (0.1.4)
254 | unf_ext
255 | unf_ext (0.0.8.2)
256 | unicode-display_width (1.8.0)
257 | yell (2.2.2)
258 | zeitwerk (2.6.8)
259 |
260 | PLATFORMS
261 | x86_64-linux
262 |
263 | DEPENDENCIES
264 | github-pages (= 206)
265 | html-proofer (>= 3.3.1)
266 | jekyll-feed (~> 0.11)
267 | minima (~> 2.0)
268 | tzinfo-data
269 |
270 | BUNDLED WITH
271 | 2.4.15
272 |
--------------------------------------------------------------------------------
/qips/QIP018.md:
--------------------------------------------------------------------------------
1 | ---
2 | qip: 18
3 | title: Better format of wallet addresses
4 | author: Robert Pösel (@robyer)
5 | layer: core
6 | status: "draft/incomplete"
7 | comments_uri: https://github.com/theQRL/qips/pull/44/
8 | created: 2023-07-06
9 | modified: 2023-07-28
10 | ---
11 |
12 | ## Abstract
13 |
14 | The QRL wallet addresses are currently represented as 79 characters strings. Such a long length has many disadvantages for the users. This QIP proposes use of more efficient encoding for address representation to make it shorter (64 characters) and user-friendly. It doesn't require any changes to the internal wallet format, therefore it doesn't affect internal APIs or security, and backwards compatibility is easily maintained.
15 |
16 | There is currently new upgrade to QRL in the works (codename Zond), and since the format of wallet addresses is already changed there, it makes sense to apply this proposal only to Zond and keep the current version of QRL intact. That way the wallet addresses will be changed only once - with release of Zond (ideally with the first testnet release).
17 |
18 | Note: Same encoding change should be applied to the Transaction IDs as well (separate QIP will be created for that).
19 |
20 | ## Motivation
21 |
22 | There are many inconveniences associated with long addresses, for example:
23 |
24 | - Visual inspection of the address
25 | - Before user confirms an outgoing transaction, they should carefully check that the recipient's address is correct. But the longer the address, the more annoying this activity is. As a result, user will probably check only the last few characters (which can be abused by bad actors generating addresses similar in this part), or just generally be less careful, increasing the probability of making a mistake.
26 | - Manual writing of the address
27 | - This has same problems as visual inspection, plus it's more annoying to manually type the address somewhere. It is not always possible to rely on QR codes and their scanning, and sometimes it is simply necessary to write it down manually - whether on a computer/phone, or perhaps on a paper.
28 | - Bloated user interface in applications
29 | - Wherever a long address is used, a large amount of space must be reserved for it in the user interface. Either to show an input field for destination address, or to show user's address to copy it, or having addresses in a list of transactions, in address book, in block explorer, etc.
30 | - It's even worse on HW wallets, as they have small display sizes and user often needs to go through multiple screens to read the whole address.
31 | - Less friendly when compared to addresses of other cryptocurrencies
32 | - When people want to receive donations from others, they place their crypto addresses on the web, on their profiles, in a forum signatures or similar places. Not only do longer addresses take up more space (see the previous point), but in addition, when they are compared or placed next to (for example) a BTC address (34 or 42 or 62 characters) or an ETH address (42 characters), QRL addresses (79 characters) look more technical and less friendly.
33 |
34 | It's important to note that length is not the only aspect that must be considered here, but it is the main problem of current format. The addresses should be shorter AND user-friendly.
35 |
36 | ## Specification
37 |
38 | QRL currently uses wallet addresses starting with `Q` followed by 78 hexadecimal characters (`0-9a-f` - which is basically **Base16** encoding).
39 |
40 | Proposed format is keeping the `q` (but lower case) followed by 63 characters in **z-base-32** encoding, which is more efficient and user-friendly (see the design considerations in the encoding specification).
41 |
42 | For example current QRL addresses (79 characters):
43 | 1. `Q01070050d31c7f123995f097bc98209e9231d663dc26e06085df55dc2f6afe3c2cd62e8271a6bd`
44 | 2. `Q0109003493192e08affe87d57e254df3e15be3b8709a40f07e0fc550de60696c2d0333f7070e1d`
45 |
46 | Would look like this (64 characters):
47 | 1. `qyrdoywgudt9trqci6nm53gbyu4jddiud5ouqyarf57k7am5k9a6n3itqoja4pxe`
48 | 2. `qyrroyprudrzytm96o9kzhjkp6xoiza7aqnprbhd6b9nibzuypfsn4y3u6hdoh8e`
49 |
50 | Note that with [QRL Zond](https://zond-docs.theqrl.org/wallet/node/node-cli-wallet) it seems that addresses will be shorter - still having `Q` followed by 42 hexadecimal characters (in the docs is not yet reflected the `Q` prefix).
51 |
52 | The planned Zond addresses (43 characters):
53 |
54 | 1. `Q1005003ea6ed78d597e7411a8ddbc2dffd8839e5`
55 | 2. `Q20bf1acdae054f4194e0c132b489e8f9099caf8c`
56 |
57 | Would look like this (34 characters):
58 | 1. `qnynoyxig7ihpmf98erpe5s6n596aoqxf`
59 | 2. `qrn9tiupqyi8wdf8yar3mjnxe9rr33mhc`
60 |
61 | To summary, change is only in the representation of the address (described in [official docs](https://docs.theqrl.org/developers/address/) for current version; for Zond they are not specified in the docs yet) to use (`q` + z-base-32 encoding) instead of (`Q` + base16 encoding).
62 |
63 | ### z-base-32
64 | The **[z-base-32](http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt)** was created in 2002 as **human-oriented base-32 encoding**.
65 |
66 | Citation from Wikipedia:
67 | > z-base-32 is a Base32 encoding designed by Zooko Wilcox-O'Hearn to be easier for human use and more compact. It includes 1, 8 and 9 but excludes l, v and 2. It also permutes the alphabet so that the easier characters are the ones that occur more frequently. It compactly encodes bitstrings whose length in bits is not a multiple of 8 and omits trailing padding characters. z-base-32 was used in the Mnet open source project, and is currently used in Phil Zimmermann's ZRTP protocol, and in the Tahoe-LAFS open source project.
68 |
69 | The full specification is [here](http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt).
70 |
71 | There are existing libraries for commonly used programming languages:
72 | - Go - https://pkg.go.dev/gopkg.in/corvus-ch/zbase32.v1
73 | - Python - https://pypi.org/project/python-zbase32/
74 | - JavaScript - https://www.npmjs.com/package/zbase32
75 | - and more...
76 |
77 | There are also online convertors, like [here](https://cryptii.com/pipes/base32) (you must switch the variant to z-base-32) or [here](https://www.dcode.fr/z-base-32-encoding).
78 |
79 | ## Rationale
80 |
81 | Representing binary data to be human-readable is a common task and there are many different approaches which were created during the years. Wikipedia has a [list of many of them](https://en.wikipedia.org/wiki/Binary-to-text_encoding). Creating new custom encoding format doesn't make much sense, which leaves us to one of the existing ones.
82 |
83 | For example original Bitcoin addresses used Base58 encoding ([original reasoning](https://en.wikipedia.org/wiki/Binary-to-text_encoding#/media/File:Original_source_code_bitcoin-version-0.1.0_file_base58.h.png)), but there is a problem that it uses both lower and upper-case characters, which is not user-friendly. And Bitcoin later switched to a fully-lowercase format anyway.
84 |
85 | Ethereum (and QRL currently) uses simply hexadecimal encoding, which is unnecessarily long and also less visually pleasant, as majority of the characters are numbers, which has full line height as capital letters and so they feel overwhelming and too technical. Additionally, QRL having first character (`Q`) uppercase while rest is lowercase is a bit inconvenient and inconsistent.
86 |
87 | Other Base32 encodings has been considered for its nice balance between its length and user-friendliness, but the [design decisions](http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt) of the z-base-32 regarding human errors makes most sense, and because it's fully lower-case, it makes it more visually pleasant (as opposite to fully upper-case Crockford's Base32 encoding).
88 |
89 | ## Backward compatibility
90 |
91 | The addresses are parsed to a binary format at entry/exit points to the system, which is then used internally in communication between services, APIs, etc. This QIP proposes only visual change to the user-facing representation of wallet addresses, the internal format is unchanged, which keeps the addresses internally compatible. Only the part which handles parsing/formatting of wallet addresses must be changed in order to accept and produce the new format.
92 |
93 | To provide the backward compatibility for user-facing forms, current apps/services should allow user to input addresses in both new and old formats. But the GUI should show only addresses in new format, everywhere. Additionally there could be created a simple conversion tool on the official website (and/or in official wallet apps) which would provide conversion from old to new format (and vice-versa) in case user needs to work with some old service or previously written address in old format.
94 |
95 | ## Security Considerations
96 |
97 | There are no security implications related to this change.
98 |
--------------------------------------------------------------------------------
/qip-workflow.md:
--------------------------------------------------------------------------------
1 | # QIP Workflow
2 |
3 | - [1. Considerations and Governance](#1-considerations-and-governance)
4 | - [1.1. Scope Considerations](#11-scope-considerations)
5 | - [1.2. Governance](#12-governance)
6 | - [2. Shepherding your QIP](#2-shepherding-your-qip)
7 | - [2.1. Drafting your idea](#21-drafting-your-idea)
8 | - [2.2. Facilitate Discussions](#22-facilitate-discussions)
9 | - [2.3. Request for proposal](#23-request-for-proposal)
10 | - [2.4. Proposal/open](#24-proposalopen)
11 | - [2.5. Proposal review and summary](#25-proposal-review-and-summary)
12 | - [3. Process Specification](#3-process-specification)
13 | - [3.1. Fork and setup your QIP Repository](#31-fork-and-setup-your-qip-repository)
14 | - [3.1.1. Clone your local repository](#311-clone-your-local-repository)
15 | - [3.1.2. Set theQRL organization's repository as upstream](#312-set-theqrl-organizations-repository-as-upstream)
16 | - [3.1.3. Setup your local environment](#313-setup-your-local-environment)
17 | - [3.2. Starting a draft](#32-starting-a-draft)
18 | - [3.2.1. Copy the reference QIP](#321-copy-the-reference-qip)
19 | - [3.2.2. Add anything needed from the specification](#322-add-anything-needed-from-the-specification)
20 | - [3.3. Submit your draft](#33-submit-your-draft)
21 | - [3.3.1. Commit and push](#331-commit-and-push)
22 | - [3.3.2. Submit your pull request](#332-submit-your-pull-request)
23 | - [3.4. Making adjustments](#34-making-adjustments)
24 | - [3.4.1. Fetch and merge upstream changes](#341-fetch-and-merge-upstream-changes)
25 | - [3.4.2. Make changes, commit, and push](#342-make-changes-commit-and-push)
26 | - [3.4.3. Submit a new pull request](#343-submit-a-new-pull-request)
27 | - [4. Getting help](#4-getting-help)
28 |
29 | # 1. Considerations and Governance
30 |
31 | ## 1.1. Scope Considerations
32 |
33 | Understand that QRL Improvement Proposals are design documents which govern the core structure of the QRL ecosystem. This includes the following layers:
34 |
35 | - **core**: Improvements requiring a consensus fork.
36 | - **networking**: Improvements around network components
37 | - **security**: Improvements and upgrades to to the security.
38 | - **Interface**: Improvements around APIs
39 | - **meta**: Self referential to the QIP Process, governance, and structure.
40 |
41 | Anything outside of these layers will result in a rejected QIP.
42 |
43 | ## 1.2. Governance
44 |
45 | Anyone can and is encouraged to submit a QRL Improvement Proposal (QIP) if they have an idea to improve the QRL core protocol.
46 |
47 | Votes are loosely coupled and takes place on-chain by taking a snapshot of each addresses funds and distributing a proportional amount of tokens. Known organizational entities, such as exchanges, and funds from the foundation, are excluded from this proportional distribution.
48 |
49 | When a proposal is opened, the snapshot and voting blockheight are declared along with the minimum voting threshold and turnout. Destination addresses are created, where the distributed tokens can be sent to 'register' the voters decision.
50 |
51 | # 2. Shepherding your QIP
52 |
53 | Parties involved in the process are you, the champion(s) and QIP author(s), the QIP editors, the QRL community, and the QRL contributors.
54 |
55 | QIPs start as ideas: it’s a good idea to share these ideas with the parties involved before starting. Ask the QRL community first if an idea is original to avoid wasting time on something that will be rejected based on prior research.
56 |
57 | ## 2.1. Drafting your idea
58 |
59 | Once it's determined that the idea is original and with some merit, begin by drafting your proposal from the reference QIP and following the process specification in this document below.
60 |
61 | ## 2.2. Facilitate Discussions
62 |
63 | Facilitate discussions and adjust your QIP in accordance with the discussions that have taken place.
64 |
65 | While you're championing for your own QIP, skill will be required to keep discussions positive, forward-thinking, and in good faith in order to consider all viewpoints.
66 |
67 | Thoroughly understanding all viewpoints will allow you to refine your draft into a proposal that's more likely to gain community consensus.
68 |
69 | ## 2.3. Request for proposal
70 |
71 | After a minimum of a two week period, and when you're ready for the draft to reach a proposal stage, put in a proposal request to the authors as part of the reference QIP. The QIP editors will then review the draft
72 |
73 | Assuming no adjustments are requested, the editors will evaluate and propose an on-chain governance specification.
74 |
75 | At this point, the QIP will move from `draft/incomplete` to `proposal/open`.
76 |
77 | Special note: While the QIP editors endeavor to achieve on-chain governance for every QIP, it's possible a proposal may not be suitable due to unforeseen factors.
78 |
79 | ## 2.4. Proposal/open
80 |
81 | Discussion will continue on the open proposal through to the final consensus blockheight. This is a process that can last months, depending on the scope of the proposal.
82 |
83 | ## 2.5. Proposal review and summary
84 |
85 | Whether or not consensus is reached, a summary of the proposal is made and the discussion locked.
86 |
87 | If consensus is reached at it passes review, the QIP will be set as a recommendation and slated for development depending on resources available.
88 |
89 | # 3. Process Specification
90 |
91 | The process involves an understanding of git, which many find to be cumbersome and may feel more at ease in a GUI, of which [there are a few](https://git-scm.com/downloads/guis).
92 |
93 | ## 3.1. Fork and setup your QIP Repository
94 |
95 | Login to GitHub and fork the [QIP repository](https://github.com/theQRL/qips) by clicking on the fork in the top right hand corner of your browser.
96 |
97 | ### 3.1.1. Clone your local repository
98 |
99 | ```
100 | git clone https://github.com/[YOUR-USERNAME]/qips
101 | ```
102 |
103 | ### 3.1.2. Set theQRL organization's repository as upstream
104 |
105 | ```
106 | git remote add upstream https://github.com/theQRL/qips
107 | ```
108 |
109 | ### 3.1.3. Setup your local environment
110 |
111 | For smoother editing, a local jekyll site can be built.
112 |
113 | 1. Open terminal
114 | 2. Install [rbenv](https://github.com/rbenv/rbenv), if you haven't done so already.
115 | 3. Install local Ruby version
116 |
117 | ```bash
118 | rbenv install
119 | ```
120 |
121 | 4. Install the bundler
122 |
123 | ```bash
124 | gem install bundler
125 | ```
126 |
127 | 5. Install dependencies
128 |
129 | ```bash
130 | gem install bundler jekyll
131 | bundle install
132 | ```
133 |
134 | 6. Start the server!
135 |
136 | ```bash
137 | bundle exec jekyll serve
138 | ```
139 |
140 | ## 3.2. Starting a draft
141 |
142 | ### 3.2.1. Copy the reference QIP
143 |
144 | Copy [qips/reference](qips/reference.md) and rename to "draft" followed a self-descriptive slug.
145 |
146 | Examples:
147 |
148 | - `draft-privacy.md`
149 | - `draft-encoding.md`
150 |
151 | ### 3.2.2. Add anything needed from the specification
152 |
153 | Each QIP is preceded and specified by front-matter denoted between two sets of dashes "`---`", which allows for it to be easily parsed by other programs. For quick reference, a the [`qip-template.md`](./qip-template.md) can be used to fill out the frontmatter along with the reference copied in step 3.2.1.
154 |
155 | A more detailed specification is outlined in the file [`qip-specification.md`](./qip-specification.md).
156 |
157 | Formatting below the frontmatter follows a WYSIWYM (What You See Is What You Mean) syntax called [Markdown](https://daringfireball.net/projects/markdown/syntax). There a [plenty](https://www.ossblog.org/markdown-editors/) of very good Markdown editors available.
158 |
159 | ## 3.3. Submit your draft
160 |
161 | Once you're satisfied, you'll want to submit a draft PR which consists of committing your files, pushing to your GitHub repository and then creating a pull request from theQRL's GitHub repository.
162 |
163 | ### 3.3.1. Commit and push
164 |
165 | Commit your files:
166 |
167 | ```
168 | git add [filename]
169 | ```
170 | or (with caution)
171 | ```
172 | git add --all
173 | ```
174 |
175 | It will open an editor asking you to briefly describe the changes made.
176 |
177 | Once that's saved, you can then push to your repository on GitHub
178 |
179 | ```
180 | git push
181 | ```
182 |
183 | ### 3.3.2. Submit your pull request
184 |
185 | Head over to the [pull requests section of theQRL/qips](https://github.com/theQRL/qips/pulls) repo and click on [New pull request].
186 |
187 | ## 3.4. Making adjustments
188 |
189 | After your draft is merged and discussions take place, you'll want to make some final adjustments before the draft is turned into a proposal.
190 |
191 | ### 3.4.1. Fetch and merge upstream changes
192 |
193 | From the local repo you had before, fetch and merge upstream changes.
194 |
195 | ```
196 | git fetch upstream
197 | git merge upstream/master
198 | ```
199 |
200 | ### 3.4.2. Make changes, commit, and push
201 |
202 | Same thing as 3.3.1. Make any changes to your files and commit.
203 |
204 | ```
205 | git add [filename]
206 | ```
207 | or (with caution)
208 | ```
209 | git add --all
210 | ```
211 |
212 | It will open an editor asking you to briefly describe the changes made.
213 |
214 | Once that's saved, you can then push to your repository on GitHub
215 |
216 | ```
217 | git push
218 | ```
219 |
220 | ### 3.4.3. Submit a new pull request
221 |
222 | Head over to the [pull requests section of theQRL/qips](https://github.com/theQRL/qips/pulls) repo and click on [New pull request].
223 |
224 | # 4. Getting help
225 |
226 | If you're lost at any point during this process, feel free to reach out to the community on [Reddit](https://reddit.com/r/QRL), [Discord](https://www.theqrl.org/discord) or email QRL support at [support@theqrl.org](mailto:support@theqrl.org).
227 |
--------------------------------------------------------------------------------
/repo_outline.svg:
--------------------------------------------------------------------------------
1 |
2 |
996 |
--------------------------------------------------------------------------------