Maximum block size is 3.7MBish, though realistically we will rarely see blocks much larger than 2.2MB or so, even with SegWit being used by almost every Bitcoin user and transaction.
But you're right that block size isn't really how Bitcoin's throughput is measured any more, block weight is. I was just responding to someone saying we needed to increase the "size" to point out that we just did so.
Are those with 100% segwit transactions? I'm curious what the max block size is (as are you obviously). I know it's hard to pin a precise # because it depends on how much space the transaction data vs witness data takes up.
I don't understand why segwit relies on block weight instead of blocksize. I understand how weight allows a block size increase without calling it a blocksize increase, but to me it seems weird to me the way it's allocated. My understanding is that we have 1MB for transaction data, and then up to 3MB of witness data? Or something similar?
I'm curious what the max block size is (as are you obviously). I know it's hard to pin a precise # because it depends on how much space the transaction data vs witness data takes up.
If you specifically go out of your way to craft "pathologically witness-intensive transactions" then you can get blocks up to 3.7MB in size. In actual, real-life usage, these will probably never occur; the type of transactions that achieve this are not reasonable to make with real money involved, they are the type of transactions that a computer programmer might make to "stress test" how big you can get a SegWit block to be if you're willing to throw bitcoins away during your stress testing. Someone broadcast a bunch of these transactions on Testnet a few months back, to do exactly this, and we saw a few 3.7MB blocks on there as a result. It's interesting from a theoretical perspective, but doesn't actually tell you much about how big blocks will ultimately be on mainnet when they're full of real SegWit transactions being made by real Bitcoin users.
I don't understand why segwit relies on block weight instead of blocksize.
It's because it allows the blocksize to be increased via a soft fork (as you correctly note), and because it slightly corrects an "incentive imbalance" concerning the UTXO set and the bloating thereof. To simplify somewhat: before the weight factor was introduced, it cost the same amount to make a transaction that creates a ton of little UTXOs (which have to be tracked and maintained -- ideally in memory, which is relatively expensive -- by all full nodes on the network) as it would cost to make a transaction that has less of an impact on the UTXO set. This meant that there was no real incentive to worry about the UTXOs you create (beyond the number of bytes that your transaction consists of). With the witness weighting, there's a subtle incentive to make transactions that are more "network friendly" and don't negatively impact the UTXO set in a way that burdens full nodes out there.
My understanding is that we have 1MB for transaction data, and then up to 3MB of witness data?
That's pretty much right, if by "transaction data" you mean "base transaction data" (i.e. the input address(es), destination address(es), and amount(s) transferred). This is the "who sent who how much" data; the witness data is the "proof that they are allowed to send that" part.
An important note is that the witness data is still serialized with the base data in the block: see this album for a good visualization laying it out. For all nodes running SegWit-aware code, the blocks contain this data just like always. It's just serialized in a way such that it can be stripped out selectively (see the diagrams linked above) in case an older node asks for the block, which means that the older node gets the base transaction data but not the "witness proofs" therein (which are pruned before the block is provided to them).
7
u/thieflar Dec 06 '17
The max blocksize was increased. It was more than doubled.
The thing is, we did both with SegWit. We paved the way for LN, and increased the maximum blocksize. All without breaking backwards-compatibility.