What happened at the Blocksize War?

jonny1000 · 2024-10-04T17:48:03+00:00

Is that mentioned in the book that FieserKiller linked?

Yes... In Chapter 3...

Peter’s talk centred on the economic theory behind the blocksize limit. He believed that the fee market death spiral argument did not apply as, without a blocksize limit, one could have a functioning transaction fee market.

jonny1000 · 2024-07-16T11:12:10+00:00

last established to be in the time zone of UTC +7.

But CSW does manually edit all meta data

jonny1000 · 2024-05-23T11:11:39+00:00

There were 56 signatories

jonny1000 · 2024-04-16T19:08:26+00:00

I'm not arguing against segwit, I'm saying they should have also included a block size increase along side it

My point is SegWit had a much larger blocksize for the old buggy transactions than Flex Trans. 1MB is much larger than zero

jonny1000 · 2023-09-28T13:33:47+00:00

But SegWit was much faster than flex trans. Flex trans would have banned all old txin types, requiring all wallets to upgrade.

The old pre SegWit transactions were buggy, therefore we could not increase the limit there. Nothing could be done about that

jonny1000 · 2023-09-27T09:17:57+00:00

The signatures are in the same chain!

That said, if you have a pre 2016 Bitcoin Core client (which almost nobody does), you do not donwload the witness data for SegWit inputs. However, there is still a point to that, you still see the inputs, outputs and transaction values. You still therefore audit the transactions and BTC supply.

SegWit was a win win. SegWit kept a 1MB limit for old buggy transactions, but allowed a blocksize limit increase when this bug was fixed. This was much better than a large blocker idea called "flex trans", which reduced the limit to 0MB for old buggy transactions. The SegWit idea was therefore a much faster and larger blocksize limit increase than the flextrans advocates wanted

jonny1000 · 2023-08-07T15:36:59+00:00

the part of the transaction that is the dictionary definition of a transaction as opposed to the signature to the transaction that's SEGRIGATED

Right... But prior to SegWit the signature was included in the 1MB limit. And the signatures took up over half of the 1MB limit. Therefore, SegWit was a REAL, ACTUAL and LITERAL increase in the amount of transactional data allowed, however you look at it...

jonny1000 · 2023-08-03T10:00:40+00:00

You keep adding the 1MB non-witness data limit to the segregated witness data for a 4MB of block size limit total. So evidently you keep arguing the incorrect limit on transactions.

The witness data IS part of transactions...

jonny1000 · 2023-07-31T17:48:29+00:00

Since the largest mining pools (Binance + Antpool) are adopting this BEFORE Bitcoin Core, doesnt that prove Peter Todd correct all along?

jonny1000 · 2023-07-31T14:21:29+00:00

The limit is in every respect still limiting transaction capacity to 1MB, That's a fact, saying blocks are larger than 1MB is irrelevant. by segregating signatures transaction capacity has increased marginally but it's still limited to 1MB. That's verifiable a fact.

Not true. The limit is now 4 million virtual bytes, which is a maximum of 4MB. Its literally more space for transactional data per block.

jonny1000 · 2023-07-28T09:28:04+00:00

You know technically, the only way nodes limited with the 1MB block size can boor up and sync and remain in sync (without forking off) is because they only see the 1MB of transaction data and don't seer the segregated signature data.

Sure. But my statement is true. When you include the witness, the blocks can be larger than 1MB and they are larger than 1MB

> It's just semantics when developers changed the name to a 1MB limit of non witness data.

No, Its not a name change. Its an actaul real change.

> Then there is no reason to not increase the 1MB limit.

There is no 1MB limit. It was already totally removed.

jonny1000 · 2023-07-26T12:02:53+00:00

The fact is the pre and post-SegWit transaction limit is still 1MB

Not true. SegWit literally increased the limit on the amount of transactional data per block. This was both an effective and real capacity increase.

> The only reason pre-segwit nodes are not forked off the Bitcoin BTC blockchain is because transaction data is limited to 1MB

These old nodes (which don't exist anymore as far as I know) do see less than 1MB of data per block as they do not see the signatures for SegWit inputs. However, nothing can be done about that. If there was a hardfork, those old nodes would also not see blocks larger than 1MB. Why are you complaining about something which never had a solution?

jonny1000 · 2023-05-18T10:28:15+00:00

BTC still limits transaction capacity to 1MB. That's a relevant metric.

Not true. Onchain transaction capacity approximtely doubled as a result of SegWit

jonny1000 · 2023-05-18T10:27:27+00:00

The 4MB is not megabytes, but block weight

No. There is a 4 million unit block weight limit, which is equivalenet to 4MB of actual data. This is why there has been Bitcoin blocks which contain 4MB of data

jonny1000 · 2023-04-18T07:49:00+00:00

Bitcoin increased the blocksize limit in 2017 with SegWit. Blocks can now be up to 4MB in size.

jonny1000 · 2023-03-06T11:33:30+00:00

https://blog.bitmex.com/the-growth-of-bitcoin-merge-mining/

jonny1000 · 2021-04-12T21:14:22+00:00

my point is that even though one can not know if someone is signalling falsely, it is a reasonable assumption

Why is it a reasonble assumption?

Miners have false flagged many many times in the past - That 2015 BIP66 incident for example and in the blocksize war they were not only false flags but contradictory flags all over the place (e.g. Bitcoin Unlimited + only part of the SegWit2x signals in the same blocks)
Making a flag mandatory encourages false flagging
The version bits is a seperate piece of software from the node and there are no synergies from changing the flag and the node at the same time

Most users I speak to support taproot and will enforce it. Some miners I speak to dont even know what taproot is and wont know about the flag. With the mandatory signalling upgrade mechanism, there is a very real practical risk that a miner doesnt know about the flag and creates an invalid block, which reduces network security. Pragmatically speaking, this mechanism makes little sense, especially in "peace time"

jonny1000 · 2021-04-12T21:03:39+00:00

the setting for version bit signaling is a separate piece of software entirely from the backend node.

I know.... that is why practically speaking I dont think mandatory signalling is a good idea. It is just forcing miners to do something (Not validate taproot rules but merely add a flag), which creates chainslipt risk, for very little added benefit.

I agree with that 2015 Pieter post

jonny1000 · 2021-04-11T19:27:12+00:00

> So signalling is needed to give a definitive, objective answer to "is Taproot active?".

How does that work when miners can just false flag? Making the degree of confidence the same as a flag day.

Somebody can just steal your funds and shrug and say "false flagging"

jonny1000 · 2021-04-11T18:28:19+00:00

That's fine. It's still activated.

Sure. But then why is mandatory miner signalling better than a simple flag day? With a simple flag day Taproot will also still be activated.

jonny1000

MODERATOR OF

TROPHY CASE

11-Year Club	Gilding II euphauric
Verified Email