On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote: > 1. It will encourage centralization, because participants of mining > pools will loose more money because of excessive initial block template > latency, which leads to higher stale shares > > When a new block is solved, that information needs to propagate > throughout the Bitcoin network up to the mining pool operator nodes, > then a new block header candidate is created, and this header must be > propagated to all the mining pool users, ether by a push or a pull > model. Generally the mining server pushes new work units to the > individual miners. If done other way around, the server would need to > handle a high load of continuous work requests that would be difficult > to distinguish from a DDoS attack. So if the server pushes new block > header candidates to clients, then the problem boils down to increasing > bandwidth of the servers to achieve a tenfold increase in work > distribution. Or distributing the servers geographically to achieve a > lower latency. Propagating blocks does not require additional CPU > resources, so mining pools administrators would need to increase > moderately their investment in the server infrastructure to achieve > lower latency and higher bandwidth, but I guess the investment would be > low.
1. Latency is what matters here, not bandwidth so much. And latency reduction is either expensive or impossible. 2. Mining pools are mostly run at a loss (with exception to only the most centralised pools), and have nothing to invest in increasing infrastructure. > 3, It will reduce the security of the network > > The security of the network is based on two facts: > A- The miners are incentivized to extend the best chain > B- The probability of a reversal based on a long block competition > decreases as more confirmation blocks are appended. > C- Renting or buying hardware to perform a 51% attack is costly. > > A still holds. B holds for the same amount of confirmation blocks, so 6 > confirmation blocks in a 10-minute block-chain is approximately > equivalent to 6 confirmation blocks in a 1-minute block-chain. > Only C changes, as renting the hashing power for 6 minutes is ten times > less expensive as renting it for 1 hour. However, there is no shop where > one can find 51% of the hashing power to rent right now, nor probably > will ever be if Bitcoin succeeds. Last, you can still have a 1 hour > confirmation (60 1-minute blocks) if you wish for high-valued payments, > so the security decreases only if participant wish to decrease it. You're overlooking at least: 1. The real network has to suffer wasted work as a result of the stale blocks, while an attacker does not. If 20% of blocks are stale, the attacker only needs 40% of the legitimate hashrate to achieve 50%-in-practice. 2. Since blocks are individually weaker, it becomes cheaper to DoS nodes with invalid blocks. (not sure if this is a real concern, but it ought to be considered and addressed) > 4. Reducing the block propagation time on the average case is good, but > what happen in the worse case? > > Most methods proposed to reduce the block propagation delay do it only > on the average case. Any kind of block compression relies on both > parties sharing some previous information. In the worse case it's true > that a miner can create and try to broadcast a block that takes too much > time to verify or bandwidth to transmit. This is currently true on the > Bitcoin network. Nevertheless there is no such incentive for miners, > since they will be shooting on their own foots. Peter Todd has argued > that the best strategy for miners is actually to reach 51% of the > network, but not more. In other words, to exclude the slowest 49% > percent. But this strategy of creating bloated blocks is too risky in > practice, and surely doomed to fail, as network conditions dynamically > change. Also it would be perceived as an attack to the network, and the > miner (if it is a public mining pool) would be probably blacklisted. One can probably overcome changing network conditions merely by trying to reach 75% and exclude the slowest 25%. Also, there is no way to identify or blacklist miners. > 5. Thousands of SPV wallets running in mobile devices would need to be > upgraded (thanks Mike). > > That depends on the current upgrade rate for SPV wallets like Bitcoin > Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we > develop the source code for the change now and apply the change in Q2 > 2016, then most of the nodes will already be upgraded by when the > hardfork takes place. Also a public notice telling people to upgrade in > web pages, bitcointalk, SPV wallets warnings, coindesk, one year in > advance will give plenty of time to SPV wallet users to upgrade. I agree this shouldn't be a real concern. SPV wallets are also more likely and less risky (globally) to be auto-updated. > 6. If there are 10x more blocks, then there are 10x more block headers, > and that increases the amount of bandwidth SPV wallets need to catch up > with the chain > > A standard smartphone with average cellular downstream speed downloads > 2.6 headers per second (1600 kbits/sec) [3], so if synchronization were > to be done only at night when the phone is connected to the power line, > then it would take 9 minutes to synchronize with 1440 headers/day. If a > person should accept a payment, and the smart-phone is 1 day > out-of-synch, then it takes less time to download all the missing > headers than to wait for a 10-minute one block confirmation. Obviously > all smartphones with 3G have a downstream bandwidth much higher, > averaging 1 Mbps. So the whole synchronization will be done less than a > 1-minute block confirmation. Uh, I think you need to be using at least median speeds. As an example, I can only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G has worse range/coverage than 2G. No doubt the *average* is skewed so high because of densely populated areas like San Francisco having 400+ Mbps cellular data. It's not reasonable to assume sync only at night: most payments will be during the day, on battery - so increased power use must also be considered. > According to CISCO mobile bandwidth connection speed increases 20% every > year. Only in small densely populated areas of first-world countries. Luke ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development