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 ...
21
As you correctly identified, there are two types of seed nodes, i.e. DNS seeds and seed nodes. DNS seeds are stored in chainparams.cpp. As of today (September 2021) the following nodes are listed in this file.
seed.bitcoin.sipa.be
dnsseed.bluematt.me
dnsseed.bitcoin.dashjr.org
seed.bitcoinstats.com
seed.bitcoin.jonasschnelli.ch
seed.btc.petertodd.org
seed....
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 ...
5
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 ...
5
No, the DNS seeds are not running a Bitcoin client. The DNS seed nodes only give you a list of IP addresses that are running (or were recently running) a Bitcoin client. In the source code you can see that the DNS seed nodes are contacted only to get a list of addresses.
Source: https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1210
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
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
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 ...
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
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
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
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
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
2017 values are:
seed.bitcoin.sipa.be
dnsseed.bluematt.me
dnsseed.bitcoin.dashjr.org
seed.bitcoinstats.com
seed.bitcoin.jonasschnelli.ch
seed.btc.petertodd.org
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
Yes, all "seed nodes" refer to bitcoin clients known (or suspected) to be more or less permanently available. The DNS seed nodes are those reached via DNS lookup; the others via their IP address. A more thorough answer (including other initial "bootstrapping" connection methods than these hardcoded seeds) has been given to another question.
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
Did you add the hardcoded nodes with addnode or with connect?
addnode=<ip> Add a node to connect to and attempt to keep the connection open
connect=<ip> Connect only to the specified node(s)
So, if you used connect, it will not connect to any but the hardcoded nodes.
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
A node is a machine that is connected to other nodes on the Bitcoin network which sends and receives blocks and transactions with other nodes.
A peer is a node which your node is connected to. Peer is often used interchangeably with node.
A seed node is a node which you connect to briefly in order to find other nodes to actually connect to. When you ...
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
how long on average would it take for a node to discover all other nodes
No normal node ever does this.
A normal node only connects directly with a very small number of other nodes (e.g. max 8 outbound, max 125 inbound) and relies on those other nodes to pass on information to the small number of nodes they are in contact with. This way information diffuses ...
Only top voted, non community-wiki answers of a minimum length are eligible