Guide - P2P network updates

- Peer discovery / IBD start
This commit is contained in:
thephez 2017-11-15 16:46:03 -05:00
parent 68688df0ce
commit fbe53a41c4
2 changed files with 32 additions and 30 deletions

View file

@ -9,23 +9,23 @@ http://opensource.org/licenses/MIT.
{% autocrossref %}
The Bitcoin network protocol allows full nodes
The Dash network protocol allows full nodes
(peers) to collaboratively maintain a
[peer-to-peer network][network]{:#term-network}{:.term} for block and
transaction exchange. Full nodes download and verify every block and transaction
prior to relaying them to other nodes. Archival nodes are full nodes which
store the entire blockchain and can serve historical blocks to other nodes.
Pruned nodes are full nodes which do not store the entire blockchain. Many SPV
clients also use the Bitcoin network protocol to connect to full nodes.
clients also use the Dash network protocol to connect to full nodes.
Consensus rules do not cover networking, so Bitcoin programs may use
Consensus rules do not cover networking, so Dash programs may use
alternative networks and protocols, such as the [high-speed block relay
network][] used by some miners and the [dedicated transaction
information servers][electrum server] used by some wallets that provide
SPV-level security.
To provide practical examples of the Bitcoin peer-to-peer network, this
section uses Bitcoin Core as a representative full node and [BitcoinJ][]
To provide practical examples of the Dash peer-to-peer network, this
section uses Dash Core as a representative full node and [DashJ][]
as a representative SPV client. Both programs are flexible, so only
default behavior is described. Also, for privacy, actual IP addresses
in the example output below have been replaced with [RFC5737][] reserved
@ -41,44 +41,42 @@ IP addresses.
When started for the first time, programs don't know the IP
addresses of any active full nodes. In order to discover some IP
addresses, they query one or more DNS names (called [DNS seeds][/en/glossary/dns-seed]{:#term-dns-seed}{:.term})
hardcoded into Bitcoin Core and
BitcoinJ. The response to the lookup should include one or more [DNS
A records][] with the IP addresses of full nodes that may accept new
incoming connections. For example, using the [Unix `dig`
command][dig command]:
hardcoded into Dash Core. The response to the lookup should include one or more
[DNS A records][] with the IP addresses of full nodes that may accept new
incoming connections. For example, using the [Unix `dig`command][dig command]:
;; QUESTION SECTION:
;seed.bitcoin.sipa.be. IN A
;dnsseed.masternode.io. IN A
;; ANSWER SECTION:
seed.bitcoin.sipa.be. 60 IN A 192.0.2.113
seed.bitcoin.sipa.be. 60 IN A 198.51.100.231
seed.bitcoin.sipa.be. 60 IN A 203.0.113.183
dnsseed.masternode.io. 60 IN A 192.0.2.113
dnsseed.masternode.io. 60 IN A 198.51.100.231
dnsseed.masternode.io. 60 IN A 203.0.113.183
[...]
The DNS seeds are maintained by Bitcoin community members: some of them
The DNS seeds are maintained by Dash community members: some of them
provide dynamic DNS seed servers which automatically get IP addresses
of active nodes by scanning the network; others provide static DNS
seeds that are updated manually and are more likely to provide IP
addresses for inactive nodes. In either case, nodes are added to the
DNS seed if they run on the default Bitcoin ports of 8333 for mainnet
or 18333 for testnet.
DNS seed if they run on the default Dash ports of 9999 for mainnet
or 19999 for testnet.
<!-- paragraph below based on Greg Maxwell's email in
http://comments.gmane.org/gmane.comp.bitcoin.devel/5378 -->
DNS seed results are not authenticated and a malicious seed operator or
network man-in-the-middle attacker can return only IP addresses of
network man-in-the-middle attacker could return only IP addresses of
nodes controlled by the attacker, isolating a program on the attacker's
own network and allowing the attacker to feed it bogus transactions and
blocks. For this reason, programs should not rely on DNS seeds
exclusively.
blocks. For this reason, programs should not rely on DNS seeds exclusively.
Once a program has connected to the network, its peers can begin to send
it `addr`
(address<!--noref-->) messages with the IP addresses and port numbers of
other peers on the network, providing a fully decentralized method of
peer discovery. Bitcoin Core keeps a record of known peers in a
peer discovery. Dash Core keeps a record of known peers in a
persistent on-disk database which usually allows it to connect directly
to those peers on subsequent startups without having to use DNS seeds.
@ -90,12 +88,14 @@ network, forcing a user to wait before sending a transaction or checking
the status of payment.
<!-- reference for "Bitcoin Core...11 seconds" below:
https://github.com/bitcoin/bitcoin/pull/4559 -->
https://github.com/bitcoin/bitcoin/pull/4559
https://github.com/dashpay/dash/commit/2e7009d67b862cf822a1c70e181de6af659a3096
-->
To avoid this possible delay, BitcoinJ always uses dynamic DNS seeds to
get IP addresses for nodes believed to be currently active.
Bitcoin Core also tries to strike a balance between minimizing delays
and avoiding unnecessary DNS seed use: if Bitcoin Core has entries in
Dash Core also tries to strike a balance between minimizing delays
and avoiding unnecessary DNS seed use: if Dash Core has entries in
its peer database, it spends up to 11 seconds attempting to connect to
at least one of them before falling back to seeds; if a connection is
made within that time, it does not query any seeds.
@ -109,11 +109,11 @@ maybe PEBKAC). -@harding -->
Both Bitcoin Core and BitcoinJ also include a hardcoded list of IP
addresses and port numbers to several dozen nodes which were active
around the time that particular version of the software was first
released. Bitcoin Core will start attempting to connect to these nodes
released. Dash Core will start attempting to connect to these nodes
if none of the DNS seed servers have responded to a query within 60
seconds, providing an automatic fallback option.
As a manual fallback option, Bitcoin Core also provides several
As a manual fallback option, Dash Core also provides several
command-line connection options, including the ability to get a list of
peers from a specific node by IP address, or to make a persistent
connection to a specific node by IP address. See the `-help` text for
@ -160,11 +160,13 @@ downloaded, such as when a previously-caught-up node has been offline
for a long time. In this case, a node can use the IBD method to download
all the blocks which were produced since the last time it was online.
Bitcoin Core uses the IBD method any time the last block on its local
<!-- This needs to be reviewed for accuracy. @thephez -->
Dash Core uses the IBD method any time the last block on its local
best block chain has a block header time more than 24 hours in the past.
Bitcoin Core 0.10.0 will also perform IBD if its local best block chain is
more than 144 blocks lower than its local best header chain (that is,
the local block chain is more than about 24 hours in the past).
the local block chain is more than about 6 hours in the past).
{% endautocrossref %}

View file

@ -255,7 +255,7 @@ Processing][devguide payment processing] section for details.
{% autocrossref %}
Bitcoin wallets at their core are a collection of private keys. These
Dash wallets at their core are a collection of private keys. These
collections are stored digitally in a file, or can even be physically
stored on pieces of paper.
@ -332,7 +332,7 @@ 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
shows such a point on the elliptic curve used by Bitcoin,
shows such a point on the elliptic curve used by Dash,
y<sup>2</sup>&nbsp;=&nbsp;x<sup>3</sup>&nbsp;+&nbsp;7, over a field of
contiguous numbers.