Guide - wallet section updates

Misc other changes

_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.
 
+<!-- dashj _may_ support the bitcoinj micropayment functions, but has not been tested
 **Resource:** The [dashj][] Java library
 provides a complete set of micropayment functions, an example
 implementation, and [a
 tutorial (from bitcoinj)][bitcoinj micropayment tutorial]
 all under an Apache license.
-
+-->
 {% endautocrossref %}
 
 <!-- Obsolesced by PrivateSend

_includes/devdoc/guide_wallets.md

@@ -9,9 +9,9 @@ http://opensource.org/licenses/MIT.
 
 {% autocrossref %}
 
-A Bitcoin wallet can refer to either a wallet program or a wallet file.
+A Dash wallet can refer to either a wallet program or a wallet file.
-Wallet programs create public keys to receive satoshis and use the
+Wallet programs create public keys to receive duffs and use the
-corresponding private keys to spend those satoshis. Wallet files
+corresponding private keys to spend those duffs. Wallet files
 store private keys and (optionally) other information related to
 transactions for the wallet program.
 
@@ -26,11 +26,11 @@ we're talking about wallet programs or wallet files.
 
 {% autocrossref %}
 
-Permitting receiving and spending of satoshis is the only essential
+Permitting receiving and spending of duffs is the only essential
 feature of wallet software---but a particular wallet program doesn't
 need to do both things.  Two wallet programs can work together, one
-program distributing public keys in order to receive satoshis and
+program distributing public keys in order to receive duffs and
-another program signing transactions spending those satoshis.
+another program signing transactions spending those duffs.
 
 Wallet programs also need to interact with the peer-to-peer network to
 get information from the block chain and to broadcast new transactions.
@@ -67,7 +67,7 @@ full-service wallets.
 
 The main advantage of full-service wallets is that they are easy to use.
 A single program does everything the user needs to receive and spend
-satoshis.
+duffs.
 
 The main disadvantage of full-service wallets is that they store the
 private keys on a device connected to the Internet.  The compromise of
@@ -82,7 +82,6 @@ key or to read the decrypted keys from memory.
 
 {% endautocrossref %}
 
-
 #### Signing-Only Wallets
 {% include helpers/subhead-links.md %}
 
@@ -91,7 +90,7 @@ key or to read the decrypted keys from memory.
 To increase security, private keys can be generated and stored by a
 separate wallet program operating in a more secure environment. These
 signing-only wallets work in conjunction with a networked wallet which
-interacts with the peer-to-peer network. 
+interacts with the peer-to-peer network.
 
 Signing-only wallets programs typically use deterministic key creation
 (described in a later subsection) to create parent private and public
@@ -108,7 +107,7 @@ those public keys, creates unsigned transactions spending those outputs,
 and transfers the unsigned transactions to the signing-only wallet.
 
 Often, users are given a chance to review the unsigned transactions' details
-(particularly the output details) using the signing-only wallet.  
+(particularly the output details) using the signing-only wallet.
 
 After the optional review step, the signing-only wallet uses the parent
 private key to derive the appropriate child private keys and signs the
@@ -146,7 +145,7 @@ drives.  The user's workflow is something like:
 2. (Online) Install the wallet software on another device, this one
    connected to the Internet, and import the parent public key from the
    removable media. As you would with a full-service wallet, distribute
-   public keys to receive payment. When ready to spend satoshis, fill in
+   public keys to receive payment. When ready to spend duffs, fill in
    the output details and save the unsigned transaction generated by the
    wallet to removable media.
 
@@ -163,7 +162,7 @@ drives.  The user's workflow is something like:
 The primary advantage of offline wallets is their possibility for
 greatly improved security over full-service wallets.  As long as the
 offline wallet is not compromised (or flawed) and the user reviews all outgoing
-transactions before signing, the user's satoshis are safe even if the
+transactions before signing, the user's duffs are safe even if the
 online wallet is compromised.
 
 The primary disadvantage of offline wallets is hassle. For maximum
@@ -174,8 +173,6 @@ device and back.
 
 {% endautocrossref %}
 
-
-
 ##### Hardware Wallets
 {% include helpers/subhead-links.md %}
 
@@ -191,7 +188,7 @@ transfer data manually.  The user's workflow is something like:
    wallet to a networked device so it can get the parent public key.
 
 2. (Networked) As you would with a full-service wallet, distribute
-   public keys to receive payment. When ready to spend satoshis, fill in
+   public keys to receive payment. When ready to spend duffs, fill in
    the transaction details, connect the hardware wallet, and click
    Spend.  The networked wallet will automatically send the transaction
    details to the hardware wallet.
@@ -220,9 +217,6 @@ their intention to support at least one model of hardware wallet.
 
 {% endautocrossref %}
 
-
-
-
 #### Distributing-Only Wallets
 {% include helpers/subhead-links.md %}
 
@@ -256,7 +250,6 @@ Processing][devguide payment processing] section for details.
 {% endautocrossref %}
 
 
-
 ### Wallet Files
 {% include helpers/subhead-links.md %}
 
@@ -273,9 +266,9 @@ stored on pieces of paper.
 
 {% autocrossref %}
 
