question

[Carlton Banks]

Let's start simple. Can you give a rational argument against immediately raising the block size cap to 8MB?

no, there is no "actual" answer to such nonsense.

That says about all I need to hear to understand your position. Thanks!

You asked two questions, I answered a different question to the answer which you're attributing it.

You people are a fucking disgrace

[1715029365]

1715029365

[1715029365]

1715029365

[1715029365]

1715029365

[Klestin]

If you wanna play this game I can: it will effectively retire a number of nodes from the network.

What are you basing the statement on? We currently have a 1MB cap, yet we do not have 1MB blocks.  Raising the cap has no causative effect on the block size - it will only go up when the volume of transactions increase enough.  Speaking as one full node operator, I can say that the incremental cost is entirely trivial, and my node will remain.

It is a slippery road opening the door for more unadvised decision encouraged by populist movements.

I asked only about a change to 8MB.  Further changes would have to be approved on their own merits.

The effects on securty and the network are unknown and have yet to receive any legitimate testing.

Actually, it's well tested.  When I first started using Bitcoin, it had no cap (or actually had a 32MB cap due to code limitations).  

[Klestin]

You asked two questions, I answered a different question to the answer which you attributing it.

You people are a fucking disgrace

Ad hominem so quickly?  You need to pace yourself.

I asked only one question. "Can you give a rational argument against immediately raising the block size cap to 8MB?"

One that you still haven't answered.

[Carlton Banks]

You asked two questions, I answered a different question to the answer which you attributing it.

You people are a fucking disgrace

Ad hominem so quickly?  You need to pace yourself.

I asked only one question. "Can you give a rational argument against immediately raising the block size cap to 8MB?"

One that you still haven't answered.

You asked 2 questions and pretended I provided the answer to the one that suited you best. Hence your arguments and you are a literal disgrace, and so any perceived ad hominem is addressing the meta-argument accurately. Fuck off.

[Klestin]

You asked 2 and pretended I answered the one that suited you best. Hence your arguments and you are a literal disgrace, and so any perceived ad hominem is addressing the meta-argument accurately. Fuck off.

I don't suppose you can quote this mythical second question, can you?

[Carlton Banks]

You asked 2 and pretended I answered the one that suited you best. Hence your arguments and you are a literal disgrace, and so any perceived ad hominem is addressing the meta-argument accurately. Fuck off.

I don't suppose you can quote this mythical second question, can you?

It's clear that I've lost patience with your dishonesty, so no. Respect my wishes and fuck off.

[Klestin]

It's clear that I've lost patience with your dishonesty, so no. Respect my wishes and fuck off.

I thank you for the amusement you've generated for me today, and will happily do so.

[DooMAD]

Let's start simple. Can you give a rational argument against immediately raising the block size cap to 8MB?

If you wanna play this game I can: it will effectively retire a number of nodes from the network. It is a slippery road opening the door for more unadvised decision encouraged by populist movements. The effects on securty and the network are unknown and have yet to receive any legitimate testing.

There are plenty of arguments really.

Or we could just stop playing games and you could tell us exactly what increase in blocksize you would be comfortable with.  If, as I suspect, the answer is zero, please then admit that your position is untenable.  Because even if you do support the notion of forcing a significant number of transactions off-chain via lightning network or something similar, LN itself still needs a larger blocksize to function.  A larger blocksize is almost unavoidable and none of your arrogant "only I'm smarterer enough to have a valid opinion" troll BS is going to change that.  Introducing LN to the wider Bitcoin ecosystem is also a much larger change than a moderate blocksize increase.  The effects on security and the network with LN are also unknown and is also yet to receive any legitimate testing because it doesn't exist yet.

You can play the "slippery slope" card that it will lead to centralisation, but the rest of us can play the same slippery slope card that a permanent 1MB blocksize will lead to an elitist, niche safe-haven that only benefits early adopters.  One way or another, it's almost inevitable the blocksize is increasing because the pressure for it to happen will never go away unless another solution is found.  A small handful of people who think that Bitcoin is here solely to benefit them and them alone have no way of stopping a global populace looking for an alternative to the corrupt banking system.  The numbers are simply against you.  You can either contribute to the blocksize increase in a constructive fashion, or just keep acting like a belligerent troll (but we've already got iCEBREAKER for that, so it seems a tad redundant).

