diff --git a/_includes/devdoc/guide_p2p_network.md b/_includes/devdoc/guide_p2p_network.md index cd51e718..1aaec6ff 100644 --- a/_includes/devdoc/guide_p2p_network.md +++ b/_includes/devdoc/guide_p2p_network.md @@ -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. 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) 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. + 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 + + +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 %} diff --git a/_includes/devdoc/guide_wallets.md b/_includes/devdoc/guide_wallets.md index 1d1ec1eb..e707c259 100644 --- a/_includes/devdoc/guide_wallets.md +++ b/_includes/devdoc/guide_wallets.md @@ -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, y2 = x3 + 7, over a field of contiguous numbers.