mirror of
https://github.com/dashpay/dash.git
synced 2024-12-25 03:52:49 +01:00
Merge #13255: trivial: Fixed typos and cleaned up language
d5f745a5c7 trivial: correct typos (Varunram) 3be70ba400 trivial: Fixed typos and cleaned up language (William Robinson) Pull request description: This rebases and fixes some of the outstanding nits in #13010. Let either merge quickly or close for now. Tree-SHA512: 4cc1a5f854f2d6a19332334e2608a19e2be6b97dc09114c8186237ea77ee4b62372ebf6841a61cca548cedb47f0e6f11d4c0aba51a71949cd5aff8cef88204d6
This commit is contained in:
MarcoFalke
UdjinM6
parent
d33dd31032
commit
8e3565df8e
@ -5,7 +5,7 @@ This is the official reference wallet for Dash digital currency and comprises th
|
||||
|
||||
Running
|
||||
---------------------
|
||||
The following are some helpful notes on how to run Dash on your native platform.
|
||||
The following are some helpful notes on how to run Dash Core on your native platform.
|
||||
|
||||
### Unix
|
||||
|
||||
@ -20,7 +20,7 @@ Unpack the files into a directory, and then run dash-qt.exe.
|
||||
|
||||
### macOS
|
||||
|
||||
Drag Dash-Qt to your applications folder, and then run Dash-Qt.
|
||||
Drag Dash Core to your applications folder, and then run Dash Core.
|
||||
|
||||
### Need Help?
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@ Benchmarking
|
||||
============
|
||||
|
||||
Dash Core has an internal benchmarking framework, with benchmarks
|
||||
for cryptographic algorithms such as SHA1, SHA256, SHA512 and RIPEMD160. As well as the rolling bloom filter.
|
||||
for cryptographic algorithms (e.g. SHA1, SHA256, SHA512, RIPEMD160), as well as the rolling bloom filter.
|
||||
|
||||
Running
|
||||
---------------------
|
||||
|
||||
@ -13,7 +13,7 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.13.0**):
|
||||
* [`BIP 32`](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki): Hierarchical Deterministic Wallets has been implemented since **v0.13.0** ([PR #8035](https://github.com/bitcoin/bitcoin/pull/8035)).
|
||||
* [`BIP 34`](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki): The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since **v0.7.0**. The rule took effect for version 2 blocks as of *block 224413* (March 5th 2013), and version 1 blocks are no longer allowed since *block 227931* (March 25th 2013) ([PR #1526](https://github.com/bitcoin/bitcoin/pull/1526)).
|
||||
* [`BIP 35`](https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki): The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since **v0.7.0** ([PR #1641](https://github.com/bitcoin/bitcoin/pull/1641)).
|
||||
* [`BIP 37`](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki): The bloom filtering for transaction relaying, partial merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth SPV clients) has been implemented since **v0.8.0** ([PR #1795](https://github.com/bitcoin/bitcoin/pull/1795)).
|
||||
* [`BIP 37`](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki): The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth SPV clients) has been implemented since **v0.8.0** ([PR #1795](https://github.com/bitcoin/bitcoin/pull/1795)).
|
||||
* [`BIP 42`](https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki): The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in **v0.9.2** ([PR #3842](https://github.com/bitcoin/bitcoin/pull/3842)).
|
||||
* [`BIP 61`](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki): The 'reject' protocol message (and the protocol version bump to 70002) was added in **v0.9.0** ([PR #3185](https://github.com/bitcoin/bitcoin/pull/3185)). Starting *v0.16.0*, whether to send reject messages can be configured with the `-enablebip61` option.
|
||||
* [`BIP 65`](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki): The CHECKLOCKTIMEVERIFY softfork was merged in **v0.12.0** ([PR #6351](https://github.com/bitcoin/bitcoin/pull/6351)), and backported to **v0.11.2** and **v0.10.4**. Mempool-only CLTV was added in [PR #6124](https://github.com/bitcoin/bitcoin/pull/6124).
|
||||
|
||||
@ -40,7 +40,7 @@ Running
|
||||
|
||||
Dash Core is now available at `./src/dashd`
|
||||
|
||||
Before running, it's recommended you create an RPC configuration file.
|
||||
Before running, it's recommended that you create an RPC configuration file.
|
||||
|
||||
echo -e "rpcuser=dashrpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/DashCore/dash.conf"
|
||||
|
||||
|
||||
@ -46,7 +46,7 @@ Follow the instructions in [build-generic](build-generic.md)
|
||||
|
||||
Security
|
||||
--------
|
||||
To help make your Dash installation more secure by making certain attacks impossible to
|
||||
To help make your Dash Core installation more secure by making certain attacks impossible to
|
||||
exploit even if a vulnerability is found, binaries are hardened by default.
|
||||
This can be disabled with:
|
||||
|
||||
@ -62,7 +62,7 @@ Hardening enables the following features:
|
||||
Build position independent code to take advantage of Address Space Layout Randomization
|
||||
offered by some kernels. Attackers who can cause execution of code at an arbitrary memory
|
||||
location are thwarted if they don't know where anything useful is located.
|
||||
The stack and heap are randomly located by default but this allows the code section to be
|
||||
The stack and heap are randomly located by default, but this allows the code section to be
|
||||
randomly located as well.
|
||||
|
||||
On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error
|
||||
@ -78,8 +78,8 @@ Hardening enables the following features:
|
||||
ET_DYN
|
||||
|
||||
* Non-executable Stack
|
||||
If the stack is executable then trivial stack based buffer overflow exploits are possible if
|
||||
vulnerable buffers are found. By default, Dash Core should be built with a non-executable stack
|
||||
If the stack is executable then trivial stack-based buffer overflow exploits are possible if
|
||||
vulnerable buffers are found. By default, Dash Core should be built with a non-executable stack,
|
||||
but if one of the libraries it uses asks for an executable stack or someone makes a mistake
|
||||
and uses a compiler extension which requires an executable stack, it will silently build an
|
||||
executable without the non-executable stack protection.
|
||||
@ -87,7 +87,7 @@ Hardening enables the following features:
|
||||
To verify that the stack is non-executable after compiling use:
|
||||
`scanelf -e ./dashd`
|
||||
|
||||
the output should contain:
|
||||
The output should contain:
|
||||
STK/REL/PTL
|
||||
RW- R-- RW-
|
||||
|
||||
|
||||
22
doc/tor.md
22
doc/tor.md
@ -11,13 +11,13 @@ for how to properly configure Tor.
|
||||
|
||||
## 1. Run Dash Core behind a Tor proxy
|
||||
|
||||
The first step is running Dash Core behind a Tor proxy. This will already make all
|
||||
outgoing connections be anonymized, but more is possible.
|
||||
The first step is running Dash Core behind a Tor proxy. This will already anonymize all
|
||||
outgoing connections, but more is possible.
|
||||
|
||||
-proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy
|
||||
server will be used to try to reach .onion addresses as well.
|
||||
|
||||
-onion=ip:port Set the proxy server to use for tor hidden services. You do not
|
||||
-onion=ip:port Set the proxy server to use for Tor hidden services. You do not
|
||||
need to set this if it's the same as -proxy. You can use -noonion
|
||||
to explicitly disable access to hidden service.
|
||||
|
||||
@ -58,11 +58,11 @@ your dashd's P2P listen port (9999 by default).
|
||||
|
||||
-externalip=X You can tell Dash Core about its publicly reachable address using
|
||||
this option, and this can be a .onion address. Given the above
|
||||
configuration, you can find your onion address in
|
||||
/var/lib/tor/dashcore-service/hostname. Onion addresses are given
|
||||
preference for your node to advertise itself with, for connections
|
||||
configuration, you can find your .onion address in
|
||||
/var/lib/tor/dashcore-service/hostname. For connections
|
||||
coming from unroutable addresses (such as 127.0.0.1, where the
|
||||
Tor proxy typically runs).
|
||||
Tor proxy typically runs), .onion addresses are given
|
||||
preference for your node to advertise itself with.
|
||||
|
||||
-listen You'll need to enable listening for incoming connections, as this
|
||||
is off by default behind a proxy.
|
||||
@ -78,7 +78,7 @@ In a typical situation, where you're only reachable via Tor, this should suffice
|
||||
|
||||
./dashd -proxy=127.0.0.1:9050 -externalip=ssapp53tmftyjmjb.onion -listen
|
||||
|
||||
(obviously, replace the Onion address with your own). It should be noted that you still
|
||||
(obviously, replace the .onion address with your own). It should be noted that you still
|
||||
listen on all devices and another node could establish a clearnet connection, when knowing
|
||||
your address. To mitigate this, additionally bind the address of your Tor proxy:
|
||||
|
||||
@ -91,7 +91,7 @@ as well, use `discover` instead:
|
||||
|
||||
and open port 9999 on your firewall (or use -upnp).
|
||||
|
||||
If you only want to use Tor to reach onion addresses, but not use it as a proxy
|
||||
If you only want to use Tor to reach .onion addresses, but not use it as a proxy
|
||||
for normal IPv4/IPv6 communication, use:
|
||||
|
||||
./dashd -onion=127.0.0.1:9050 -externalip=ssapp53tmftyjmjb.onion -discover
|
||||
@ -130,9 +130,9 @@ To show verbose debugging information, pass `-debug=tor`.
|
||||
|
||||
Connecting to Tor's control socket API requires one of two authentication methods to be
|
||||
configured. For cookie authentication the user running dashd must have write access
|
||||
to the `CookieAuthFile` specified in Tor configuration. In some cases this is
|
||||
to the `CookieAuthFile` specified in Tor configuration. In some cases, this is
|
||||
preconfigured and the creation of a hidden service is automatic. If permission problems
|
||||
are seen with `-debug=tor` they can be resolved by adding both the user running tor and
|
||||
are seen with `-debug=tor` they can be resolved by adding both the user running Tor and
|
||||
the user running dashd to the same group and setting permissions appropriately. On
|
||||
Debian-based systems the user running dashd can be added to the debian-tor group,
|
||||
which has the appropriate permissions. An alternative authentication method is the use
|
||||
|
||||
@ -278,7 +278,7 @@
|
||||
"010000000144490eda355be7480f2ec828dcc1b9903793a8008fad8cfe9b0c6b4d2f0355a9000000004a483045022100fa4a74ba9fd59c59f46c3960cf90cbe0d2b743c471d24a3d5d6db6002af5eebb02204d70ec490fd0f7055a7c45f86514336e3a7f03503dacecabb247fc23f15c83510151ffffffff010000000000000000016a00000000", "P2SH,CONST_SCRIPTCODE"],
|
||||
|
||||
|
||||
["Using CHECKSIG with singatures in scriptSigs will trigger FindAndDelete, which is invalid"],
|
||||
["Using CHECKSIG with signatures in scriptSigs will trigger FindAndDelete, which is invalid"],
|
||||
[[["ccf7f4053a02e653c36ac75c891b7496d0dc5ce5214f6c913d9cf8f1329ebee0", 0, "DUP HASH160 0x14 0xee5a6aa40facefb2655ac23c0c28c57c65c41f9b EQUALVERIFY CHECKSIG"]],
|
||||
"0100000001e0be9e32f1f89c3d916c4f21e55cdcd096741b895cc76ac353e6023a05f4f7cc00000000d86149304602210086e5f736a2c3622ebb62bd9d93d8e5d76508b98be922b97160edc3dcca6d8c47022100b23c312ac232a4473f19d2aeb95ab7bdf2b65518911a0d72d50e38b5dd31dc820121038479a0fa998cd35259a2ef0a7a5c68662c1474f88ccb6d08a7677bbec7f22041ac4730440220508fa761865c8abd81244a168392876ee1d94e8ed83897066b5e2df2400dad24022043f5ee7538e87e9c6aef7ef55133d3e51da7cc522830a9c4d736977a76ef755c0121038479a0fa998cd35259a2ef0a7a5c68662c1474f88ccb6d08a7677bbec7f22041ffffffff010000000000000000016a00000000", "P2SH,CONST_SCRIPTCODE"],
|
||||
|
||||
|
||||
@ -109,7 +109,7 @@ struct CompactTallyItem
|
||||
|
||||
enum WalletFlags : uint64_t {
|
||||
// wallet flags in the upper section (> 1 << 31) will lead to not opening the wallet if flag is unknown
|
||||
// unkown wallet flags in the lower section <= (1 << 31) will be tolerated
|
||||
// unknown wallet flags in the lower section <= (1 << 31) will be tolerated
|
||||
|
||||
// will enforce the rule that the wallet can't contain any private keys (only watch-only/pubkeys)
|
||||
WALLET_FLAG_DISABLE_PRIVATE_KEYS = (1ULL << 32),
|
||||
|
||||
Loading…
Reference in New Issue
Block a user