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 ...
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 ...
Short answer: Yes, there's a limit but it depends on transaction size, not count.
Basic summary of blocks
Miners are incentivized to put as many transactions into a block as they can with fees. The more transactions, the more fees the miner collects, and that can mean an extra coin on top of block rewards. A block gets bigger as more transactions are added,...
The absolute limit is the size of the block, which is currently hard-coded at 1,000,000 bytes. Each transaction takes up a variable amount of space, but ~250 bytes is about right for a simple (one-input one-output) transaction.
However as soon as a block is solved it is not possible to extend the block by adding in more transactions, as the proof of work ...
The current maximum block size is 1MB (but it could be increased in the future with a protocol change), there is no minimum size per se, but the block needs to have all its components to be valid (check Protocol Specification). Each block needs to have at least one transaction - one paying the miner the reward for mining the block.
Very interesting question, let's see what the smallest transaction we can build is. For it to be minimal it has to be a single input and a single output. The non-segwit part would look something like this:
4 bytes version
1 byte input count
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes ...
The current maximum size of a block is 1 MB. Current block sizes are about half that, so the absolute worse case scenario is that the block chain grows in size twice as fast as it does now. That's not particularly scary.
It's easy to create more than 1 MB of transactions every 10 minutes. If anyone does that, some transactions can't be included in blocks. ...
Only block header gets hashed, and it has fixed size, so the total block size doesn't matter.
From Wiki:Block hashing algorithm
The body of the block contains the transactions. These are hashed only
indirectly through the Merkle root. Because transactions aren't hashed
directly, hashing a block with 1 transaction takes exactly the same
amount of ...
Yes. Let's calculate the minimum size of a block:
The block header must be exactly 80 bytes. This is the only part of the block that miners actually mine; the rest of the block is data that the header securely references.
The transaction count. This isn't part of the block header and it isn't part of the block data, but it's part of the peer-to-peer ...
The block size is the combination of the block header and the list of transactions. Specifically, the block header has these fields:
version - 4 bytes
previous block header hash - 32 bytes
merkle root hash - 32 bytes
time - 4 bytes
nBits (encoded POW target) - 4 bytes
nonce - 4 bytes
So the total bytes for a block header is
4 + 32 + 32 + 4 + 4 + 4 = 80 ...
Yes, they are referring to two different metrics: virtual size (vsize) and size.
The size in [bytes] of a transaction refers to the raw byte length of its serialized format. It is used to measure the data footprint of transactions when relayed on the network or stored on disk.
The vsize in [vbytes] refers to a transaction's weighted size under segwit rules. ...
The blockchain will not reach its maximum capacity by the year 2140, the only thing that is going to change is that all bitcoins (a little less than 21M bitcoins) will have been mined by then and the total number of blocks at that time will be around 6,929,999.
Assuming that a block's maximum size will remain 1 MB then we can estimate that the maximum ...
The block chain length in number of blocks will grow indefinitely with one block being created for 10 minutes on average.
The actual size of the whole chain will strongly depend on the following two aspects:
the number of transactions
The number of transactions in a block determine the size of the block. So, the more transactions are made in the network, ...
The strongest arguments against dynamic blocksizes which can be determined by miner actions, is that they do not necessarily represent the interests of other participants such as users, node operators, or even all miners.
If miners setting the blocksize have good equipment and connections, they may want blocks so large that others are forced off the ...
Miners pick transactions from the mempool which is the queue of unconfirmed transactions. When there are fewer transactions waiting than would fit into a block, the block will not be full. The miner could create more transactions themselves, but that would be only useful if they wanted to send one themselves already in the first place, otherwise they'd just ...
While the block header is always the same size, one component of the block header is the Merkle Root which changes with each included transaction. The Merkle Root is a hash based on a Merkle Tree of all the transactions of the block. Creating the Merkle Tree requires 2(n-1)+1 hashes. The Merkle tree will need to be updated periodically to include new ...
The primary driver of Block size is the number of transactions. Below is the structure of a block and the size of each part in the block.
Magic no, 4 bytes
Blocksize, 4 bytes
Blockheader, 80 bytes
Transaction counter, 1 - 9 bytes
Transactions, -many transactions
The only part of a block with a variable size is the transactions part.
The block size is limited to 1,000,000 bytes 4,000,000 weight units of data. Miners may arbitrarily decide from the available valid transactions which to include. The obvious selection policy would be to optimize for maximum fees collected in the block, for which a simple greedy approach would be to select by the fee rate of transactions, i.e. the amount of ...
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 ...
It has been discussed before, but you're right that the problem isn't nearly as big. There are a couple of reasons for this:
Dogecoin has the same blocksize limit as Bitcoin, but it has ten times as many blocks, and therefore the limit is ten times higher.
As you say, there are fewer transactions on Dogecoin's network.
Hard forks are regarded differently ...
The transaction limit under segwit is derived solely from the transaction weight and the block weight limit of 4,000,000 weight units.
Virtual transaction size was not used for the limit calculation because it is fractional when computed accurately. Bitcoin Core only uses integers in the consensus code and thus transitioned to transaction weight.
SegWit blocks aren't limited in bytes anymore but rather in weight. The maximum weight for a block is 4M. The weight of non-witness data is 4x its number of bytes.
So, yes, decreasing the amount of signature-data frees up some weight which can then be filled by more transactions. Yet those new transactions also contain some non-witness data which is more ...
Currently, only full-nodes, i.e. nodes that have the complete blockchain inventorized relay blocks. Personally, I've recently encountered the first problem, when my Linux partition ran out of storage, yet if I had chosen a bigger partition size, I'd be able to even afford a multiple of the 50GiB easily.
Storage usage: Currently, the blockchain is about ...
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 ...
Block weight is defined in BIP 141 itself:
Block weight is defined as Base size * 3 + Total size. (rationale)
Base size is the block size in bytes with the original transaction
serialization without any witness-related data, as seen by a
Total size is the block size in bytes with transactions serialized as
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 ...
Up until 2017, both BTC and LTC had 1 MB block limit. When SegWit was soft-forked into both protocols, the capacity increased to a hypothetical 4 MB blockweight limit.
But the limit doesn't mean every block that's produced is 1 MB. All it means is that it can not exceed 1 MB. What determines the size of the block is the size of the transactions in the ...
First off, it is worth noting: this paper is not only talking about throughput in the 'transactions/second' sense, it is also addressing the effects of block size and interval on the network's latency (which is an important factor in scaling blockchain networks). The authors define 'effective throughput' as:
Our results hinge on the key metric of ...
Why is there a limit? Why don't we change it?
No matter the number of transactions broadcast to the network, there is an implicit maximum number of transactions that can be included in a block (see @JamesC's answer), and the number of blocks found is regulated by the network's difficulty adjustment algorithm, aiming for an average of one block every ten ...