Most of us would now like to have a sensible discussion on where to strike the balance between decentralisation and capacity because we recognise that both are important.  If you want to keep having the same tired old conversation about how decentralisation is the only thing that's important (because it provides tremendous benefit to you) and capacity is somehow irrelevant (because it doesn't benefit you), go talk to some people who actually want to listen to it.  
 

[alani123]

Semantic quibbling aside, let's address what alani clearly meant:

Why would anyone want to force the blocksize limit expanding at pre-set dates. Now, give a sensible reply to what was intended.

It's hardly semantic, and I'm not at all sure what he meant. Many of the arguments against raising the cap only make any sense if understood as an argument against raising the block size.

Let's start simple. Can you give a rational argument against immediately raising the block size cap to 8MB?

There's no indicator that an 8Mb limit could be of use at the moment. One big argument for raising the limit was that more transactions per second could start being handled. Which in theory could become possible under a larger block size limit but if you think about it, even right now bitcoin isn't making full use of the 1Mb limit. Increasing the block size limit to a small number at first could help study the plausible effects such a change could have with minimum risk. If you look at it carefully, the Chinese pools have been Vetoing Mike hearn's proposals for months now. BIP101 came out with 8Mb blocks after pools accounting for ~ 60% of the hashrate at the time united against the then 20Mb blocks proposal. Now, as BIP100 started becoming more popular, more miners are showing support towards it since it's considered a less radical and more modest proposal by far. Prior to showing support for BIP100, most of those pools were showing support for 8Mb blocks, but not BIP101. It now seems like instantly increasing the block size limit to 8Mb doesn't look as attractive to miners.

In short, an 8Mb block limit could:

• Have devastating effects on the fee market

Since there's more space in each block, this space is now less valuable, fees might not be zero, but they'll be lead down to the minimum and competitiveness for fast transactions will be dead.

• Bring nodes offline and make pools/miners less reliable

The change would increase bandwidth consumption as well as HD space required to run a full node. There are many nodes that run on non-optimized hosts, if they suddenly start sucking up more of the bandwidth and HD space it's safe to assume that many will go offline. Also, pools running on weak networks would be more prone to orphaned blocks because of the blocks being harder to propagate.

I've seen people arguing that in case the block limit was raised, it wouldn't be put to use immediately as well that it would handle transaction floods better. But what if it destroys the fee market on the moment it's implemented? Sending out a meaningless transaction would now be cheaper. Plus, if nodes and miners were available exclusively to those with unlimited hardware and bandwidth, centralisation is unavoidable.

[Carlton Banks]

Semantic quibbling aside, let's address what alani clearly meant:

Why would anyone want to force the blocksize limit expanding at pre-set dates. Now, give a sensible reply to what was intended.

Let's start simple. Can you give a rational argument against immediately raising the block size cap to 8MB?

In short, an 8Mb block limit could:

• Have devastating effects on the fee market

Since there's more space in each block, this space is now less valuable, fees might not be zero, but they'll be lead down to the minimum and competitiveness for fast transactions will be dead.

• Bring nodes offline and make pools/miners less reliable

Mining basically becomes less and less economically viable over time under BIP101. Mining would need subsidising somehow, and so only those that can afford to do that will mine (i.e. losing money). The most concerning outcome would be large miners staying in the industry only to maintain control of the hashrate.

[brg444]

Semantic quibbling aside, let's address what alani clearly meant:

Why would anyone want to force the blocksize limit expanding at pre-set dates. Now, give a sensible reply to what was intended.

Let's start simple. Can you give a rational argument against immediately raising the block size cap to 8MB?

In short, an 8Mb block limit could:

• Have devastating effects on the fee market

Since there's more space in each block, this space is now less valuable, fees might not be zero, but they'll be lead down to the minimum and competitiveness for fast transactions will be dead.

• Bring nodes offline and make pools/miners less reliable

Mining basically becomes less and less economically viable over time under BIP101. Mining would need subsidising somehow, and so only those that can afford to do that will mine (i.e. losing money). The most concerning outcome would be large miners staying in the industry only to maintain control of the hashrate.

That doesn't sound half wrong to me. That's the Silicon Valley motto no? "Lose money, gain users!" 

[Carlton Banks]

The most concerning outcome would be large miners staying in the industry only to maintain control of the hashrate.

That doesn't sound half wrong to me. That's the Silicon Valley motto no? "Lose money, gain users!" 

I find it incredibly unconvincing that Google, for instance, have ever turned a profit. They've amassed alot of useful information though.

