59
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 ...
23
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 ...
13
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}
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 ...
11
Bitcoin Core sync very slow
Bitcoin Core is capable of full sync in a relatively short period of time depending mainly on the hardware.
Most of the work done is not actually downloading the blocks, it is validating them and every transaction that they contain. It not only depends on downloading the blocks but also on the quantity and complexity of every ...
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 two ways by which bitcoind connects to peers.
The default is purely outbound connections - the node will use DNS seeds, as well as its own database of previously seen peers, and attempt to establish connections to them as needed (upon startup, or when existing connections are closed).
Allow incoming connections allows you to return this favour - it ...
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.
4
As Nate Eldredge said, the block that you received is a Bitcoin Cash block which is invalid to Bitcoin Core. Because of this, your node banned the Bitcoin Cash node that sent you the block. However, it seems like the way that you have your node set up is that the gateway is acting as a proxy instead of passing through the connections. Thus Bitcoin Core ...
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
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
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 ...
3
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
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
As @Anonymous said Electrum servers listen on port 50002 so that's what you are seeing here. Your phone is connecting from a random local port to remote 50002 on the servers.
Electrum gets blockchain data from electrum servers run by volunteers. These servers see your addresses + transactions but they don't see your private keys or seed. So you lose ...
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
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 ...
2
Your node will just ask its peers for blocks. It actually does the same thing it does for the initial sync. It starts with what it currently considers to be the chain tip (in initial sync, that's the genesis block). From there, it connects to other nodes and asks those nodes for more block headers starting with the block at its own chain tip. Typically, that ...
2
Addresses for outbound connections are largely chosen at random. The filtering of addresses comes at the time the addresses are first received by the node before they are added to the address database. This filter checks what services the nodes offer, what network they are on (e.g. IPv4, IPv6, TOR), and the time that they were reported to last be seen. Your ...
2
If the nodes are running different versions then communication cannot continue.
That is incorrect. If two nodes interact which have different versions, they just communicate using the lower of the two versions.
1
Sites like bitnodes run their own lite nodes which are crawlers. These nodes connect to other nodes and only receive data from those nodes. When a node receives a new block, it will send it to the nodes it is connected to. If one of these is a bitnodes crawler, it can record that it received a block at height X from the node. In this way it can track the ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
