mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
Guide - P2P network updates
- Peer discovery / IBD start
This commit is contained in:
parent
68688df0ce
commit
fbe53a41c4
2 changed files with 32 additions and 30 deletions
|
@ -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 %}
|
||||
|
||||
|
|
|
@ -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> = x<sup>3</sup> + 7, over a field of
|
||||
contiguous numbers.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue