Bitcoin Forum

Just to seek proper clarification, rather than assuming. While going through mempool.space, I noticed that the weight of every mined block never exceeds 4MWU(which in most cases lies around 3.99MWU), and the size always exceeds 1MB, which happens to be the maximum size limits of a block from what I read. Some of the sizes of mined blocks that I saw were around (1.4Mb - 1.5Mb) like the one below.


From the image above, if we are to stick with the rule that "maximum size of a block is 1MB",
1. How come most of the mined blocks always exceed 1MB, like the one above?., Or does the 1MB ranges from 1 - 1.99MB ?.

And again, I observed that the total tx in each mined block varies, maybe due to their various individual sizes, but just to be clear,
2. Does the weight of a block (which doesn't exceeds 4MWU) determines the numbers of tx that could fit into it?.

And lastly, I observed that the block weight is not displayed until a block is mined, but let me ask this
3. Is it possible to have an unmined block, even after the block weight has reached its limit of 4MWU maybe due to mining difficulty or other reasons?.

---

Not really sure of some of the things I've read personally, but I'm always opened to corrections. You might want to also DYOR after reading this.

Ah, you're from the post segwit age  ;)

Blocks used to have a maximum size of 1Mb, but since blocks were always full and fees were high (iirc, that was the reason), there was a big discussion on how to solve this issue. A fork with bigger blocks was made (bitcoin cash) but it didn't gain traction.

What did gain traction was segwit: SEGgregated WITness. Basically, transaction data was still limited to 1Mb, but witness data (usually the signature) was moved to the end of the block, and no longer counted to this 1Mb limit (there is a limit for witness data aswell, but afaik, it's very seldomly reached due to the existing limit of 1Mb for the actual transaction data).
Why did we do it this way? Because new segwit transactions were formed in such a way that pre-segwit nodes still saw these transactions as valid transactions, eventough they had a 1Mb block limit (all the important transaction data was still limited to the first 1Mb), but they basically "ignored" the witness data. Post segwit nodes saw the transaction data AND the witness data, and basically verified the signature aswell... That way, we could have a soft fork and still increase the capacity of the block.

That should answer your first question... As for your second question: the size of the transaction (excluding the witness data) basically determines how much transactions fit into a block... Size is not equal to value... You can create a one input one output transaction with a value of 100 BTC which is smaller in size than a 2 input, 2 output transaction with a value of 0.001 BTC!!! Technically, there's a limit for the witness data aswell, but afaik, this limit very seldomly comes into play... AFAIK, it's usually the 1Mb transaction limit that's the limiting factor for the block size.

For your thirth question: i must say i don't really understand what you're asking... Sure, you can have a mining farm, solve a block and don't broadcast it... But that would be a very bad idear... Don't you want the block reward???

Not always, but it is usually the case. Some exceptions exist, for example: https://mempool.space/block/0000000000000000000169070f8f0650ed43a83e1b22b99542c216c5933682ce

No, it is from few hundreds of bytes, up to 4 MB. Another example: https://mempool.space/block/0000000000000000000515e202c8ae73c8155fc472422d7593af87aa74f2cf3d

No. The legacy 1 MB part determines it. The number of possible created or consumed UTXOs remains unchanged, no matter if Segwit is enabled or not. And if Segwit would allow 1 GB witness, then still, UTXO creation and consumption would be still limited into this 1 MB legacy part.

However, if a single UTXO would handle more than a single user, then yes, you will have more "transactions", even if they would be represented on-chain as a single "transaction".

Well, anyone can create a block template. So, even if you have no mining equipment, then by having just a CPU, and some full node, you can create a block template, and check, which transactions can go to which blocks.

And this is what sites like mempool.space do: they have their own mempool, with all waiting transactions, and then they guess, which block will contain which transaction, based on transaction fee, and transaction size.

This rule is outdated. Since SegWit activation, the limit is 4 million weight unit where some website call it as either 4 kWU or 4MWU. But take note under this limit, total size of non-witness data is 1MB. And regarding multiple units to measure size of TX and block, you may want to read these website pages
https://en.bitcoin.it/wiki/Weight_units (https://en.bitcoin.it/wiki/Weight_units)
https://medium.com/segwit-co/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e (https://medium.com/segwit-co/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e)

TBH, the explanation so far as been brilliant, but I've always assumed that the bigger the value of an input, the bigger the size of the transaction. It's even good that you pointed this out.


There might not be a need to that, since the mWU doesn't necessarily determines the amount of transactions that can fit in.

---

Pretty good examples, especially for the second. 3.96Mb is quite massive.
And I noticed a non standard transaction with zero fees, but has a size of about 3.94mb, which occupies more than 90% of the total transactions in the block, and also confirms that the value doesn't necessarily determine the size like mocacinno pointed out.

---

I find this very helpful. The misconception is pretty straightforward.

This limit no longer exists for taproot transactions and it is now consensus valid for a transaction to fill up an entire block


The throughput of possible UTXOs may not have changed but the throughput of transactions with non-trivial scripts has. Now we can construct a transaction with a 2 of 3 multisig and spend it without including anything in the scriptsig. Reducing transactions with complex scripts to an anyone-can-spend transaction with a small scriptpubkey does increase the transaction throughput for the most common use-case for example, which is just paying to a public key hash (https://dune.com/murchandamus/bitcoins-utxo-set)

See size.txt (https://loyce.club/blockdata/size.txt) for the size of all blocks.

I was confused at first I didn’t check the label… from which block id was segwit introduced??
figured this out "481,824"...

This is misleading because it sounds like two routes were taken to scale "bitcoin" and one of them was "bcash" whereas in reality many people have been creating "copies of bitcoin" pretending they are one of those "routes" to solve issues bitcoin is facing, one of those shitcopies were bcash.

It also didn't gain any traction because it was an altcoin created by copying bitcoin's source code and blockchain like about 2 dozen others at the time (bgold, bsliver, btx, ...). Bcash made more noise than others because it had a "celebrity" advertising it (Roger Ver) and a major bitcoin website listing it (bitcoin.com) and scamming people by calling it "real bitcoin". Otherwise there is difference among these CopyCatCoins.

Any "bitcoin" fork needs to be voted in by the miners and if it gains supermajority, it can be categorized as one of those "routes" to take.

Witness, similar to any other part of the tx (like version, output script, locktime, etc.) is part of the transaction and is included in the transaction itself not the "end of the block".
Basically this structure:
turned into this:

The 1 MB limit is no longer part of the checks performed in the consensus rules. We are now computing "weight" and the limit on that weight is 4 MB. The way weight is calculated means the stripped block will have <= 1 MB size.

Weight of the transaction...

sure, the weight is calculated now, but it still boils down to a size of transactions minus witness data being less than 1Mb. If the size of the transaction data minus the witness data would exceed 1Mb, old nodes could no longer verify blocks, and it would no longer be a soft fork... But you guys are right, i should have payed more attention to semantics... The thing was that i was trying to keep this as simple as possible, and as soon as you bring along terms like vbytes, weight, weight units things get a bit more difficult for newer members.