joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-26 17:26:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Guide - wallet section updates

Browse source 
Misc other changes
This commit is contained in:
thephez 2017-11-15 10:59:34 -05:00
parent f19c6f7800
commit 40fbb25c80
4 changed files with 34 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

3
_includes/devdoc/guide_contracts.md
View file

@ -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

71
_includes/devdoc/guide_wallets.md
View file

@ -9,9 +9,9 @@ http://opensource.org/licenses/MIT.
{% autocrossref %}
A Bitcoin wallet can refer to either a wallet program or a wallet file.
Wallet programs create public keys to receive satoshis and use the
corresponding private keys to spend those satoshis. Wallet files
A Dash wallet can refer to either a wallet program or a wallet file.
Wallet programs create public keys to receive duffs and use the
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
another program signing transactions spending those satoshis.
program distributing public keys in order to receive duffs and
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
recommended default for all Bitcoin software.
compressed public keys are the default in Dash Core and are the
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.

6
_includes/devdoc/ref_p2p_networking.md
View file

@ -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`

1
_layouts/glossary_entry.html
View file

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