The fork

[Anon136]

i for one would not go along with such a fork. i think many others would agree with me. So long as there are atleast a few other people who agree, a hard fork will not be possible.

This change is (eventually) such a critical and needed change, if we want Bitcoin to be used for small payments as well, that it will simply be done. Anyone who disagrees will form their own payment network.

The alternative scenario is that for some reason the dev team doesn't have the will to do this, and users eventually start to flock to other cryptocurrencies.

This problem can be solved with centralized services. I know this sounds ominous, but since these servers would only be used for transactions that were too small to be efficiently sent through the bitcoin network it really wouldnt be a big deal at all. I would probably only have a tiny fraction of a percent of my assets held in such a system at any given time.

So you feel like 7 transactions/second will always be enough? 

not at all. Im saying that small transactions will be handled off network and 7 transactions per second will be enough to transfer large amounts of bitcoin. (assuming 7 transactions per-second is the actual limit applied by 1mb blocks)

[1715085562]

1715085562

[1715085562]

1715085562

[1715085562]

1715085562

[1715085562]

1715085562

[1715085562]

1715085562

[1715085562]

1715085562

[hazek]

Does it matter what your point was? You spread manipulative framing, don't do it.

That's just silly. Of course it matters what the point was.

Notig was using Gavin's words to imply that Gavin had a certain intent.  The only way to point out that Gavin had a different intent was to point out what that different intent was.

Yes. Of course.

But instead of saying Gavin was responding to an argument that blocksize has to remain small forever for the sake of inefficient miners (as he framed it) you could have accurately said that he was responding to an argument that blocksize has to remain small forever for the sake of security and decentralization.

See the difference? It's subtle, but that's how manipulation usually is.

[hazek]

As I understand it, Satoshi DID intend to increase the block size, and he intended to do it without a fork.

I think its worth remembering that Satoshi's view ought to get a certain amount of respect just because, he is Satoshi.

Fallacy: Appeal to authority.


It's completely irrelevant what Satoshi or anyone else thought how Bitcoin ought to work if it isn't based in a sound argument.

[DannyHamilton]

Does it matter what your point was? You spread manipulative framing, don't do it.

That's just silly. Of course it matters what the point was.

Notig was using Gavin's words to imply that Gavin had a certain intent.  The only way to point out that Gavin had a different intent was to point out what that different intent was.

Yes. Of course.

But instead of saying Gavin was responding to an argument against a particular reasoning that blocksize has to remain small forever for the sake of inefficient miners (as he framed it) you could have accurately said that he was responding to an argument against a particular reasoning that blocksize has to remain small forever for the sake of security and decentralization.

See the difference? It's subtle, but that's how manipulation usually is.

Sure, but then Gavin would be in here accusing me of spreading retep's manipulative framing.  

It seems that either way I'm using someone's framing. That can't be avoided.  Since Notig was using Gavin's words to make his point, I was using Gavin's words to show that Notig misunderstood Gavin's point.

If Notig had used retep's words and misunderstood retep's point, I'd have used retep's words (along with whatever framing they included) to show that Notig misunderstood retep's point.

Sorry, I just don't see the issue here.  I wasn't arguing that Gavin was right (or wrong), only that Notig was basing his questions on a misunderstanding of what Gavin was saying.

[markm]

If there is still space in blocks reserved for free transactions will that go away first before bothering to actually increase the block size?

At how much fee per kilobyte will a megabyte per block cease to be "enough" to accommodate all transactions willing to pay that fee?

-MarkM-

[mintymark]

As I understand it, Satoshi DID intend to increase the block size, and he intended to do it without a fork.

I think its worth remembering that Satoshi's view ought to get a certain amount of respect just because, he is Satoshi.

Fallacy: Appeal to authority.


It's completely irrelevant what Satoshi or anyone else thought how Bitcoin ought to work if it isn't based in a sound argument.

I agree. But all I am saying is that in Satoshi's case it usually was, so we should be that much more certain if we think he was wrong.

prezbo: yes on futher reflection this is a fork, I was wrong.

[DannyHamilton]

prezbo: yes on futher reflection this is a fork, I was wrong.

Increasing from 250kB to 1MB is not a fork because 250kB is a self imposed limitation used by a subset of miners on the creation (not the acceptance or relay) of a block.

Increasing above 1MB and/or changing to a dynamic algorithm for choosing the maximum blocksize of any particular block would be a fork inducing change if 100% of the users and miners did not accept the change before it was triggered.

[Littleshop]

Yawn.

If the majority of developers feel it is important to change the protocol to keep it functioning properly I will change my miners or switch to a pool that supports it.  Changes have happened before and they will happen again.  Bitcoin is not a frozen protocol.  If you don't like the change, don't change though you may no longer be a part of the majority network.  These things resolve themselves quickly based on the TECHNICAL MERITS of the change.

