Updated Dogecoin references in Docs
Some docs still referencing Bitcoin and Bitcoin Core. Updated to reflect Dogecoin branding.
This commit is contained in:
Alan Cramer
Ross Nicoll
parent
5632a9341c
commit
190d1ab808
|
|
@ -92,6 +92,6 @@ build process to remain somewhat deterministic. Here's how it works:
|
|||
that have been previously (deterministically) built in order to create a
|
||||
final dmg.
|
||||
- The Apple keyholder uses this unsigned app to create a detached signature,
|
||||
using the script that is also included there. Detached signatures are available from this [repository](https://github.com/bitcoin-core/bitcoin-detached-sigs).
|
||||
using the script that is also included there. Detached signatures are available from this [repository](https://github.com/dogecoin/dogecoin-detached-sigs).
|
||||
- Builders feed the unsigned app + detached signature back into Gitian. It
|
||||
uses the pre-built tools to recombine the pieces into a deterministic dmg.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ pkg_add automake # (select highest version, e.g. 1.15)
|
|||
pkg_add python # (select highest version, e.g. 3.5)
|
||||
```
|
||||
|
||||
The default C++ compiler that comes with OpenBSD 5.9 is g++ 4.2. This version is old (from 2007), and is not able to compile the current version of Bitcoin Core, primarily as it has no C++11 support, but even before there were issues. So here we will be installing a newer compiler.
|
||||
The default C++ compiler that comes with OpenBSD 5.9 is g++ 4.2. This version is old (from 2007), and is not able to compile the current version of Dogecoin Core, primarily as it has no C++11 support, but even before there were issues. So here we will be installing a newer compiler.
|
||||
|
||||
GCC
|
||||
-------
|
||||
|
|
@ -39,7 +39,7 @@ Do not use `pkg_add boost`! The boost version installed thus is compiled using t
|
|||
...
|
||||
Segmentation fault (core dumped)
|
||||
|
||||
This makes it necessary to build boost, or at least the parts used by Bitcoin Core, manually:
|
||||
This makes it necessary to build boost, or at least the parts used by Dogecoin Core, manually:
|
||||
|
||||
```
|
||||
# Pick some path to install boost to, here we create a directory within the dogecoin directory
|
||||
|
|
@ -108,7 +108,7 @@ The change will only affect the current shell and processes spawned by it. To
|
|||
make the change system-wide, change `datasize-cur` and `datasize-max` in
|
||||
`/etc/login.conf`, and reboot.
|
||||
|
||||
### Building Bitcoin Core
|
||||
### Building Dogecoin Core
|
||||
|
||||
**Important**: use `gmake`, not `make`. The non-GNU `make` will exit with a horrible error.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Reduce Traffic
|
|||
|
||||
Some node operators need to deal with bandwidth caps imposed by their ISPs.
|
||||
|
||||
By default, bitcoin-core allows up to 125 connections to different peers, 8 of
|
||||
By default, dogecoin-core allows up to 125 connections to different peers, 8 of
|
||||
which are outbound. You can therefore, have at most 117 inbound connections.
|
||||
|
||||
The default settings can result in relatively significant traffic consumption.
|
||||
|
|
@ -33,5 +33,5 @@ blocks and transactions to fewer nodes.
|
|||
## 3. Reduce maximum connections (`-maxconnections=<num>`)
|
||||
|
||||
Reducing the maximum connected nodes to a minimum could be desirable if traffic
|
||||
limits are tiny. Keep in mind that bitcoin's trustless model works best if you are
|
||||
limits are tiny. Keep in mind that Dogecoin's trustless model works best if you are
|
||||
connected to a handful of nodes.
|
||||
|
|
|
|||
|
|
@ -250,7 +250,7 @@ possible.
|
|||
Known Bugs
|
||||
==========
|
||||
|
||||
Since 1.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin
|
||||
Since 1.14.0 the approximate transaction fee shown in Dogecoin-Qt when using coin
|
||||
control and smart fee estimation does not reflect any change in target from the
|
||||
smart fee slider. It will only present an approximate fee calculated using the
|
||||
default target. The fee calculated using the correct target is still applied to
|
||||
|
|
|
|||
14
doc/tor.md
14
doc/tor.md
|
|
@ -74,7 +74,7 @@ In a typical situation, where you're only reachable via Tor, this should suffice
|
|||
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:
|
||||
|
||||
./bitcoind ... -bind=127.0.0.1
|
||||
./dogecoind ... -bind=127.0.0.1
|
||||
|
||||
If you don't care too much about hiding your node, and want to be reachable on IPv4
|
||||
as well, use `discover` instead:
|
||||
|
|
@ -96,21 +96,21 @@ API, to create and destroy 'ephemeral' hidden services programmatically.
|
|||
Bitcoin Core has been updated to make use of this.
|
||||
|
||||
This means that if Tor is running (and proper authentication has been configured),
|
||||
Bitcoin Core automatically creates a hidden service to listen on. This will positively
|
||||
Dogecoin Core automatically creates a hidden service to listen on. This will positively
|
||||
affect the number of available .onion nodes.
|
||||
|
||||
This new feature is enabled by default if Bitcoin Core is listening (`-listen`), and
|
||||
This new feature is enabled by default if Dogecoin Core is listening (`-listen`), and
|
||||
requires a Tor connection to work. It can be explicitly disabled with `-listenonion=0`
|
||||
and, if not disabled, configured using the `-torcontrol` and `-torpassword` settings.
|
||||
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 bitcoind must have write access
|
||||
configured. For cookie authentication the user running dogecoind must have write access
|
||||
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
|
||||
the user running bitcoind to the same group and setting permissions appropriately. On
|
||||
Debian-based systems the user running bitcoind can be added to the debian-tor group,
|
||||
the user running dogecoind to the same group and setting permissions appropriately. On
|
||||
Debian-based systems the user running dogecoind can be added to the debian-tor group,
|
||||
which has the appropriate permissions. An alternative authentication method is the use
|
||||
of the `-torpassword` flag and a `hash-password` which can be enabled and specified in
|
||||
Tor configuration.
|
||||
|
|
@ -118,7 +118,7 @@ Tor configuration.
|
|||
4. Privacy recommendations
|
||||
---------------------------
|
||||
|
||||
- Do not add anything but bitcoin ports to the hidden service created in section 2.
|
||||
- Do not add anything but dogecoin ports to the hidden service created in section 2.
|
||||
If you run a web service too, create a new hidden service for that.
|
||||
Otherwise it is trivial to link them, which may reduce privacy. Hidden
|
||||
services created automatically (as in section 3) always have only one port
|
||||
|
|
|
|||
Loading…
Reference in New Issue