[brg444]

The most concerning outcome would be large miners staying in the industry only to maintain control of the hashrate.

That doesn't sound half wrong to me. That's the Silicon Valley motto no? "Lose money, gain users!" 

I find it incredibly unconvincing that Google, for instance, have ever turned a profit. They've amassed alot of useful information though.

I foresee a similar future for Gavincoin service providers!

[glub0x]

Because it was always done this way and therefor it is the easiest solution to implement.
I am not sure, how a 1 BTC= 1 vote would work. After all the votes have to be in the blockchain.

It would be nice to have a BIP that takes into account technical growth, but that is also impossible since, this information is also not in the

To be clear i am not saying this idea is better or even if it is good just that it looks as arbitrary as to give vote to miners.
Now You can sign a messages on the blockchain with your private key and then multiply that with the amount of satoshi
it would work a bit the same way as the miner voting system but instead of "1mhZ" 1 vote, you get "1btc" 1 vote.

About technical growth. we can start by considering the technical growth from 2009 until 2015 which is a start. after that only predictions true.

I don't think, you understand how miner voting works. They don't vote with the Hashing power, they vote with the blocks they have found and putting additional information in that blocks.
For a voting system with BTC, people would have to send BTC (making a transaction) and put additional information in there. There is no "signing a message on the blockchain" other than that. The question here is also, what prevents them from just sending the same BTC to sign their votes. You can't tell, if when address A is sending to address B, if address B belongs to the same person, just excluding address B from voting would mean, that whoever makes the first votes in a voting period, would have a advantage.
Unless you can show me a more detailed description of how that is supposed to work, I don't think it is a good idea.

I understand how miner vote. Minus the random part of block finding isn't that the same as 1MHZ 1vote?
The more hashing power, the more block you find ...

So to come back to my exemple of a different system but as arbitrary
Vote take place on DAY 1.
All the coin that didn't move before DAY 1 can vote ( ie you can't send a coin from different address to vote multiples times
Address A sign a particular message about the blocksize  "i vote for blocksize 2MB" (at the cost of a transaction fee+1satoshi)
Address B that receive btc on day 1 ( possibly from a previous vote) can't vote.

Then to know what the bitcoins holders want you simply sum up all the satoshi on address A at the voting time (at the begining of DAY1) and of all the other address that vote for 2MB...

This will probably never be accepted but is it so much different of BIP 100 system?
Instead of giving power to one, you give it to another...

[PinkFish]

Maybe we come up with a BIP 102 and compromise by including pieces from both?

[uxgpf]

• Have devastating effects on the fee market

Since there's more space in each block, this space is now less valuable, fees might not be zero, but they'll be lead down to the minimum and competitiveness for fast transactions will be dead.

I don't know how it would change the fee market.. There hasn't been any scarcity in blocks before so fees would probably stay quite similar to what they are today. If adoption continues to increase, the total of collected fees will be higher as there would be more transactions per block.

• Bring nodes offline and make pools/miners less reliable

The change would increase bandwidth consumption as well as HD space required to run a full node. There are many nodes that run on non-optimized hosts, if they suddenly start sucking up more of the bandwidth and HD space it's safe to assume that many will go offline. Also, pools running on weak networks would be more prone to orphaned blocks because of the blocks being harder to propagate.

One possibility is that increase in adoption and advancement of technology will balance that or even make number of nodes increase. We can't know for sure.

What I know is that letting blocks to saturate will make the fees rise rise and will make bitcoin less inclusive. It will be less appealing/useless for many markets/use cases thus stiffle the growth. Everyday users will find it less useful and investors don't want to invest in niche product with no growth potential.

If you're not so sure about that, then lets try to keep 1 MB limit for few years just to see what happens. It would be an interesting experiment and surely would not kill bitcoin...just push it back few years at worst.

[Carlton Banks]

• Have devastating effects on the fee market

Since there's more space in each block, this space is now less valuable, fees might not be zero, but they'll be lead down to the minimum and competitiveness for fast transactions will be dead.

I don't know how it would change the fee market.. There hasn't been any scarcity in blocks before so fees would probably stay quite similar to what they are today. If adoption continues to increase, the total of collected fees will be higher as there would be more transactions per block.