[DannyHamilton]

Yawn.

If the majority of developers feel it is important to change the protocol to keep it functioning properly I will change my miners or switch to a pool that supports it.  Changes have happened before and they will happen again.  Bitcoin is not a frozen protocol.  If you don't like the change, don't change though you may no longer be a part of the majority network.  These things resolve themselves quickly based on the TECHNICAL MERITS of the change.

And if there's pretty much an even split among developers with equal numbers on each side of the issue, and the technical merits depend on a choice between a more decentralized bitcoin or a significantly faster growing blockchain that leads to centralization and a reduction in mining and full nodes?  Then which will you choose?

[Peter Todd]

Yawn.

If the majority of developers feel it is important to change the protocol to keep it functioning properly I will change my miners or switch to a pool that supports it.  Changes have happened before and they will happen again.  Bitcoin is not a frozen protocol.  If you don't like the change, don't change though you may no longer be a part of the majority network.  These things resolve themselves quickly based on the TECHNICAL MERITS of the change.

Bitcoin has changed before, but the last time a hard-fork change happened was way back in the summer of 2010 to fix the overflow bug. Back then Bitcoin's were nearly worthless, there wasn't really an economy built, and the userbase was tiny. There have been soft-forks like P2SH, where only mining power requires upgrading, but even those took months of planning and advocacy.

Changing the block size is a really big deal. Technically speaking the change is no different than changing the inflation schedule, and as we've seen, it's not a change without a lot of controversy. Everyone needs to change their software to accept the change; if Gavin pushed a blocksize change to the reference client tomorrow, I know I myself would stick with the existing system as would many others.

[Littleshop]

Yawn.

If the majority of developers feel it is important to change the protocol to keep it functioning properly I will change my miners or switch to a pool that supports it.  Changes have happened before and they will happen again.  Bitcoin is not a frozen protocol.  If you don't like the change, don't change though you may no longer be a part of the majority network.  These things resolve themselves quickly based on the TECHNICAL MERITS of the change.

Bitcoin has changed before, but the last time a hard-fork change happened was way back in the summer of 2010 to fix the overflow bug. Back then Bitcoin's were nearly worthless, there wasn't really an economy built, and the userbase was tiny. There have been soft-forks like P2SH, where only mining power requires upgrading, but even those took months of planning and advocacy.

Why would changing the blocksize be any different?  I see a lot of FUD in this thread. 

[DannyHamilton]

- snip -
if Gavin pushed a blocksize change to the reference client tomorrow, I know I myself would stick with the existing system as would many others.

retep,

I saw in that other thread that you gave quite a bit of thought to how increasing blocksize could lead to increased centralization of mining.

I'm curious if you've given much thought to the ways that increased transaction fees might also lead to increased centralization?  Perhaps I haven't given it enough thought yet, but my basic thinking is along the lines of:

• Increased fees create an incentive for a few large well funded mining operations to get involved
• The larger the total hashing power of the network, the more necessary it becomes for smaller operations to participate in a pool to receive a reasonable chance of being paid for their efforts in a timely manner.
• The more pools are used by smaller operations, the smaller the individual share of mining reward for each of those operations.
• High fees make spending/using that small acquired share of a mining reward cost prohibitive (fees use up the entire balance of each added input leaving nothing left for actual spending).
• The inability to spend/use any of the earned bitcoins discourages participation in mining by small operations, leading to an increase in centralization as the smaller operations are forced out of the market.

There may be other ways that increased fees drive centralization, this was just the first that came to mind (which was why I asked if you had given the possibility much thought).

[Peter Todd]

retep,

I saw in that other thread that you gave quite a bit of thought to how increasing blocksize could lead to increased centralization of mining.

I'm curious if you've given much thought to the ways that increased transaction fees might also lead to increased centralization?  Perhaps I haven't given it enough thought yet, but my basic thinking is along the lines of:

On the bitcoin-dev email list I responded to exactly that argument actually; my responses below are based on the response:

Increased fees create an incentive for a few large well funded mining operations to get involved

