Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

9

I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes. Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior. When Bitcoin Core receives a ...


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. (...


5

The oldest version that can sync is 0.8.6. This is the version that first used LevelDB instead of BDB. Both the IRC node discovery and the protocol message changes occurred several versions prior.


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

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

A node is only called a peer if you're connected to it. So by definition you are always connected to all your peers. I assume you're asking whether you're connected to every node in the network. The answer is no; most Bitcoin node software implementations only connected to around 8 others. What happens if one is malicious? Bitcoin is trust-minimized by ...


3

This is an excellent question but still probably a little bit under specified. Let me try to give an answer and elaborate. When looking at network bandwidth there are several componants playing into it. The most obvious (and probably most dominant) one is specified in BOLT 07 routing-gossip. There are 4 messages which are used to provide the information ...


3

You can use a "network sniffer" to observe data packets on your local network which are sent from or received by your computer. It will be helpful to study the Bitcoin network protocol documentation so that you can define a filter that will only show the Bitcoin related traffic. A popular choice for Windows is Wireshark, but there are many other options. ...


3

There are significantly more than 10k full nodes on the network. The 10k figure is simply the number of reachable nodes which listen publicly for new connections. There are many more times that amount which do not have open ports. Luke-jr publishes information about nodes his own knows about[1], suggesting there are in the order of 100k nodes. It only takes ...


3

Is all of this effectively 3 transactions? No, assuming you mean '3 on-chain transactions'. It is useful to make a distinction between an 'on-chain transaction' and a payment being sent. To open a LN channel requires one (on-chain) transaction, and to close it requires another. But while the LN channel is open, the participants can send each-other an ...


2

It should work on big-endian systems. The serialization code for integers will byteswap on such systems. This was certainly tested at some point, but I'm not sure how recently someone has. I don't think it will work on systems where int is different than 32-bit.


2

Each full-node will send an INV message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from. In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions: 1) INV message from peer 2) TX message from peer ...


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

As difficulty adjusts automatically, it is indeed possible to run a mostly functional network with the bare minimum hardware required for storage and networking. Naturally, this network will have next to no protection against a 51% attack, as anyone with a faster computer (or computers) will easily be able to outdo your bare minimum hardware. Running it ...


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 ...


1

When your client start the connection with another peer it is outbound, otherwise it is inbound. If you want to be sure that your tor node is properly setup and that other peer can connect to you, check: https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service


1

It is possible that intermediate nodes on the route between you and the payee may track previous payments they have forwarded. If this happens, then the first time the payment_preimage for a payment_hash is revealed, any node along the route could remember it, and if they see the same payment_hash used again in another payment, they would be able to respond ...


1

Nodes that participate in the Bitcoin network run a computer program such as this one: https://github.com/bitcoin/bitcoin, which dictates how everything works. To answer your more specific questions: Yes, bitcoin once used UPnP, here are some more details: https://dirkmittler.homeip.net/blog/archives/3340 but in modern versions it does not (thanks for ...


1

This is implementation dependent of course. Afaik every implementation will try to reconnect, so your first case works (note that your paranoid friend's Tor hidden service isn't used at all). This is common in practice, for any non-public node. In the second case, for c-lightning the address hint will be forgotten on reconnect, so they'll try to reconnect ...


1

The recommended way is to use the -connect option. You can do -connect=0 or -noconnect (they mean the same thing) and Bitcoin Core will not try to automatically connect to any other node.


1

This is not only related to Lightning but remains true for any critical application that you run on your PC when connected to your home network. If your home network is compromised then an attacker can possibly escalate privileges and compromise the machine on which your lightning node is running (as well as other critical applications). Lightning is thought ...


1

Many wallet software obfuscate the information about payment and change address in order to protect the privacy of the user. When you see block explorer websites showing addresses in the outputs as change addresses, they are merely guessing as there is no sure shot way of knowing. Some of the techniques used to identify change addresses are below. I have ...


1

ser_writedata8 does not care about endianness, in contrast to ser_writedata16, ser_writedata32, ser_writedata64. Single bytes don't need to swapped, as 8 bits have one address and there's no way to access specific bits without using BMI or arithmetic operations. Therefore, bit endianness is not important except in bitfields.


1

Is there any way that when requesting the peers list of a node, the node could provide a fake peers list with a number of 'bad' nodes? Certainly. It's impossible to check whether nodes are good or bad without connecting to them. A node can just return whatever IP address and port combinations it wants and the receiver will need to determine for itself ...


1

There isn't any reason that I'm aware of to think that this would be desirable. I'm not aware of any way that it would improve things and it would make the network highly prone to partitioning. E.g. why would the nodes in north america ever have any connectivity to the nodes in europe? Making some number of additional connections to nodes on your LAN would ...


1

Yes, but only in a probabilistic way: If you run many different nodes and try not to leave any node in the network that isn't connected by any of your nodes, you'll be able to track and visualize the relaying of the new blocks. After a while, you'll have the whole network graph, looking at which might obviously show the miners. By the way, using the same ...


1

If you are running -onlynet=onion, there is no need to open any router ports. Perhaps I misunderstand your question. If your chain state is caught up, and bitcoind+Tor is properly configured, you should be serving data to other nodes, even behind an otherwise locked-down home router. What result do you get when running $ bitcoin-cli getpeerinfo | grep ...


1

There is no correlation between hash-power and number of validating full-nodes in the network. Consider the following: Hashrate is necessarily anonymous. Therefore, there is no way to determine how many miners are operating on the network. Furthermore, a miner may operate an arbitrary number of full-validation nodes, from which it creates its candidate ...


1

https://ln.alhur.es/ provides a download link for their historical channel database from this link: https://ln.alhur.es/static/channels.db Data starts June 2019 and provided by https://twitter.com/fiatjaf


1

Here is a simple guide on how to build and run your own home node behind a tor. https://github.com/bitembassy/home-node


Only top voted, non community-wiki answers of a minimum length are eligible