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 ...
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
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 ...
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 ...
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
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 ...
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 ...
2
Those hosts are DNSseeds.
When your node starts if it find itself unable to successfully connect to the network within 11 seconds it will query those DNS names which are run by technical people in the Bitcoin community, and get back a lists of recently working nodes.
The use of DNS improves your privacy somewhat since DNS caching can prevent the operator's ...
2
In order for a bitcoin node to start connections with other nodes, it first needs a seed node. A seed node can be any node (listening) connected to the bitcoin network. Once the node has connected to the initial seed node, it can then retrieve information about other nodes in the network and start connections with those ones as well.
The names you are ...
2
Blockchain.info (and other block explorers) do additional processing of the transaction data in order to make it more user friendly to follow the path of coin movement through multiple transactions. Additionally, it seems that whatever you are using to print out the transaction details is not showing you all of the information.
In a transaction, each input ...
2
however payment reversals are a problem with bank wire transfers.
"Different wire transfer systems and operators provide a variety of options relative to the immediacy and finality of settlement and the cost, value, and volume of transactions. Central bank wire transfer systems, such as the Federal Reserve's FedWire system in the United States, are more ...
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
When you run P2P functional tests you are spinning up regtest nodes (running simplified Python code) that connect to your full node (running the full C++ code) to test P2P functionality.
As John Newbery outlines here:
A node is the bitcoind instance. This is the thing whose behavior
is being tested. Each bitcoind node is managed by a Python TestNode
object ...
1
As 0xB10C posts here you can get a peer dashboard to bitcoin-cli that looks like this.
You can get this dashboard by using
watch ./src/bitcoin-cli -netinfo 4
and you can use the -asmap flag too.
This feature was merged into Bitcoin Core in September 2020 so to use it today you will either need to build master or wait for a future major release. (The ...
1
Each full Bitcoin node has what is known as "mempool". mempool is where transactions are stored in preparation for propagation into a proposed block during the mining process.
It's somewhat counter-intuitive but each node has it's own mempool and transactions (as they are posted by BTC users), will be propagated throughout the network and be stored ...
1
how do we ascertain that the bitcoin network [...] is one connected graph
Problems paying people.
The senders and recipients in transactions are people who make contact using non-bitcoin protocols - for example HTTP websites, SMTP email, chat, in-person, by phone.
Therefore if the Bitcoin network were fragmented we should expect that pretty soon a person ...
1
I don't believe this is exposed via the JSON-RPC API.
The easiest method would likely be to have a program monitoring debug.log and look for the best height update messages - they will be a few milliseconds off, since I believe those are only logged after block validation has succeeded, but it is likely the closest you can get to a per-node block receipt ...
1
Pre 0.10 versions synced inventories as it was the way they composed a list of blocks that they then recursively request from the peer. It provides multiple benefits over just asking for all blocks since timestamp x (where is the timestamp of the last block we had).
The biggest one being that it allows you to check the peer is on the same chain as the ...
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
They do attempt to reconnect to previous peers. Each node maintains a database in the peers.dat file of all the peers it has seen, along with whether they are reliable or not.
Once connected to some peers (whether by reconnecting to previously seen ones, or peers source from the dnsseeds), a node will also constantly exchange peer information with other ...
1
The usual way to do this is to use an escrow service that holds the crypto until the bank transfer or payment is deemed complete and irreversible - if the buying party attempts to reverse the payment, the escrow service would release the BTC back to you.
There are organized services that do this, such as LocalBitcoins, LocalEthereum, Paxful, Counter Network,...
1
This only works for unconfirmed transactions. Nodes do not maintian an index of confirmed transactions because this is unnecessary, so you will receive notfound.
1
An address is a human construct, and is meaningless to the p2p protocol - The p2p protocol is only concerned with Bitcoin Scripts.
If you have a raw tx object, you can attempt to find the address for an output by checking if the locking script (scriptPubKey) field matches the format for a known p2sh, p2pkh, p2wpkh, or p2pk address.
If it does, you can ...
1
Block locator hashes are just the hashes of various blocks that you already have. As a new peer, the only block that you will have is the genesis block (the genesis block must be hard coded into your software). So you just send a getheaders message that only contains the hash of the genesis block.
Only top voted, non community-wiki answers of a minimum length are eligible
