23
First the "why it matters":
Fibre (Fast Internet Bitcoin Relay Engine) is a protocol which attempts to deliver Bitcoin blocks around the world with delays as close to the physical limits as possible.
This is very important because Bitcoin mining is intended to be a fair lottery: If you have x% of the hashrate you should find x% of the blocks, on average. ...
22
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....
15
Someone wrote a Bitcoin protocol decoder for Wireshark, several years ago. I assume it was included in the Wireshark distribution.
Wireshark simply knows about the Bitcoin protocol. There is no magic involved.
15
In my view, the main implementation detail to be worked out with Dandelion
is ensuring that there are no new DoS vectors introduced.
In the existing transaction relay model of Bitcoin Core, transactions that
do not make it into a node's mempool -- a proxy for what we expect to be
(eventually) mined -- do not get relayed to other nodes.
In the Dandelion ...
11
Jon Atack answered this on Twitter.
Configuration and setup
First install and start I2P (version 2.35 or above).
$ apt install i2pd
$ systemctl enable i2pd.service
$ systemctl start i2pd.service
In your bitcoin.conf file add (I will assume you run Bitcoin Core v22+ and want to use both Tor and I2P but remove debug=tor and onlynet=onion if not interested in ...
6
When a node requests one of it's neighbours for a list of it's peers, that node responds with a list of all of it's neighbours.
No it doesn't. It responds with list of nodes that its aware of being claimed exist. It likely isn't connected to any of the nodes it returns and probably has never connected to many of them. Many of them may not even be real. (...
6
Best place is https://getaddr.bitnodes.io/nodes/leaderboard/
Nodes are rank according to various parameters
6
To run a Bitcoin full node you don't need to have a static IP address as when your IP address changes you should still be able to find peers and connect to them. However, if you want to maintain the same peers getting a static IP address is a good idea. Your connection to existing peers will drop if your IP address changes and you will either reconnect to ...
6
While nodes are set to be listening by default, the vast majority does not permit inbound connections either because listening has been disabled or their network setup doesn't make the necessary port accessible. There seem to be in the range of 8-10k listening nodes, while estimates for non-listening nodes range in 60-400k depending on the source.
Next to ...
6
Full nodes have absolutely no use for the mempool message, it is vestigial from bip35 and has had a history of causing privacy leaks due to its poor implementation. It has previously been used to bypass transaction trickling, or just cause an enormous amount of waste data transfer. Modern versions of Bitcoin Core do not ship with bip37 enabled, which means ...
6
It sends exactly one block. If you want to send multiple blocks, you need multiple messages.
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
5
Bitcoin is a peer-to-peer gossip flood network. Whenever a Bitcoin participant creates a transaction, their wallet software submits it to its peer nodes. These peers then relay it to their peers in turn. The transaction floods through the network and reaches most nodes. Eventually, the transaction is included in a block which makes the transaction part of ...
5
No, you cannot know this. But in general, since you're a normal, honest, node presumably, the most likely answer is "none".
4
The network used today isn't actually the same as the original design, which did not have an inventory system at all, every transaction and every block was sent to every peer indiscriminately. Compact Blocks was also added to remove redundancy in block transmission and reduce latency, as blocks predominantly contain transactions which have already been ...
4
It isn't as simple as "sending sequentially" or "sending in parallel". Each connection is its own socket and the kernel performs packet scheduling. The Bitcoin protocol doesn't have any acknowledgement. When a node sends a message it hands it to the TCP stack which often will just immediately accept the whole message. It's then up to the kernel to send it ...
4
It returns some plausible peers, not all of its peers.
You have no way of knowing any specific details about them, if they’re sybil, not operational, or not useful. The software tries to work out what is most optimal for outgoing connections based on its own criteria, and doesnt trust this information for anything besides a hint towards where other peers ...
4
FIBRE is valuable as it allows for miners to extremely quickly propagate their blocks to other miners and to the rest of the network. The goal of FIBRE is to reduce latency in block transmission. Miners will thus waste less time on trying to mine a block that has already been found so they will reduce their stale block rates and be working on the latest ...
4
The help text is your friend:
Requests that a ping be sent to all other nodes, to measure ping time.
Results provided in getpeerinfo, pingtime and pingwait fields are decimal seconds.
Ping command is handled in queue with all other commands, so it measures processing backlog, not just network ping
After you use ping, you may see a new field, pingwait, in ...
4
Bitcoin needs approximately sundial time accuracy to operate. Computers have their own free running clocks which provide more than enough accuracy in the absence of other references, and NTP sources which are terrestrial rather than GPS based.
nLockTime and other internal tools are not based on local clocks, as there’s absolutely no guarantee that anybody in ...
3
First, let me clarify that the Erebus attack does not require rebooting the victim. It is only for speeding up the attack process. The attacker can patiently wait for the existing legitimate connections to expire and occupy them.
Coming back to your question, I guess you suggested to prioritize reconnecting the current outbound peers among all tried IPs.
...
3
Do full-nodes process all txs before broadcasting the new blockheader?
It depends. For nodes having protocol version 70015 and higher, the peer will announce the compact block even before full validation of the transactions contained in the block. However, the header has to be conform with the difficulty requirement. For nodes using protocol version 70015 ...
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
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 ...
3
The getheaders message allows you to list multiple block hashes. So instead of just putting the current chain tip, you can insert multiple block hashes. Responding nodes will see if any of those hashes are in its main chain and start sending headers from there. Since reorgs tend to be small, you could put the most recent 10 block hashes and it should be ...
3
Adding more advanced prediction of what transactions are useful to prefill was probably intended as a TODO when Compact Blocks were implemented, but to the best of my knowledge, nobody has worked on it since.
It is worth pointing out that Compact Blocks in practice (and in non-adverserial situations) works extremely well. On my own long-running node, as of ...
3
A security assumption is that nodes are connected to at least one honest peer. If all of their peers are malicious, is is perfectly feasible for them to withhold information about certain blocks or transactions from a victim. Look up eclipse attacks, if you want to know more about this style of attacks, or the mitigations that exist against them.
2
The mempool is just a temporary store of unconfirmed transactions. Each node's mempool is not synchronized, and in fact a node could choose to not keep a mempool at all. So no node needs to verify whether anyone else has a transaction, before deleting it from their memory. Miners will choose transactions from their mempool, to build new block templates that ...
2
The problem is because the netgroup of the feeler connection was not properly handled.
Check further pull requests and fixes here: https://github.com/bitcoin/bitcoin/issues/15484
2
Blocks cannot be modified because the next block contains a hash of the previous block's header. Any change to a block would result in a change to the header, and thus, change its hash, requiring all blocks which succeed it to also be modified because their hashes would no longer be valid. It isn't possible to rebuild all of the blocks because it requires ...
Only top voted, non community-wiki answers of a minimum length are eligible