-Private keys are what are used to unlock satoshis from a particular address. In Bitcoin, a private key in standard format is simply a 256-bit number, between the values:
+Private keys are what are used to unlock duffs from a particular address. In Dash, a private key in standard format is simply a 256-bit number, between the values:
 
-0x01 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140, representing nearly the entire range of 2<sup>256</sup>-1 values. The range is governed by the secp256k1 ECDSA encryption standard used by Bitcoin. 
+0x01 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140, representing nearly the entire range of 2<sup>256</sup>-1 values. The range is governed by the secp256k1 ECDSA encryption standard used by Dash.
 
 {% endautocrossref %}
 
@@ -284,7 +277,7 @@ Private keys are what are used to unlock satoshis from a particular address. In
 
 {% autocrossref %}
 
-In order to make copying of private keys less prone to error, [Wallet Import Format][/en/glossary/wallet-import-format]{:#term-wallet-import-format}{:.term} may be utilized. WIF uses base58Check encoding on an private key, greatly decreasing the chance of copying error, much like standard Bitcoin addresses.
+In order to make copying of private keys less prone to error, [Wallet Import Format][/en/glossary/wallet-import-format]{:#term-wallet-import-format}{:.term} may be utilized. WIF uses base58Check encoding on an private key, greatly decreasing the chance of copying error, much like standard Dash addresses.
 
 1. Take a private key.
 
@@ -313,13 +306,13 @@ The process is easily reversible, using the Base58 decoding function, and removi
 
 {% autocrossref %}
 
-Mini private key format is a method for encoding a private key in under 30 characters, enabling keys to be embedded in a small physical space, such as physical bitcoin tokens, and more damage-resistant QR codes. 
+Mini private key format is a method for encoding a private key in under 30 characters, enabling keys to be embedded in a small physical space and more damage-resistant QR codes.
 
-1. The first character of mini keys is 'S'. 
+1. The first character of mini keys is 'S'.
 
 2. In order to determine if a mini private key is well-formatted, a question mark is added to the private key.
 
-3. The SHA256 hash is calculated. If the first byte produced is a `00’, it is well-formatted. This key restriction acts as a typo-checking mechanism. A user brute forces the process using random numbers until a well-formatted mini private key is produced. 
+3. The SHA256 hash is calculated. If the first byte produced is a `00`, it is well-formatted. This key restriction acts as a typo-checking mechanism. A user brute forces the process using random numbers until a well-formatted mini private key is produced.
 
 4. In order to derive the full private key, the user simply takes a single SHA256 hash of the original mini private key. This process is one-way: it is intractable to compute the mini private key format from the derived key.
 
@@ -330,15 +323,12 @@ address utility].
 
 {% endautocrossref %}
 
-
-
-
 #### Public Key Formats
 {% include helpers/subhead-links.md %}
 
 {% autocrossref %}
 
-Bitcoin ECDSA public keys represent a point on a particular Elliptic
+Dash ECDSA public keys represent a point on a particular Elliptic
 Curve (EC) defined in secp256k1. In their traditional uncompressed form,
 public keys contain an identification byte, a 32-byte X coordinate, and
 a 32-byte Y coordinate. The extremely simplified illustration below
@@ -367,8 +357,8 @@ default in the widely-used OpenSSL library.
 
 Because they're easy to use, and because they reduce almost by half
 the block chain space used to store public keys for every spent output,
-compressed public keys are the default in Bitcoin Core and are the
+compressed public keys are the default in Dash Core and are the
-recommended default for all Bitcoin software.
+recommended default for all Dash software.
 
 However, Bitcoin Core prior to 0.6 used uncompressed keys.  This creates
 a few complications, as the hashed form of an uncompressed key is
@@ -377,7 +367,7 @@ works with two different P2PKH addresses.   This also means that the key
 must be submitted in the correct format in the signature script so it
 matches the hash in the previous output's pubkey script.
 
-For this reason, Bitcoin Core uses several different identifier bytes to
+For this reason, Bitcoin Core (and Dash Core) uses several different identifier bytes to
 help programs identify how keys should be used:
 
 * Private keys meant to be used with compressed public keys have 0x01
@@ -391,11 +381,10 @@ help programs identify how keys should be used:
 
 {% endautocrossref %}
 
-
 #### Hierarchical Deterministic Key Creation
 {% include helpers/subhead-links.md %}
 
-<!-- 
+<!--
 For consistent word ordering:
 [normal|hardened|] [master|parent|child|grandchild] [extended|non-extended|] [private|public|chain] [key|code]
 -->
@@ -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<!--noref--> 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<!--noref--> 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.
 

_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` |
+| 10011 | 12 | `RECONSIDER_BLOCKS` | Forces reindex of a specified number of blocks to recover from unintentional network forks
-| 10012 | 13 | `OLD_SUPERBLOCK_FLAG` |
+| 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`

_layouts/glossary_entry.html

@@ -5,7 +5,6 @@
 layout: base
 lang: en
 breadcrumbs:
-  - bitcoin
   - dev docs
   - glossary
   - GLOSSARY_ENTRY_TITLE