7

It depends significantly if you're asking about the average, N-th percentile time, or a worst case including the possibility of maliciously constructed blocks. Nodes use the first copy of a block they receive, obviously. A consequence of this is that block propagation along a slower path will be outpaced by block propagation on a faster path. As a result, ...


7

The code isn't optimal especially not on the merged mining side. Currently there is no optimal method to handle both block chains without a more advanced miner-pool communication protocol. Excluding merged mining issues, latency is a large factor. When a block change occurs every single miner's effective hashing power is zero until they begin working on ...


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

Yes, data has shown, that GFW has effects on packet propagation, but not much. The major cause of delay is distance. As you can see here, the median propagation time is comparable for various locations.Complete details can be seen here. Interestingly, this issue highlights that more than the effect of GFW, it is the effect of large blocks propagation delay &...


4

I don't know what this frequency analysis technique would do, so this answer corresponds to the second question you asked: Blockchain.info connects to hundreds of nodes: http://www.blockchain.info/connected-nodes The IP address Blockchain.info shows is the address of one of those nodes that they happened to be connected to which first saw that transaction....


3

Every node in the Bitcoin network acts independently. When a node hears about a new block, it will perform a series of checks to see if it is valid according to the network's rules. If the block is valid, the node adds it onto it's local copy of the blockchain, and broadcasts the block to the other nodes its connected to. If the block isn't valid, the ...


3

It is trivial for solo miners to use tor to hide IP adresses. This defeats mentioned above frequency analysis attack.


3

The most critical factor is this: When a new block is discovered on the Bitcoin network, how long does it take the pool to get a new work unit based on the new block to the vast majority of its clients? This is determined by three factors: 1) Long Polling: If you care about performance, you have to support LP. It's that simple. 2) Network Latency: If the ...


3

The waste ratio you are talking about is different from the one mentioned there. What you are talking about is the difficulty: if the network's total hash rate is X hashes/second, then the difficulty is set such that it requires 600*X hashes to create a block on average. This does not mean that separate miners are wasting their work, because if the ...


2

There is a lower bound: Blocks must include at least one transaction, the Coinbase. ;) The advantage of a smaller block has been somewhat overstated in the past, as it usually doesn't matter much, especially since the relay network got improved with Compact Blocks, a compressed block format that significantly reduces the peak bandwidth required to propagate ...


2

Some pools may still use the 250 KB cap for faster block propagation and reduced chance of orphaned blocks. If one block is orphaned you probably have to mine for 10 years to recover that loss with the extra transaction fees from mining larger blocks. However I think many pools use a max size above 250 KB. The reason most of the blocks are smaller, even ...


1

Miners are incentivized to always mine at the longest valid chain tip. If there were incentives to not mine on the longest known chain, then we would expect the network to be unable to maintain consensus on the blockchain's state. And without that, it would be impossible to build a reliable financial system. So it isn't about 'miners conceding a shorter ...


1

First off, it is not impossible. Bitcoin nodes are not validating thousands of transactions per second. They are actually processing less than ten per second, which is perfectly reasonable for even slower computers. Second, not all Bitcoin nodes validate all transactions. What you are likely referring to are "full nodes", which are basically nodes that ...


1

To start with, nodes no longer mine in Bitcoin. Bitcoin's difficulty is too high, and mining is now done via a series of mining pools, which distribute the work to tens of thousands (if not hundreds of thousands) of ASIC miners. Mine right away. Miners do start mining a new block as soon as the previous one is discovered, regardless of if it was ...


1

It is impossible to know how many nodes each node is connected to or has in its peers table. This information is not broadcast publicly and the information that is available publicly (by asking a node) is not representative of what the node actually knows.


1

The y axis of the plot shows the delay/size, that is, the number of seconds of delay produced by each kilobyte of data of the block. Therefore, as blocks get bigger, the overall delay of the block also gets bigger. However, the delay per kilobyte of data approaches a constant value. This is produced because the overhead generated by the bitcoin protocol ...


1

A bigger amount to the miners won't make them mine the block faster. It will only increase your chances to be in the next block AKA have your transaction confirmed faster. In short the answer is no, the sender has no control when the next block will be mined, nor can they influence that with higher fees on their transaction. "Miners" try to solve a ...


1

Yes, compact blocks are still usually faster even when there is a getblocktxn round trip. The reason for this is because all that needs to be sent in that case is the requests for the missing transactions and the missing transactions themselves. Although the time is increased by another round trip in this case it is only a single round trip and there is ...


1

Imagine you make a double spend and then you try to propagate a block that contains only your second transaction This would mean you found a proof-of-work before everyone else, which is a very difficult thing to do without a significant amount of hashing power. Miners, in fact, publish very small blocks (literally, just the coinbase tx) all the time. ...


1

Then full node requests the transactions missing from the miner. Is this correct? No. All transactions (including the missing ones) are already encoded into the IBLT (that the miner sent). It's a little like a Sudoku puzzle. The miner sends you an empty sudoku with only the totals filled in. You throw in the transactions that you already know. And then ...


1

Compact Blocks in Bitcoin Core provides similar functionality (see BIP 152 for spec). The main improvement is in the way it gets rid of bloom filters, as those add a DoS attack risk. There's a bit more in commentary from nullc (Gregory Maxwell) in this thread on Reddit


1

Gavin Andresen wrote a bit on the topic here: O(1) Block Propagation. Essentially, he is implementing the conclusion from your answer, a way to get around resending all transactions when propagating a new block. He is working on implementing Invertible Bloom Lookup Tables to use for set reconciliation. IBLT excel at comparing sets of significant overlap, ...


1

"Immature" blocks should be valid, but they require 100-120 confirmations before they can be spent. On testnet this may take up to 40 hours or so. If you have the block hash (it should be in debug.log if not elsewhere), you ought to be able to find these blocks on http://blockexplorer.com/testnet and see them linked into the block chain. "Orphaned" blocks ...


1

You make one call to bitcoind using getblocktemplate to get a template for a block. Then you can generate all the work you need. In the fantasy world you would find a block instantly. You submit this block and get another template to create the next block. You would be generating hundreds or thousands of blocks per second. The only thing to slow you down ...


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