23

Yes and no. It depends on how you frame the question. It is a block size increase, because you can fit a larger number of useful transactions into a block. If you want to make a useful Bitcoin transaction, it has to be signed so that nobody else can change it. If you can find a way to make the block size limit not count the signature, then you can fit more ...


20

Please note, this answer was written in Februar 2015. The debate has significantly evolved since then, but I haven't gotten around to updating this answer, yet. I'm sorry, this kinda turned out less brief than it started. TL;DR: Very briefly, it is an issue of opposing ideologies: Proponents wish to provide a common good to everyone and believe the ...


18

Why is this limit present? 1. To Maintain Consensus There has to be clearly defined rules about which blocks are valid and which are not for the network to agree. Obviously no node will accept a block that is 10 million terabytes, it would be near impossible to download even if it were valid. So where do you set the limit? And what if one node sets their ...


17

It's not a silver bullet solution, but it's a really good start. As Gavin Andresen has said, Segregated Witness is a poor name. The 'segregated' part of the name is there to denote that there is separation being done. The 'witness' portion of the name comes from the fact that digital signatures are often time called witnesses. Segregated witness splits ...


12

Two issues with Bitcoin's design Scalability of everyone checks everything Bitcoin is a gossip network: P2P nodes connect mostly randomly to each other and pass-on new information to each other as they receive it. That way, information floods through the network quickly: each step further increases the nodes that were informed exponentially (until most are)...


12

Bitcoin has to maintain some balance to be able to maintain the ability to be decentralized. As you've correctly established, this is partly down to making sure that the resource requirements of fully validating the block chain are not unreasonable. There's a push form the consumer side of things to constantly increase the resource usage of Bitcoin for ...


11

Best estimates on effective blocksize with SegWit are 1.6-2.0 MB. Current transactions/second possible are around 3 tx/s. Given that the effective increase is 1.6 - 2.0x, the transactions/second are also the same multiple giving us somewhere around 5-6 tx/s. The second question is harder to answer. There's a reason I wrote "effective blocksize" since ...


8

BIP 100: Jeff Garzik Miners vote on blocksize, constrained between 1 and 32 MB. BIP 101: Gavin Andresen Blocksize increases to 8 MB, and doubles every two years after that. (This is what XT implements.) BIP 102: Jeff Garzik Blocksize increase to 2 MB. (Intended as a fallback that everyone can agree on.) BIP 103: Pieter Wuille Blocksize increase by 17.7% each ...


8

The problem arises from the uneven propagation of information in the network. While the propagation of small blocks is fast, i.e., every miner gets to know a new block approximately at the same time, this is no longer true for large blocks. Large blocks take a lot of time to be forwarded to every node in the network, since this includes miners, these miners ...


6

Ultimately, the consensus rules are set by (the consensus of) those running full nodes, and not by miners. If all Bitcoin node operators decided to switch to different rules for whatever reason, miners have no choice but following, or see their blocks become worthless. Because of that, in the extreme, miners have no say at all. They have to produce blocks ...


6

One problem is that lower block times mean an increased chance of forking, which makes head of the chain, and the system, less reliable. Another problem is that it normally takes a block a few seconds to a minute to propagate across the network. Proportionally that time becomes a lot higher with a decreased block time, giving the original miner and miners ...


6

Emergent consensus Emergent consensus is a protocol upgrade proposal championed by the Bitcoin Unlimited developers. The idea is for each node to broadcast its acceptable block size and to thusly establish a feedback mechanism by which the miners can determine the size of blocks to create. In parallel, rules governing block size would be largely lifted ...


5

I am not aware of any cryptocurrency that has block times of greater than 10 minutes, but I am very familiar with the desire to limit growth of the block chain. Monero recently increased its block time from 1 to 2 minutes in part for the reason you mentioned (but also in part to reduce the # of orphan blocks which occur more frequently when block times are ...


5

Yes, according to Gavin Andresen via Reddit. Even if they didn't to do so, Bitcoin Core already has two other mechanisms which will produce automated alerts as the hard fork approaches: one which will take effect before the hard fork occurs, and one after (as per BIP-50).


5

This is a possible issue. Currently we have a block limit in size of 1Mb although many pools send out 250Kb to make their block propagate faster to avoid orphaned blocks. This gives us a cap of 7 transactions per second, data usage of 6Mb per hour or 144Mb a day, almost negligible amount of bandwidth. Visa on average handles 2000 per second. So looking ...


5

I think, it is worth to mention what Satoshi said about raising the block size... It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete. ...


5

The following assumes that one understands what happens with a soft and hard fork. See all the answers here for a good explanation. Say a new change is implemented in the bitcoin protocol and it requires a hard fork. Full nodes are required to upgrade to the new version (otherwise there are dangers...). What are the dangers of a hard fork? The real ...


4

If you made the block size that large, the rate of network divergence would increase drastically as more and more miners would find blocks while still transferring a block that someone else found. (You have to consider the network latency of propagating 1GB to peers every 10 minutes). There are other problems. Large blocks make it harder to do full ...


4

If there is a block-size hard fork, will the old chain have an advantage? This is partially true, but it is not as grave a problem as the writer would have us believe. It would be much more problematic if the implementation of increasing the block size were done very poorly and discretely (such as just putting out a new client with the MAX_BLOCK_SIZE ...


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

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'd suggest starting here: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/. There's also a SegWit adoption page on the site somewhere. Finally, this article has some details on recent testing: http://www.coindesk.com/bitcoin-scaling-segregated-witness-expected-launch/


4

Currently, there are no BIPS (Bitcoin Improvement Proposals) that seek to increase the 80 byte limit as you can see here. Doing a cursory search on that repository, you can see that only a few mention OP_RETURN at all.


4

So have all the fears of larger block sizes come to bass with Bitcoin Cash? I think most BTC proponents would say no, the fears have not passed. It is not a black/white situation in which a cryptocurrency immediately fails or succeeds, the effects of the engineering decisions may take years to play out fully. For example: in regards to the extra load put ...


3

The blocksize topic correlates directly with the current 7 transaction per second (TPS) ceiling Bitcoin has that was recently brought to light before US Congressional Testimony. https://en.bitcoin.it/wiki/Scalability describes the 7 TPS ceilings under "Current bottlenecks". Ignore block framing data fields, the 7 TPS limit implies that ~4200 transaction (10*...


3

Yes, the maximum number of signature operations per block also need to change. It may change dynamically with the block size limit. The code currently assumes a ratio of MAX_BLOCK_SIZE to MAX_BLOCK_SIGOPS: From https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.h#L59-L60: /** The maximum allowed number of signature check operations in a block (...


3

Your analysis seems to assume unconfirmed transactions will sit in the queue forever. That's not the case. When someone realizes that their transaction will never confirm, they can create a double spend with a higher fee. When the double spend is confirmed, the earlier transaction becomes invalid (barring a chain reorganization). I think it's an open ...


3

As far as I know, they don't have an explicit business model published anywhere. We do know that they are working on: Side chains - a two-way peg that has fixed transfers of value from bitcoin to a sidechain and back. Lightning network - a network of transactions that can be updated relatively quickly (seconds, theoretically) and provably given if the ...


3

It is unlikely that the Blockstream business model requires small blocks. For Blockstream to succeed, Bitcoin will need to succeed independently or there will be limited demand and other devs will increase the block size and the model will fail anyway.


3

The full code for Segregated Witness was released on 19th of April, which to the letter fulfills the requirement. However, apparently some people had understood the first point to mean that it would be in production in April which was not the case. Following the above, an implementation for a hard-fork would be expected to be delivered by 19th of July. ...


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