106
Bitcoin clients use several methods to locate other clients. The primary method is a list of nodes from a previous connection to the network. The works very well for everything but your first connection or a connection after a very long period of disconnection.
For the case where you have no previous known IPs or they aren't usable, the primary fallback ...
50
There's a couple of methods the client can use. However, unlike David's very good answer, I'll talk about them in chronological order:
The number one way that clients learn about other clients is by connecting to another client and issuing the 'getaddr' command. The standard client has always had that ability. However, there's a problem with this - how do ...
33
The Bitcoin client has a number of sources that it uses to locate the network on initial startup. In order of importance:
1) The primary mechanism, if the client has ever run on this machine before and its database is intact, is to look at its database. It tracks every node it has seen on the network, how long ago it last saw it, and its IP address.
2) The ...
20
The Bitcoin system doesn't have just one network protocol: Any way of obtaining the blocks is equally valid-- blocks over freenet, over satellite broadcast, over the P2P network, all work just as well and are used in practice. UDP is used with bitcoin too, by the Fibre protocol.
As far the common Bitcoin P2P protocol goes UDP is not an especially good ...
12
Although the torrent protocol requires a central server, you don't necessarily need a central server for a p2p network. The client only needs the IP address of at least one active participant. Connecting to this will give you other IP addresses to connect to.
So the only problem for a p2p network without a central server is: where to find the first IP ...
12
addnode add a node to the list of nodes to connect.
connect only connect to THIS node.
For example, if you are currently connected to the nodes {A, B, C} and then issue…
addnode=D: you'll be connected to {A, B, C, D}
connect=D: you'll be connected to {D}
8
The peer discovery process, in order of priority:
the client attempts to connect to peers in it's local peers.dat database
the client attempts to gain peers from one of four DNS-based seed nodes, hosted by Bitcoin developers
the client gives up
The peers.dat database is filled with information using addr messages, which connected peers use to ...
8
There are some differences between DNS seeding and the IRC method. IRC used to function as a meeting point; essentially a centralized broadcast system to let (all) other nodes know about your existance, but it failed to answer the query "who is online now?". This means that when using IRC as a publically reachable node, you would often see a peak of incoming ...
5
The Bitcoin.org client can be launched with the -connect= parameter.
Simply have it connect to another local node and no outside connectivity occurs.
But once it is caught up to the latest block, the amount of bandwidth is relatively trivial. There's no reason to do this to save bandwidth once a node has been brought current.
5
There are several bootstrap methods. I know of two:
An specific IRC channel is joined by the client. In this channel, connected clients often broadcast their IP, to allow others to find them.
There is a list of hard-coded IPs in the client binary, which the client will connect to bootstrap its network.
4
The connection method depends on the client.
Bitcoin Core will spend up to 11 seconds trying to connect to a peer in its database. If that doesn't work, it will query a DNS server (known as a DNS seed) to get addresses for peers the seed believes are active. If that doesn't work within 60 seconds, it will fallback to one of its hardcoded addresses. Once ...
4
Full nodes are always in a perpetual state of "catching up to the network". This is true if they are just booting up for the first time, have been down for a month, or have been running since the network began. Nothing is fundamentally different about their operation.
The amount of time a node will take to catch up is determined mostly by a) how many ...
4
You can see from the Debug Window ("Peers" tab) that the Bitcoin Core client connects with multiple clients not only with different versions but different implementations.
So to answer your question: No.
3
I had a similar issue. The solution is easy.
Choose the "Server" tab, then randomly right click on a server and choose "Use this as server"
To make sure it works properly, please choose one of these: https://github.com/fyookball/electrum/blob/b32f10a/lib/network.py#L54-L58
I've reported the bug to Electron Cash' developer. Thank you for noticing it!
3
This feature is no longer present in Bitcoin Core. It was removed in 2011.
You can get the same effect by adding multiple addnode= lines to your bitcoin.conf.
3
either I broke some rule, or the other person did; In this case, how does my client find a trusted peer
Your client does not trust any peer. It fully validates the blockchain. In the event of multiple conflicting blocks at a given block height, your node will choose to go with the first block it hears of. However it will still retain and validate all of the ...
3
Nodes have more than 8 connection slots, by default they have 125 maximum connections. There are 8 outbound connections, but can still have incoming connections from other nodes when all 8 outbound connection slots are full. So in your example, the new node can open a connection to any of the other nodes in the network because they all have available ...
3
It does!
There is even a BOLT for it (check out: https://github.com/lightningnetwork/lightning-rfc/blob/master/10-dns-bootstrap.md )
from there you have the following example:
dig lseed.bitcoinstats.com AAAA
lseed.bitcoinstats.com. 60 IN AAAA 2a02:aa16:1105:4a80:1234:1234:37c1:9c9
Christian Decker is maintaining the dns seed list. I even ...
3
When a new node joins the network, it will look up nodes from the DNS seeds. It'll reach out to multiple nodes it hears about and ask them for more peers in turn.
The new node asks each of their peers for their best chaintip and then starts sychronizing the headers of the best chaintip it hears about first. A block header is only 80 bytes (tiny in comparison ...
2
Bitcoin Core doesn't seem to have an option to specify the source port for outgoing connections, so you probably can't assume anything about the source port.
However, if possible, you could configure your router to look for outgoing connections with destination port 8333, which will probably be the port used by most peers.
2
The issue was that bitcoind was discovering my wrong IPv6 address. (It mistook my link IPv6 address for my public one.) I set --discover=0 and set my IPv4 and IPv6 addresses manually with --externalip.
2
I'm not familiar with the specific design of CryptoNote, but in general a cryptocurrency node must have a way of discovering its first node in the network. Once it discovers that first node, it can ask that node for all of the nodes it knows of, then ask those nodes for all of the nodes that they know of, etc. etc. until it knows about every node in the ...
2
Bitcoin is a gossip network and relays transaction or blocks on a best effort basis. Hence you cannot determine the probability of one transaction being seen by the network versus the other.
Now in terms of mining the transactions in a block there are a couple of cases that needs to be considered. For assumption sake let us assume that we are considering a ...
2
So can a blockchain can be shutdown by shutting down power supply across the globe? What would happen in such a case?
If the world's power supply was suddenly cut off, then everything electronic would stop working. The blockchain would be 'frozen', each node would retain its local copy, but be unable to communicate with other nodes, and miners would be ...
2
Each non-pruning full node (peer) stores a complete copy of the blockchain - pruned nodes store a complete copy of the current state, but may not have all historical blocks available.
When a node validates a transaction or a block, it is only validating it against its local view of the blockchain - this means that looking up data is pretty fast, since all ...
1
Simply, NANO uses UDP for blocks which are usually (certainly mostly, but always??) lower than the theoretical size limit of a UDP packet, 65 KB. In Bitcoin's case, transactions ≠ blocks. It's surely inefficient to transfer long data (Bitcoin blocks can be up to 4 megabytes - theoretically) using UDP, and that's also how other services choose between them. ...
1
DNS seeds which give you a list of hard-coded stable nodes.
No, they don't do that and you are reading those answers incorrectly.
The DNS seeders give you a list of random nodes from a set of stable nodes. They are not hard coded and hard coding nodes is against the DNS seed policy. Furthermore, these are used as seed nodes, which means that your node only ...
1
No, it is not possible. IP addresses are not part of the Bitcoin blockchain in any way whatsoever so this data is simply unavailable.
1
A common cause for a node's connection count going down and staying down for a while is IP address changes: It can take a while for knowledge of the new address to percolate in the network.
Otherwise, your prior high count could just have easily been caused by an attack or spy-peers that have since stopped.
It's a bit hard to say since the expected number ...
1
There is no need for a node to "forget" a node. This is not something that is required nor necessary. What Bitcoin Core does in response to a getaddr message (so it sends an addr message) is that it checks its list of nodes. It filters through that list for the things that it recently had a connection to and that it didn't have multiple failed connections to ...
Only top voted, non community-wiki answers of a minimum length are eligible
