4 ms·
Latency in the network is a big limitation. You can run a node at nearly dialup speed, but you'll be endlessly behind on the current state of the network and fa
by RL_Quine 7y ago
Latency in the network is a big limitation. You can run a node at nearly dialup speed, but you'll be endlessly behind on the current state of the network and fairly useless at actually relaying that information to your peers. You really want to be able to process blocks in the order of a couple of hundred milliseconds, which is actually a hell of a lot of bandwidth at peak. In the worst case scenario (no pre-caching at all), 4MB of data in 100ms is 0.32Gbit, and that's not counting the TCP overhead and your actual processing of the data.
The block size for Bitcoin is 4MB, not 1MB, too.
- BubRoss 7y agoWhere are you possibly getting that latency is a problem for 10 minutes in between blocks that miners are deciding? All a node needs to do is basic verification while sending out data. Anyone who has just synced with the chain can see that it takes less than a second per block. Where are your numbers coming from?
- grapehut 7y agoHe's conflating miner-concerns with general node ones. If you're running a miner, every millisecond is money. I operate nodes that takes up to like 20 seconds to get and validate a block (running no-mempool, and slow network/cpu) and it's absolutely no problem for my use case, which is pretty typical (accepting confirmed payments)
- lawn 7y ago> The block size for Bitcoin is 4MB, not 1MB, too. No it's not. Segwit introduced a new concept called block weight that's larger than 1MB, and in practice with normal transactions it gives around 1.4MB.
- grapehut 7y agoYou're both correct-ish. The constraint on blocks is that they must "weigh" less than 4 million units. Most of time blocks that weigh that much are going to be around 1.4MB (or what ever) but in an absolute worst case would be a size of 4MB by a specially crafted transaction