Block Size Benchmarks

[jonald_fyookball]

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

That's kinda what I was trying to say, I'm just an end-user, not a developer, but common sense makes me think that by implementing segwit, we're making the use of space more efficient (correct me if I'm wrong), which seems the best and most logical step to take first.

Why is that the best and most logical step to take first?

Why not do the simplest, least risky, least invasive, least controversial thing first, which would be to bump the blocks to 8MB or even 2MB?

The network can easily handle then... THEN maybe we can talk about segwit.

Where did this myth come from that its better to do segwit first?

Well, according to this page, increasing the block size also seems to be somewhat controversial.
https://en.bitcoin.it/wiki/Block_size_limit_controversy

And then this:
https://bitcoinmagazine.com/articles/security-researcher-found-bug-knocked-out-bitcoin-unlimited/
https://cointelegraph.com/news/community-reacts-to-bitcoin-unlimited-bug-calls-for-segwit-activation

I mean if I see all this stuff, as a non-developer, it seems to me that Bitcoin unlimited also has plenty of issues to be worried about.

Anyone who is bright and has been around here a while is familiar with the arguments and most are easily debunkable.

For example "No amount of max block size would support all the world's future transactions "  -- obvious all or nothing
fallacy and not useful to improve now.

"Congestion" concerns can be solved with mempool improvements"  -- clearly not happening and plainly illogical.

"A hard fork requires waiting for sufficient consensus" -- easy to argue that there's no consensus when you're the one blocking it.

It should be clear that Core/Blockstream has their own agenda/roadmap that is decidedly against on chain scaling, and clearly
in opposition to Satoshi's vision, which did include the fact that running a full node will at some point probably only be done by big miners.

EDIT: I don't mean to imply you're not bright -- and I do have a background in computers... so I suppose it may be difficult
to discern truth here if you're non technical. 

[Carlton Banks]

Why not do the simplest, least risky, least invasive, least controversial thing first, which would be to bump the blocks to 8MB or even 2MB?

You must be joking jonald, literal IRL ROFLMAO


"Least controversial"? You cannot be serious

[Kprawn]

Is there some kind of calculation to see how much the transaction speed would go up when Segwit is implemented with 1mb block size?
Bigger blocks will be needed, but to me it seems like it would be far more beneficial if segwit were implemented before changing block size.

Bigger blocks are NOT the best way to increase the transaction rate


Bigger blocks are the most dangerous way to increase the transaction rate, there are OTHER OPTIONS APART FROM BIGGER BLOCKS. We should do the least sensible, most dangerous increases LAST, not FIRST.

That's kinda what I was trying to say, I'm just an end-user, not a developer, but common sense makes me think that by implementing segwit, we're making the use of space more efficient (correct me if I'm wrong), which seems the best and most logical step to take first.

Why is that the best and most logical step to take first?

Why not do the simplest, least risky, least invasive, least controversial thing first, which would be to bump the blocks to 8MB or even 2MB?

The network can easily handle then... THEN maybe we can talk about segwit.

Where did this myth come from that its better to do segwit first?

Well, according to this page, increasing the block size also seems to be somewhat controversial.
https://en.bitcoin.it/wiki/Block_size_limit_controversy

And then this:
https://bitcoinmagazine.com/articles/security-researcher-found-bug-knocked-out-bitcoin-unlimited/
https://cointelegraph.com/news/community-reacts-to-bitcoin-unlimited-bug-calls-for-segwit-activation

I mean if I see all this stuff, as a non-developer, it seems to me that Bitcoin unlimited also has plenty of issues to be worried about.

Anyone who is bright and has been around here a while is familiar with the arguments and most are easily debunkable.

For example "No amount of max block size would support all the world's future transactions "  -- obvious all or nothing
fallacy and not useful to improve now.

"Congestion" concerns can be solved with mempool improvements"  -- clearly not happening and plainly illogical.

"A hard fork requires waiting for sufficient consensus" -- easy to argue that there's no consensus when you're the one blocking it.

It should be clear that Core/Blockstream has their own agenda/roadmap that is decidedly against on chain scaling, and clearly
in opposition to Satoshi's vision, which did include the fact that running a full node will at some point probably only be done by big miners.

EDIT: I don't mean to imply you're not bright -- and I do have a background in computers... so I suppose it may be difficult
to discern truth here if you're non technical.  

Nobody is saying the Blockstream guys are not going into this without an agenda. It should be quite obvious if you get paid to develop something, that

you would get some kind of reward or profit from that money that you invested. There are a bunch of people on both sides, getting a shitload of money

to come up with a solution that would take Bitcoin further.

Do you think it is a good idea, to trust "Big miners" with the sole responsibility to run ALL nodes? { Then we are totally fucked }

[jonald_fyookball]

not necessarily.  But we're far from that point.

let's not lose the plot -- the question was should we do immediately or next.

We could have just raised the blocksize to 2MB but Core blocked that
very popular idea and instead is trying to force everyone down a 1-way
path starting with segwit... so to me its insane that people think we should
"do that first". 

[Hydrogen]

Much thanks for replies. I feel like I learned some things.  

Does anyone know what the drawback is prohibiting blocks with compressed data?

.Zip compression can usually reduce a file to around 1/3rd its size.

I'm sure someone has thought of compressing data in blocks to fit 3MB of data into a 1MB block, without having to change block size.

Is it not worth it, in terms of additional validation & resource consumption, in compressing/decompressing data from genesis blocks onwards to current day transactions?

[Carlton Banks]

We could have just raised the blocksize to 2MB but Core blocked that
very popular idea

Liar



People had the opportunity to accept 2MB 3 times (BIP 102, XT, Classic).

You supported it, all 3 times, jumping from one bandwagon to the next with zero dignity.


All 3 times, no-one in Bitcoin was the slightest bit interested, and the proposed forks withered and died.


But you were here, along with the other havoc-wreaking trolls, trying to work "2MB" into the conversation any opportunity you got, 3, 4, 5 or even 6 repetitions in one post.




It was like the bit in "Being John Malkovich" when Malkovich takes the ride into his own mind, except you were echo-chambering:


"2MB, 2MB? 2 MMMMB! 2MB. 2MB
2MB. 2MB. 2MB, 2MB? 2MB.         2MB!!!!!!


2MB??


2MB!!!!!!!!!!!!!!!!!!!!"