From 40fbb25c80a2ef7d463b5f652d88deae4e877b3f Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 15 Nov 2017 10:59:34 -0500 Subject: [PATCH] Guide - wallet section updates Misc other changes --- _includes/devdoc/guide_contracts.md | 3 +- _includes/devdoc/guide_wallets.md | 71 +++++++++++--------------- _includes/devdoc/ref_p2p_networking.md | 6 +-- _layouts/glossary_entry.html | 1 - 4 files changed, 34 insertions(+), 47 deletions(-) diff --git a/_includes/devdoc/guide_contracts.md b/_includes/devdoc/guide_contracts.md index 25f4028a..a69d9f70 100644 --- a/_includes/devdoc/guide_contracts.md +++ b/_includes/devdoc/guide_contracts.md @@ -198,12 +198,13 @@ For larger payments, Dash transaction fees are very low as a percentage of the total transaction value, so it makes more sense to protect payments with immediately-broadcast separate transactions. + {% endautocrossref %} @@ -429,7 +418,7 @@ existing [(parent) public key][/en/glossary/parent-key]{:#term-parent-public-key integer (*i*) value. This child public key is the same public key which would be created by the `point()` function if you added the *i* value to the original (parent) private key and then found the remainder of that -sum divided by a global constant used by all Bitcoin software (*p*): +sum divided by a global constant used by all Dash software (*p*): {% endautocrossref %} @@ -590,7 +579,7 @@ keys can't create hardened child public keys. Because of that, a [hardened extended private key][/en/glossary/hardened-extended-key]{:#term-hardened-extended-private-key}{:.term} is much less -useful than a normal extended private key---however, +useful than a normal extended private key---however, hardened extended private keys create a firewall through which multi-level key derivation compromises cannot happen. Because hardened child extended public keys cannot generate grandchild chain codes on @@ -606,7 +595,7 @@ make descriptions easy, many developers use the [prime symbol][] to indicate hardened keys, so the first normal key (0x00) is 0 and the first hardened key (0x80000000) is 0´. -(Bitcoin developers typically use the ASCII apostrophe rather than +(Dash developers typically use the ASCII apostrophe rather than the unicode prime symbol, a convention we will henceforth follow.) This compact description is further combined with slashes prefixed by @@ -667,21 +656,19 @@ For implementation details, please see BIP39. {% endautocrossref %} - - #### Loose-Key Wallets {% include helpers/subhead-links.md %} {% autocrossref %} -Loose-Key wallets, also called "Just a Bunch Of Keys (JBOK)", are a deprecated form of wallet that originated from the Bitcoin Core client wallet. The Bitcoin Core client wallet would create 100 private key/public key pairs automatically via a Pseudo-Random-Number Generator (PRNG) for later use. +Loose-Key wallets, also called "Just a Bunch Of Keys (JBOK)", are a form of wallet that originated from the Bitcoin Core client wallet. The Dash Core client wallet creates 1000 private key/public key pairs automatically via a Pseudo-Random-Number Generator (PRNG) for later use. These unused private keys are stored in a virtual "key pool", with new keys being generated whenever a previously-generated key was used, -ensuring the pool maintained 100 unused keys. (If the wallet is +ensuring the pool maintained 1000 unused keys. (If the wallet is encrypted, new keys are only generated while the wallet is unlocked.) -This created considerable difficulty in backing up one’s keys, considering backups have to be run manually to save the newly-generated private keys. If a new key pair set is generated, used, and then lost prior to a backup, the stored satoshis are likely lost forever. Many older-style mobile wallets followed a similar format, but only generated a new private key upon user demand. +This creates considerable difficulty in backing up one’s keys, considering backups have to be run manually to save the newly-generated private keys. If a new key pair set is generated, used, and then lost prior to a backup, the stored duffs are likely lost forever. Many older-style mobile wallets followed a similar format, but only generated a new private key upon user demand. This wallet type is being actively phased out and discouraged from being used due to the backup hassle. diff --git a/_includes/devdoc/ref_p2p_networking.md b/_includes/devdoc/ref_p2p_networking.md index 594bfaac..2ad9b9c7 100644 --- a/_includes/devdoc/ref_p2p_networking.md +++ b/_includes/devdoc/ref_p2p_networking.md @@ -1318,10 +1318,10 @@ Defined Sporks (per [`src/spork.h`][spork.h]) | 10002 | 3 | `INSTANTSEND_BLOCK_FILTERING` | Turns on and off InstantSend block filtering | 10004 | 5 | `INSTANTSEND_MAX_VALUE` | Controls the max value for an InstantSend transaction (currently 2000 dash) | 10007 | 8 | `MASTERNODE_PAYMENT_ENFORCEMENT` | Requires masternodes to be paid by miners when blocks are processed -| 10008 | 9 | `SUPERBLOCKS_ENABLED` | Superblocks are enabled (the 10% comes to fund the dash treasury) +| 10008 | 9 | `SUPERBLOCKS_ENABLED` | Superblocks are enabled (10% of the block reward allocated to fund the dash treasury for funding approved proposals) | 10009 | 10 | `MASTERNODE_PAY_UPDATED_NODES` | Only current protocol version masternode's will be paid (not older nodes) -| 10011 | 12 | `RECONSIDER_BLOCKS` | -| 10012 | 13 | `OLD_SUPERBLOCK_FLAG` | +| 10011 | 12 | `RECONSIDER_BLOCKS` | Forces reindex of a specified number of blocks to recover from unintentional network forks +| 10012 | 13 | `OLD_SUPERBLOCK_FLAG` | Deprecated. No network function since block 614820 | 10013 | 14 | `REQUIRE_SENTINEL_FLAG` | Only masternode's running sentinel will be paid To verify `vchSig`, compare the hard-coded spork public key (`strSporkPubKey` diff --git a/_layouts/glossary_entry.html b/_layouts/glossary_entry.html index 64e22fd0..7174731c 100644 --- a/_layouts/glossary_entry.html +++ b/_layouts/glossary_entry.html @@ -5,7 +5,6 @@ layout: base lang: en breadcrumbs: - - bitcoin - dev docs - glossary - GLOSSARY_ENTRY_TITLE