The cost of mining is in two parts: mining itself, and overhead. The mining equipment costs basically the same regardless of how many hashes/s you want to mine with; if anything I suspect small mining operations are cheaper than larger operations because cooling costs are non-existance for a small miners with a few rigs, and at a small scale power can often be either re-used for heating (cold climates) or is available at a flat rate. (I don't pay for power at my apartment) We're fortunate that the primary cost of ASICs is the mining chip itself, and they are cheapest when you make thousands of inexpensive chips. You'll always be able to buy relatively inexpensive rigs that only contain a few chips, just like BFL sells everything from $150 rigs, one chip, to $35,000 rigs, lots of chips.

The overhead, running a validating node to verify the blocks you are mining, is a fixed cost.

Thus I see no reason why large fees have anything to do with the size required to profitably run a mining operation.

The larger the total hashing power of the network, the more necessary it becomes for smaller operations to participate in a pool to receive a reasonable chance of being paid for their efforts in a timely manner.

Sure, but that's already true. Even the ASIC operations have been mining in pools to keep varience low. The important thing is that small blocks make it cheap for anyone to validate the blocks you are mining for the pool, keeping the pool honest. Equally they allow you to mine on P2Pool, which is totally distributed and not controlled by anyone.

Anyway, the argument you're really making is that we can't spend a lot of money ensuring that the network remains secure against a well funded 51% attacker, not that small blocks themselves are an issue. I dunno about you, but I think huge mining rewards are a good thing and keep us all safe from 51% attackers.

• High fees make spending/using that small acquired share of a mining reward cost prohibitive (fees use up the entire balance of each added input leaving nothing left for actual spending).
• The inability to spend/use any of the earned bitcoins discourages participation in mining by small operations, leading to an increase in centralization as the smaller operations are forced out of the market.

These are real issues, but they can be solved with the same micropayment systems people will use for small transactions. For instance, P2Pool makes payments directly from the coinbase, taking block space away from transactions that could earn money instead.

What would happen as blocks approach the limit is first P2Pool would take into account the cost of payout transactions in terms of lost fees. This would give miners an incentive to only get payouts when the payout amount was sufficiently high. The amount of hashing power required would be pretty large, so you'd naturally see sub-pools develop combining a whole bunch of hashing power together. (P2Pool already supports sub-pools BTW) Those sub-pools would publish contracts specifying how they would pay out, what micropayment system and so on, and miners using those sub-pools would either be payed correctly, or if the pool defrauded them, they'd be able to prove the pool defrauded them and make them lose their fidelity bonds they had to purchanse to be trusted in the first place.

Note how that's basically how most pools already work anyway - you trust the pool to pay what you are owed. The only change is in the mechanism by which you get paid.

[markm]

Is there a massive difference ultimately between doubling the size of blocks and doubling the number of blocks per period of time that makes doubling the size of blocks much better than doubling the frequency of blocks?

Maybe we would be better off decreasing the target time between blocks than increasing the size of the blocks?

-MarkM-

[DannyHamilton]

Is there a massive difference ultimately between doubling the size of blocks and doubling the number of blocks per period of time that makes doubling the size of blocks much better than doubling the frequency of blocks?

Maybe we would be better off decreasing the target time between blocks than increasing the size of the blocks?

-MarkM-

That's an interesting idea.

Would you propose cutting the block reward in half and changing the future halving to every 420,000 blocks when implementing that solution so that the inflation rate stays roughly the same?

Or would you leave it exactly as it is now so that the inflation rate doubles and we reach the point where all coins are mined in half the original time?

[markm]

To at least some extent I suspect that getting to the point where all the coins are mined faster is better.

Once all the coins are mined there will no longer be all those miners dumping new coins on the markets all the time, their income will be presumably somewhat proportional to the amount that the system is actually being used. There are plenty of younger chains that will still be bringing them freshly minted coins, and we already have seen, and are about to see again, extended periods when the average time between blocks was less than ten minutes due to rapid increases in hashing power.

In fact as ASICs come online we might see enough more blocks per day that we will already anyway be making more space for transactions by pumping out blocks faster.

-MarkM-

[johnyj]

IMO, fork=double spend

Programmers tends to be perfectionists

But, even the greatest art in human history is not flawless

Scarcity cause cherish, abundant cause abuse

If people really cherish the value of bitcoin, they will try all their best to protect it

[DannyHamilton]

To at least some extent I suspect that getting to the point where all the coins are mined faster is better.

Once all the coins are mined there will no longer be all those miners dumping new coins on the markets all the time
- snip -

The total number of coins dumped on the markets would be the same, they'd just get dumped twice as fast.  As for "all the coins are mined", we'd be talking about 72 years instead of 140, right?

[Anth0n]

But instead of saying Gavin was responding to an argument that blocksize has to remain small forever for the sake of inefficient miners (as he framed it) you could have accurately said that he was responding to an argument that blocksize has to remain small forever for the sake of security and decentralization.

See the difference? It's subtle, but that's how manipulation usually is.

If current block size limit means greater decentralization and therefore greater security, that means the smallest possible block size (enough to fit just one transaction) means maximum decentralization and therefore maximum security. So proponents of a block size limit must logically also be in favor of a one-transaction-per-block limit. Not to mention absurdly high transaction fees. Ad hominems against Gavin might be fun to use as arguments, but they are not effective.

[Zangelbert Bingledack]

What happens to Bitcoin if there is a hard fork and half go along while the other half refuse?