Hot answers tagged

14

According the paper 'Information propagation in the bitcoin network.' by Decker and Wattenhofer. The mean time for a node to see a block is 12.6 seconds, after 40 seconds 95% of the nodes have seen that block. This paper goes into some of the causes of propagation speed. Block size is a dominating factor: "For blocks, whose size is larger than 20kB, each ...


6

Given some time for network latency, do messages reach absolutely all connected peers and how long it takes for them to do that? Usually, standard transactions that pay a sufficient fee to be acceptable to most mempools, without any conflicts on the network will reach almost all nodes within a minute or so. However, there is no guarantee whatsoever that it ...


4

This effectively already happens on several levels, though without direct miner interaction. Both Bitcoin Core and the Bitcoin Relay Network have their own implementation of forward preparation for the validation of blocks with the intent of speeding up block propagation as much as possible. One focused on validation latency, one on bandwidth and latency. ...


4

Simply limit the block target (i.e. 10 minutes) to the speed of light (300,000 km/s). Unless there is some wormhole or other unknown to reduce this limit, Bitcoin is safe from honest mining from any planet outside of 180,000,000 kilometers away (300000km/s * 60 sec * 10 minutes) since any miner can't keep up with the blockchain and would get any block at ...


4

Miners have total freedom to choose which transactions they will include in their blocks. Most miners will include any transaction that reaches them (assuming it includes an appropriate fee) but nothing forces them to do so. But if a miner decides, for whatever reason, to omit a particular transaction, or if it's omitted by an accident of timing, no ...


3

It is up to individual mining pools to decide how quickly to include newly received transactions. There are no strict rules here and delays of a few minutes are usually acceptable. Transactions with higher fees may encourage miners to include them in a block ASAP.


3

Let's say humans have finally made a successful colony on Mars, how useful would bitcoin be to transfer value between Earth and Mars? If you're talking about the Bitcoin blockchain in its current form, it will restrict mining to one of both planets. Bitcoin's assumptions include a block propagation time between miners is negligible compared to the ...


2

While FIBRE has done an incredible job in reducing relay times for blocks which are new, many miners additionally have systems by which they relay their own blocks in a single packet and have them queued up to relay on when they start mining the template, not when they find the block. Ultimately, FIBRE's few milliseconds of delay will lose to a single UDP ...


2

If hashes are cheap on Earth, you want them exported to Mars to improve the security of the Martian block chain. Exporting hashes is easy to do in the stateless manner we expect from decentralized Bitcoin technology. Each block on a block chain is protected against modification by the proof of work it shows and by the proof of work shown by the blocks that ...


2

TL;DR: Whatever block interval one employs, another planet with greater mining power will eventually overtake the local blockchain. It would only be possible to lock other miners out by adding low-depth checkpoints. Gedankenexperiment: MarsCoin starts a new blockchain with a 2 minute block interval, they have one Unit of Mining Power [UMP] at their ...


2

It would be radically inefficient for every miner to flood the network with their blocks before they've won the proof-of-work competition.


2

Generally, all full nodes should receive your transaction within a few minutes easily. There are a few exceptions, though. Non-standard transactions will only be propagated once they are included in a block. That also means that if you're sending a segwit transaction, full nodes that are not segwit compatible will only download the transaction after it is ...


2

P2Pool works differently from most mining systems - it aims to have a completed "mini-block" about every 10 seconds, so latency of the p2pool hosting server is critical - milliseconds count. So it absolutely must be in a decent datacentre on a high-quality (aka not-cheap oversold contended junk) network, not on your home connection if you expect ever to get ...


1

No, not necessarily, but mining in both locations is infeasible. As Pieter explained in Is it possible to use bitcoin as interplanetary money/store of value?, exorbitant latency between miners would cause perpetual forks especially when the latency exceeds the targeted block interval. Only one of the two latency-separated mining clusters can be profitable: ...


1

Can we take for granted that if in time period t there were 10,000 connected peers (no new peers connecting, no peers disconnecting), all with good internet connection and hardware, then if every of those 10,000 peers originated one transaction (or any kind of message) to his peers, can we take for absolutely granted that eventually every single one of those ...


1

Transactions are valid before they are added to the blockchain. However, they only become reliable by being confirmed in a block that ends up being part of the heaviest chain. Even if blocks were to have more capacity, the (optimal) waiting time until first confirmation would not be changed by that. At best, more transactions would be confirmed in the next ...


1

Block time and block size are two separate things. Both of them have their own effect on scalability (if you're considering transactions per second as the key factor of scalability) If you zoom out a little and look at the scenarios from a 60-minute point of view, a larger block size (let's say we go from 1 MB to 2 MB) allows twice the number of ...


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

The latency measured is the time it takes for your bitcoind to respond to getblocktemplate requests. It shouldn't matter too much, and the rising time is simply your node learning about more and more transactions and making bigger templates for P2Pool to work on. There's some command line options for bticoind which let you fine tune minimum fees and the like ...


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

Latency of connections between nodes matters when mining because, essentially, a valid block found that reaches the highest number of peers first wins that block height. For example, if miners Alpha and Beta both find within a few milliseconds of each other, their incentive to push that block around to connected clients as quickly as possible is that they ...


1

The store would accept the paper wallet, import the private key and sent the money to a safe address (for which only he has the private key). When it turns out that there was no previous double spend, the store can be sufficiently at ease that the money will arrive. The customer would now present a second paper wallet from which he only shows the address (...


1

A recent paper by Decker and Wattenhofer answers the question with detailed measurements: "Information Propagation in the Bitcoin Network" Link: http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf At current block sizes, the size of the block (via transmission and validation) matters more than the delay in requesting or ...


1

In regards to monitoring the block propagation, you could deploy a largish number of nodes and log new blocks and a time-stamp to a DB as they come in. There is probably some network size estimation requirements, but even a naive implementation should give you a good rough guess.


1

The issue is latency between the p2pool network and the miner. Hosting your bitcoind instance in a datacenter will make little difference unless you move your mining too.


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