11
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. (...
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
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.
...
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
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
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
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 ...
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.
1
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