Wrong. Some scarcity in blocks, and some disparity in the fees paid is essential to maintain a healthy economic relationship between the miners and the users. More tx volume just recreates today's dynamics on a larger scale. As the block reward subsidy diminishes, the extent to which that subsidy was distorting the fee market will become increasingly more apparent. When the block reward approaches zero, having a functional fee market in place is the only way of incentivising miners to mine at all.

Treating fees as "one-fee-fits-all" doesn't take account of the economic reality. Some transactions must confirm ASAP, for a wide variety of reasons. Others can be afforded hours, days or perhaps even longer than that.

• Bring nodes offline and make pools/miners less reliable

The change would increase bandwidth consumption as well as HD space required to run a full node. There are many nodes that run on non-optimized hosts, if they suddenly start sucking up more of the bandwidth and HD space it's safe to assume that many will go offline. Also, pools running on weak networks would be more prone to orphaned blocks because of the blocks being harder to propagate.

One possibility is that increase in adoption and advancement of technology will balance that or even make number of nodes increase. We can't know for sure.

What I know is that letting blocks to saturate will make the fees rise rise and will make bitcoin less inclusive. It will be less appealing/useless for many markets/use cases thus stiffle the growth. Everyday users will find it less useful and investors don't want to invest in niche product with no growth potential.

Again, you're speaking as if every fee will be pushed up to the same level; there is, and always will be, a range of fees that can be usefully applied in order to target the confirmation time the user needs for a given transaction. A functional fee market will make instant confirms more expensive; they should be, because instant confirms are in high demand.

Bitcoin Core wallet has only recently introduced the "smart fee" feature that helps the user choose the right fee for the confirmation time they want (there is an API for other software to use the smart fee feature too). A software feature that was written by the designer of BIP101, no less.

[mavericklm]

drop btc price to 50$ for 3 months and you will see why miners are important!

you cant have a good house without a strong foundation!

[DooMAD]

• Have devastating effects on the fee market

Since there's more space in each block, this space is now less valuable, fees might not be zero, but they'll be lead down to the minimum and competitiveness for fast transactions will be dead.

I don't know how it would change the fee market.. There hasn't been any scarcity in blocks before so fees would probably stay quite similar to what they are today. If adoption continues to increase, the total of collected fees will be higher as there would be more transactions per block.

Wrong. Some scarcity in blocks, and some disparity in the fees paid is essential to maintain a healthy economic relationship between the miners and the users. More tx volume just recreates today's dynamics on a larger scale. As the block reward subsidy diminishes, the extent to which that subsidy was distorting the fee market will become increasingly more apparent. When the block reward approaches zero, having a functional fee market in place is the only way of incentivising miners to mine at all.

Treating fees as "one-fee-fits-all" doesn't take account of the economic reality. Some transactions must confirm ASAP, for a wide variety of reasons. Others can be afforded hours, days or perhaps even longer than that.

Funnily enough, that's why no one is saying let's get rid of the cap entirely.  No one's saying let's have 10GB blocks tomorrow.  Everyone who isn't a perma-1MBer knows that the limit needs to be raised, but everyone seems to have a different idea on how much of an increase is safe.  I honestly don't see 8MB as a threat to decentralisation.  I don't see how anyone could.  I'm not entirely convinced about the doubling part being needed yet, but we don't necessarily have to allow the doubling to happen.  It can be prevented with a soft fork if it isn't needed.  All things considered, BIP101 isn't the catastrophe some make it out to be.  It certainly doesn't guarantee a future of 8GB blocks and half a dozen nodes running the whole network, no one in their right mind would allow it to come to that.  But if the miners aren't showing much support for BIP101, I'll go along with that.  Their preference seems to be BIP100 at the moment, but there are justified concerns that they could choose to enforce a 1MB limit forever if that's what they deemed most profitable for them.  What would be beneficial to the network as a whole isn't taken into consideration at all and it involves placing trust in an entity to set a variable which dictates how the network is run.  I would feel much more comfortable if this was done algorithmically, like just about everything else in Bitcoin.

More than ever, I'm convinced that the answer lies somewhere between BIP100 and upal's BIP1xx (but more towards the latter).  A balance between the two is absolutely 100% reasonable and the only people who would still take issue with it would be the ones who think Bitcoin's sole purpose is to benefit a small minority of ultralibertarian crackpots.

[alani123]

8Mb block limit in its own isn't a huge thread towards decentralisation or bitcoin. I'm hesitant when it comes to increasing the limit eightfold in an instance though, I also don't like BIB101's approach about the cap doubling.