mirror of
https://github.com/dogecoin/dogecoin.git
synced 2026-01-31 10:30:52 +00:00
Merge branch 'rnicoll-rnicoll/1590-rebase' into 1.14-maint
This commit is contained in:
langerhans
commit
6eab99b581
@ -13,7 +13,7 @@ Construct a linear, no-fork, best version of the blockchain.
|
||||
|
||||
### [Qos](/contrib/qos) ###
|
||||
|
||||
A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Bitcoin network. This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-qt instance which connects to this node and receives blocks from it.
|
||||
A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Dogecoin network. This means one can have an always-on dogecoind instance running, and another local dogecoind/dogecoin-qt instance which connects to this node and receives blocks from it.
|
||||
|
||||
### [Seeds](/contrib/seeds) ###
|
||||
Utility to generate the pnSeed[] array that is compiled into the client.
|
||||
@ -22,20 +22,20 @@ Build Tools and Keys
|
||||
---------------------
|
||||
|
||||
### [Debian](/contrib/debian) ###
|
||||
Contains files used to package bitcoind/bitcoin-qt
|
||||
for Debian-based Linux systems. If you compile bitcoind/bitcoin-qt yourself, there are some useful files here.
|
||||
Contains files used to package dogecoind/dogecoin-qt
|
||||
for Debian-based Linux systems. If you compile dogecoind/dogecoin-qt yourself, there are some useful files here.
|
||||
|
||||
### [Gitian-descriptors](/contrib/gitian-descriptors) ###
|
||||
Notes on getting Gitian builds up and running using KVM.
|
||||
|
||||
### [Gitian-keys](/contrib/gitian-keys)
|
||||
PGP keys used for signing Bitcoin Core [Gitian release](/doc/release-process.md) results.
|
||||
PGP keys used for signing Dogecoin Core [Gitian release](/doc/release-process.md) results.
|
||||
|
||||
### [MacDeploy](/contrib/macdeploy) ###
|
||||
Scripts and notes for Mac builds.
|
||||
|
||||
### [RPM](/contrib/rpm) ###
|
||||
RPM spec file for building bitcoin-core on RPM based distributions
|
||||
RPM spec file for building dogecoin-core on RPM based distributions
|
||||
|
||||
### [Gitian-build](/contrib/gitian-build.sh) ###
|
||||
Script for running full Gitian builds.
|
||||
@ -44,7 +44,7 @@ Test and Verify Tools
|
||||
---------------------
|
||||
|
||||
### [TestGen](/contrib/testgen) ###
|
||||
Utilities to generate test vectors for the data-driven Bitcoin tests.
|
||||
Utilities to generate test vectors for the data-driven Dogecoin tests.
|
||||
|
||||
### [Verify Binaries](/contrib/verifybinaries) ###
|
||||
This script attempts to download and verify the signature file SHA256SUMS.asc from bitcoin.org.
|
||||
This script attempts to download and verify the signature file SHA256SUMS.asc from dogecoin.com.
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
#!/usr/bin/make -f
|
||||
# -*- mode: makefile; coding: utf-8 -*-
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
# Linearize
|
||||
Construct a linear, no-fork, best version of the Bitcoin blockchain. The scripts
|
||||
Construct a linear, no-fork, best version of the Dogecoin blockchain. The scripts
|
||||
run using Python 3 but are compatible with Python 2.
|
||||
|
||||
## Step 1: Download hash list
|
||||
@ -11,7 +11,7 @@ Required configuration file settings for linearize-hashes:
|
||||
|
||||
Optional config file setting for linearize-hashes:
|
||||
* RPC: `host` (Default: `127.0.0.1`)
|
||||
* RPC: `port` (Default: `8332`)
|
||||
* RPC: `port` (Default: `22555`)
|
||||
* Blockchain: `min_height`, `max_height`
|
||||
* `rev_hash_bytes`: If true, the written block hash list will be
|
||||
byte-reversed. (In other words, the hash returned by getblockhash will have its
|
||||
@ -20,7 +20,7 @@ standalone hash lists but safe to use with linearize-data.py, which will output
|
||||
the same data no matter which byte format is chosen.
|
||||
|
||||
The `linearize-hashes` script requires a connection, local or remote, to a
|
||||
JSON-RPC server. Running `bitcoind` or `bitcoin-qt -server` will be sufficient.
|
||||
JSON-RPC server. Running `dogecoind` or `dogecoin-qt -server` will be sufficient.
|
||||
|
||||
## Step 2: Copy local block data
|
||||
|
||||
@ -38,7 +38,7 @@ will be printed.
|
||||
respectively, to the current time and to the timestamp of the most recent block
|
||||
written to the script's blockchain.
|
||||
* `genesis`: The hash of the genesis block in the blockchain.
|
||||
* `input`: bitcoind blocks/ directory containing blkNNNNN.dat
|
||||
* `input`: dogecoind blocks/ directory containing blkNNNNN.dat
|
||||
* `hashlist`: text file containing list of block hashes created by
|
||||
linearize-hashes.py.
|
||||
* `max_out_sz`: Maximum size for files created by the `output_file` option.
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
# bitcoind RPC settings (linearize-hashes)
|
||||
# dogecoind RPC settings (linearize-hashes)
|
||||
rpcuser=someuser
|
||||
rpcpassword=somepassword
|
||||
host=127.0.0.1
|
||||
port=8332
|
||||
#port=18332
|
||||
port=22555
|
||||
#port=44555
|
||||
|
||||
# bootstrap.dat hashlist settings (linearize-hashes)
|
||||
max_height=313000
|
||||
@ -11,14 +11,14 @@ max_height=313000
|
||||
# bootstrap.dat input/output settings (linearize-data)
|
||||
|
||||
# mainnet
|
||||
netmagic=f9beb4d9
|
||||
genesis=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||
input=/home/example/.bitcoin/blocks
|
||||
netmagic=c0c0c0c0
|
||||
genesis=1a91e3dace36e2be3bf030a65679fe821aa1d6ef92e7c9902eb318182c355691
|
||||
input=/home/example/.dogecoin/blocks
|
||||
|
||||
# testnet
|
||||
#netmagic=0b110907
|
||||
#genesis=000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
|
||||
#input=/home/example/.bitcoin/testnet3/blocks
|
||||
#genesis=bb0a78264637406b6360aad926284d544d7049f45189db5664f3c4d07350559e
|
||||
#input=/home/example/.dogecoin/testnet3/blocks
|
||||
|
||||
# "output" option causes blockchain files to be written to the given location,
|
||||
# with "output_file" ignored. If not used, "output_file" is used instead.
|
||||
|
||||
@ -283,9 +283,9 @@ if __name__ == '__main__':
|
||||
settings['rev_hash_bytes'] = settings['rev_hash_bytes'].lower()
|
||||
|
||||
if 'netmagic' not in settings:
|
||||
settings['netmagic'] = 'f9beb4d9'
|
||||
settings['netmagic'] = 'c0c0c0c0'
|
||||
if 'genesis' not in settings:
|
||||
settings['genesis'] = '000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f'
|
||||
settings['genesis'] = '1a91e3dace36e2be3bf030a65679fe821aa1d6ef92e7c9902eb318182c355691'
|
||||
if 'input' not in settings:
|
||||
settings['input'] = 'input'
|
||||
if 'hashlist' not in settings:
|
||||
|
||||
@ -115,7 +115,7 @@ if __name__ == '__main__':
|
||||
if 'host' not in settings:
|
||||
settings['host'] = '127.0.0.1'
|
||||
if 'port' not in settings:
|
||||
settings['port'] = 8332
|
||||
settings['port'] = 22555
|
||||
if 'min_height' not in settings:
|
||||
settings['min_height'] = 0
|
||||
if 'max_height' not in settings:
|
||||
|
||||
@ -11,5 +11,5 @@ This script should not be run manually, instead, after building as usual:
|
||||
During the process, the disk image window will pop up briefly where the fancy
|
||||
settings are applied. This is normal, please do not interfere.
|
||||
|
||||
When finished, it will produce `Bitcoin-Core.dmg`.
|
||||
When finished, it will produce `Dogecoin-Core.dmg`.
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
set -e
|
||||
|
||||
ROOTDIR=dist
|
||||
BUNDLE="${ROOTDIR}/Bitcoin-Qt.app"
|
||||
BUNDLE="${ROOTDIR}/Dogecoin-Qt.app"
|
||||
CODESIGN=codesign
|
||||
TEMPDIR=sign.temp
|
||||
TEMPLIST=${TEMPDIR}/signatures.txt
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
### QoS (Quality of service) ###
|
||||
|
||||
This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the Bitcoin network. It limits outbound TCP traffic with a source or destination port of 8333, but not if the destination IP is within a LAN.
|
||||
This is a Linux bash script that will set up tc to limit the outgoing bandwidth for connections to the Dogecoin network. It limits outbound TCP traffic with a source or destination port of 22556, but not if the destination IP is within a LAN.
|
||||
|
||||
This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-qt instance which connects to this node and receives blocks from it.
|
||||
This means one can have an always-on dogecoind instance running, and another local dogecoind/dogecoin-qt instance which connects to this node and receives blocks from it.
|
||||
|
||||
@ -44,16 +44,16 @@ fi
|
||||
# ret=$?
|
||||
#done
|
||||
|
||||
#limit outgoing traffic to and from port 8333. but not when dealing with a host on the local network
|
||||
#limit outgoing traffic to and from port 22556. but not when dealing with a host on the local network
|
||||
# (defined by $LOCALNET_V4 and $LOCALNET_V6)
|
||||
# --set-mark marks packages matching these criteria with the number "2" (v4)
|
||||
# --set-mark marks packages matching these criteria with the number "4" (v6)
|
||||
# these packets are filtered by the tc filter with "handle 2"
|
||||
# this filter sends the packages into the 1:11 class, and this class is limited to ${LIMIT}
|
||||
iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 8333 ! -d ${LOCALNET_V4} -j MARK --set-mark 0x2
|
||||
iptables -t mangle -A OUTPUT -p tcp -m tcp --sport 8333 ! -d ${LOCALNET_V4} -j MARK --set-mark 0x2
|
||||
iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 22556 ! -d ${LOCALNET_V4} -j MARK --set-mark 0x2
|
||||
iptables -t mangle -A OUTPUT -p tcp -m tcp --sport 22556 ! -d ${LOCALNET_V4} -j MARK --set-mark 0x2
|
||||
|
||||
if [ ! -z "${LOCALNET_V6}" ] ; then
|
||||
ip6tables -t mangle -A OUTPUT -p tcp -m tcp --dport 8333 ! -d ${LOCALNET_V6} -j MARK --set-mark 0x4
|
||||
ip6tables -t mangle -A OUTPUT -p tcp -m tcp --sport 8333 ! -d ${LOCALNET_V6} -j MARK --set-mark 0x4
|
||||
ip6tables -t mangle -A OUTPUT -p tcp -m tcp --dport 22556 ! -d ${LOCALNET_V6} -j MARK --set-mark 0x4
|
||||
ip6tables -t mangle -A OUTPUT -p tcp -m tcp --sport 22556 ! -d ${LOCALNET_V6} -j MARK --set-mark 0x4
|
||||
fi
|
||||
|
||||
@ -19,11 +19,11 @@ from binascii import b2a_hex
|
||||
|
||||
# key types
|
||||
PUBKEY_ADDRESS = 30
|
||||
SCRIPT_ADDRESS = 5
|
||||
PUBKEY_ADDRESS_TEST = 111
|
||||
SCRIPT_ADDRESS = 22
|
||||
PUBKEY_ADDRESS_TEST = 113
|
||||
SCRIPT_ADDRESS_TEST = 196
|
||||
PRIVKEY = 158
|
||||
PRIVKEY_TEST = 239
|
||||
PRIVKEY_TEST = 241
|
||||
|
||||
metadata_keys = ['isPrivkey', 'isTestnet', 'addrType', 'isCompressed']
|
||||
# templates for valid sequences
|
||||
|
||||
@ -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…
x
Reference in New Issue
Block a user