In this e-mail I'll do my best to argue than if you accept that increasing the transactions/second is a good direction to go, then increasing the maximum block size is not the best way to do it. I argue that the right direction to go is to decrease the block rate to 1 minute, while keeping the block size limit to 1 Megabyte (or increasing it from a lower value such as 100 Kbyte and then have a step function). I'm backing up my claims with many hours of research simulating the Bitcoin network under different conditions [1]. I'll try to convince you by responding to each of the arguments I've heard against it.

Arguments against reducing the block interval 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. 2. It will increase the probability of a block-chain split The convergence of the network relies on the diminishing probability of two honest miners creating simultaneous competing blocks chains. To increase the competition chain, competing blocks must be generated in almost simultaneously (in the same time window approximately bounded by the network average block propagation delay). The probability of a block competition decreases exponentially with the number of blocks. In fact, the probability of a sustained competition on ten 1-minute blocks is one million times lower than the probability of a competition of one 10-minute block. So even if the competition probability of six 1-minute blocks is higher than of six ten-minute blocks, this does not imply reducing the block rate increases this chance, but on the contrary, reduces it. 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. 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. 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. 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. According to CISCO mobile bandwidth connection speed increases 20% every year. In four years, it will have doubled, so mobile phones with lower than average data connection will soon be able to catchup. Also there is low-hanging-fruit optimizations to the protocol that have not been implemented: each header is 80 bytes in length. When a set of chained headers is transferred, the headers could be compressed, stripping 32 bytes of each header that is derived from the previous header hash digest. So a 40% compression is already possible by slightly modifying the wire protocol. 7. There has been insufficient testing and/or insufficient research into technical/economic implications or reducing the block rate This is partially true. in the GHOST paper, this has been analyzed, and the problem was shown to be solvable for block intervals of just a few seconds. There are several proof-of-work cryptocurrencies in existence that have lower than 1 minute block intervals and they work just fine. First there was Bitcoin with a 10 minute interval, then was LiteCoin using a 2.5 interval, then was DogeCoin with 1 minute, and then QuarkCoin with just 30 seconds. Every new cryptocurrency lowers it a little bit. Some time ago I decided to research on the block rate to understand how the block interval impacts the stability and capability of the cryptocurrency network, and I came up with the idea of the DECOR+ protocol [4] (which requires changes in the consensus code). In my research I also showed how the stale rate can be easily reduced only with changes in the networking code, and not in the consensus code. These networking optimizations ( O(1) propagation using headers-first or IBLTs), can be added later. Mortifying Bitcoin to accommodate the change to lower the block rate requires at least: - Changing the 21 BTC reward per block to 2.1 BTC - Changing the nPowTargetTimespan constant - Writing code to hard-fork automatically when the majority of miners have upgraded. - Allow transaction version 3, and interpret nLockTimes of transaction version 2 as being multiplied by 10. All changes comprises no more than 15 lines of code. This is much less than the number of lines modified by Gavin's 20Mb patch. As a conclusion, I haven't yet heard a good argument against lowering the block rate. Best regards, Sergio. [0] https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e [1] https://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/ [2] http://gavinandresen.ninja/time-to-roll-out-bigger-blocks [3] http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white_paper_c11-520862.html [4] https://bitslog.wordpress.com/2014/05/02/decor/ ------------------------------------------------------------------------------ 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