How a floating blocksize limit inevitably leads towards centralization

[hazek]

So...  I start from "more transactions == more success"

I strongly feel that we shouldn't aim for Bitcoin topping out as a "high power money" system that can process only 7 transactions per second.

I agree with Stephen Pair-- THAT would be a highly centralized system.

Oh, sure, mining might be decentralized.  But who cares if you either have to be a gazillionaire to participate directly on the network as an ordinary transaction-creating customer, or have to have your transactions processed via some centralized, trusted, off-the-chain transaction processing service?

So, as I've said before:  we're running up against the artificial 250K block size limit now, I would like to see what happens. There are lots of moving pieces here, so I don't think ANYBODY really knows what will happen (maybe miners will collectively decide to keep the block size low, so they get more fees.  Maybe they will max it out to force out miners on slow networks.  Maybe they will keep it small so their blocks relay through slow connections faster (maybe there will be a significant fraction of mining power listening for new blocks behind tor, but blasting out new blocks not via tor)).


I think we should put users first. What do users want? They want low transaction fees and fast confirmations. Lets design for that case, because THE USERS are who ultimately give Bitcoin value.

you could never get away with a hard fork on this point so the best you could do is create an alternative cryptocurrency which you would then become the developer of instead of bitcoin. In this respect i say more power to you! lets get some healthy competition in the cryptocurrency market! (litecoin doesnt count as competition)

I agree. I even think if ever a hard fork in Bitcoin should happen the new version should have a completely new name so that users who stay on the old version know they still use their Bitcoin and the users of the new version know that what they're using isn't Bitcoin anymore.

[TierNolan]

This raises the issue of exchange rates between chains.  A user might see their "bitcoin" total vary over time if it has stored some of the coins as bitcoin-chain7 and bitcoin-chain12 coins.

Heck you could even build chains that have fixed exchange rates built into their atomic between-chain transactions protocol if you are really worried about it. For most people most of the time it would probably suffice to denominate their life-savings account in bitcoin and let their day to day pocketmoney account just use whatever Ripple determines is the most efficient way to buy lunch on a given day.

Yeah, I think a fixed rate is a good idea.  However, it would only work if built into the system and again, it makes combining of coins bloating the main chain.

Each chain could be given a minimum number of bitcoins.  You can split a coin in 2 (or 10) and move it down to the next chain.  That makes each "chain" actually like a type of coin (good analogy there btw).

I wonder if something like Chaum's scheme could be used to "issue" coins.  You pay "coins" into a special txo and later coins can be anonymously verified and reincorporated into the top-level chain as a tx-in.

Over issue could happen if the underlying encryption is broken though.  The rule could be if 10000 coins were issued to a lower chain, then the first 10000 redeemed are the only ones to count.

Different chains could have different security.  As long as you trust the top chain and the digital cash, you can trust the coins too.

[DannyHamilton]

you could never get away with a hard fork on this point so the best you could do is create an alternative cryptocurrency which you would then become the developer of instead of bitcoin.

Why not?  All he'd have to do is code the change, offer it as the new version of the "reference client" and see how many people accepted it.  What percentage would have to accept the hard fork for it to become viable? 50%? 20%? 5%?

[DannyHamilton]

- snip -
I agree. I even think if ever a hard fork in Bitcoin should happen the new version should have a completely new name so that users who stay on the old version know they still use their Bitcoin and the users of the new version know that what they're using isn't Bitcoin anymore.

Who gets to decide which fork gets to claim to be "Bitcoin"?  If users of both forks decide they are the true "Bitcoin", how is the naming issue resolved?

[hazek]

- snip -
I agree. I even think if ever a hard fork in Bitcoin should happen the new version should have a completely new name so that users who stay on the old version know they still use their Bitcoin and the users of the new version know that what they're using isn't Bitcoin anymore.

Who gets to decide which fork gets to claim to be "Bitcoin"?  If users of both forks decide they are the true "Bitcoin", how is the naming issue resolved?

Bitcoin will be what Bitcoin is right now. I didn't say the name of the new version will change or users of the new version will want it to change, they may well want it to stay Bitcoin, doesn't make it Bitcoin though and I don't think it should be called Bitcoin. But that is my opinion and it depends how much that matters.

[markm]

you could never get away with a hard fork on this point so the best you could do is create an alternative cryptocurrency which you would then become the developer of instead of bitcoin.

Why not?  All he'd have to do is code the change, offer it as the new version of the "reference client" and see how many people accepted it.  What percentage would have to accept the hard fork for it to become viable? 50%? 20%? 5%?

Lowering the difficulty of the real, as in original, bitcoin, so the rest of us can go on mining the original, high value per coin, international settlements bitcoins while he goes on to make a payment network for people to buy popsibles with. Sounds interesting... Especially with everyone having their coins from the past still exist on both chains, the original and the new popsicle-coin chain.

-MarkM-

[markm]

- snip -
I agree. I even think if ever a hard fork in Bitcoin should happen the new version should have a completely new name so that users who stay on the old version know they still use their Bitcoin and the users of the new version know that what they're using isn't Bitcoin anymore.

Who gets to decide which fork gets to claim to be "Bitcoin"?  If users of both forks decide they are the true "Bitcoin", how is the naming issue resolved?

This is maybe the real reason for making the Bitcoin Foundation: to trademark the name, so whatever popsicle-coin of the day they come up with gets the "network effect" associated with the "brand"...

-MarkM-

[Technomage]

I don't see how a hard fork is somehow not Bitcoin. It's simply an upgrade. A bigger upgrade, but an upgrade nonetheless. If it is done in the face of serious controversy and there is a real split, then there is a naming problem. Otherwise it's just as much Bitcoin, just a new version.

It could be Bitcoin version 2.0 for example. If there is a permanent split, then the other network would be called something else.

I'm going to side with the version where the block size limit is raised, that is for sure. If it is done in a smart way though, it's a big change and needs to be thought of carefully. I don't advocate "just raising it", I advocate planning the change well and thinking about the long term future as well.

[justusranvier]

What exactly is wrong with this proposal, that justifies all this drama?

https://bitcointalk.org/index.php?topic=140233.msg1503099#msg1503099

That proposal does not force miners to increase the size of their blocks, or include any transactions they don't want to include.

It does not force any node to relay or store blocks they don't want to.

It allows the maximum block size to be determined by distributed consensus instead of centrally managed by fiat. That's the exact opposite of what people are complaining about, and the solution of leaving the limit in place is the problem they claim to want to avoid.

As far as the hard fork goes didn't we have a couple of those last year anyway, such as multisig transactions?

[Technomage]

The upgraded Bitcoin basically only needs services such as Blockchain.info, BitPay, Coinbase, Mt. Gox and such behind it, and everything else is irrelevant. Without those services there is no Bitcoin, no nothing. With them, it's a done deal. The ones advocating for a hard fork need to make sure all the major services and mining pools are on board and it's basically done.

Obviously there needs to be a significant amount of time involved so that the magnitude of the change can be communicated to all types of users.

[markm]

What exactly is wrong with this proposal, that justifies all this drama?

https://bitcointalk.org/index.php?topic=140233.msg1503099#msg1503099

That proposal does not force miners to increase the size of their blocks, or include any transactions they don't want to include.

It does not force any node to relay or store blocks they don't want to.

It allows the maximum block size to be determined by distributed consensus instead of centrally managed by fiat. That's the exact opposite of what people are complaining about, and the solution of leaving the limit in place is the problem they claim to want to avoid.

As far as the hard fork goes didn't we have a couple of those last year anyway, such as multisig transactions?

I thought one of the main points being brought up is that on the contrary it allows Joe Superminer to progressively drive more and more competitors off the net until he and he alone controls all the mining. (Presumably pretending to be more than one mining operation, of course, to keep people from noticing he has become the sole arbiter of the network.)

-MarkM-

[hazek]

I don't see how a hard fork is somehow not Bitcoin. It's simply an upgrade.

There are no backwards incompatible upgrades in Bitcoin, otherwise I wouldn't be here or have use for it.

As far as the hard fork goes didn't we have a couple of those last year anyway, such as multisig transactions?

Nope, all soft forks and backwards compatible - inherently different from a hard fork.

[justusranvier]

I thought one of the main points being brought up is that on the contrary it allows Joe Superminer to progressively drive more and more competitors off the net until he and he along controls all the mining. (Presumably pretending to be more than one mining operation, of course, to keep people from noticing he has become the sole arbiter of the network.)

Did you read the proposal? The decision about how large blocks can be rests with the nodes which relay blocks, not the miners.

If Joe Superminer controls enough of the hashing power and the p2p network to force a change through he could ruin the network today, with or without any change to the protocol.

[Anon136]

- snip -
I agree. I even think if ever a hard fork in Bitcoin should happen the new version should have a completely new name so that users who stay on the old version know they still use their Bitcoin and the users of the new version know that what they're using isn't Bitcoin anymore.

Who gets to decide which fork gets to claim to be "Bitcoin"?  If users of both forks decide they are the true "Bitcoin", how is the naming issue resolved?

To me its obvious that the original is the real bitcoin. Of course any claim that the real bitcoin was superior to the of shoot simply because its the real bitcoin would be a fallacy. So being the real bitcoin is nothing to be proud of its just a label, if the fork is fixing real problems well, and adding awesome new features ect... than go NewCoin!

[markm]

I thought one of the main points being brought up is that on the contrary it allows Joe Superminer to progressively drive more and more competitors off the net until he and he along controls all the mining. (Presumably pretending to be more than one mining operation, of course, to keep people from noticing he has become the sole arbiter of the network.)

Did you read the proposal? The decision about how large blocks can be rests with the nodes which relay blocks, not the miners.

If Joe Superminer controls enough of the hashing power and the p2p network to force a change through he could ruin the network today, with or without any change to the protocol.

I thought I had read it. We are here dissing or discussing the fact the clients would float the limit, aren't we?

If the limit can float, who controls the things it takes into account in determining whether to float and how much to float? What is it looking at to make the decision, that is not controlled by miners?

-MarkM-

[justusranvier]

I thought I had read it. We are here dissing or discussing the fact the clients would float the limit, aren't we?

If the limit can float, who controls the things it takes into account in determining whether to float and how much to float? What is it looking at to make the decision, that is not controlled by miners?

There is still the question of what the default behavior should be. Here is a proposal:

Ignore blocks that take your node longer than N seconds to verify.

I'd propose that N be:  60 seconds if you are catching up with the blockchain.  5 seconds if you are all caught-up.  But allow miners/merchants/users to easily change those defaults.

The decision about what blocks to relay is made by the p2p network. What percentage of the people running full nodes are also mining?

[markm]

They are going to refuse to "relay" things that got into the highest difficulty blockchain?

I thought relaying only meant passing around the stuff that is not yet in the blockchain?

Miners mining blocks can pass them directly to all major pools probably without any "relaying".

-MarkM-

[Gavin Andresen]

The changes in the last year were "soft forks" -- forks that required all miners to upgrade (if they don't, their blocks are ignored), but that do not require merchants/users to upgrade.

-------

A couple of random, half-baked thoughts I had this morning:

If you think that the block size should stay at 1 megabyte forever, then you're saying the network will never support more than 7 transactions per second, and each transaction will need to be for a fairly large number of bitcoins (otherwise transaction fees will eat up the value of the transaction).

If transactions are all pretty big, why the heck do we have 8 decimal places for the transaction amount?

Don't get me wrong, I still think the bitcoin network is the wrong solution for sub-US-penny payments. But I see no reason why it can't continue to work well for small-amount (between a US $1 and $0.01) payments.

If there are a very limited number of transactions per day and billions of dollars worth of BTC being transacted (that's what we all want, yes?) then obviously each transaction must be large. So, again, why bother having 8 digits after the decimal point if each transaction is hundreds of bitcoins big?

------

Second half-baked thought:

One reasonable concern is that if there is no "block size pressure" transaction fees will not be high enough to pay for sufficient mining.

Here's an idea: Reject blocks larger than 1 megabyte that do not include a total reward (subsidy+fees) of at least 50 BTC per megabyte.

"But miners can just include a never broadcast, fee-only transactions to jack up the fees in the block!"

Yes... but if their block gets orphaned then they'll lose those "fake fees" to another miner. I would guess that the incentive to try to push low-bandwidth/CPU miners out of the network would be overwhelmed by the disincentive of losing lots of BTC if you got orphaned.

[wtfvanity]

The changes in the last year were "soft forks" -- forks that required all miners to upgrade (if they don't, their blocks are ignored), but that do not require merchants/users to upgrade.

-------

A couple of random, half-baked thoughts I had this morning:

If you think that the block size should stay at 1 megabyte forever, then you're saying the network will never support more than 7 transactions per second, and each transaction will need to be for a fairly large number of bitcoins (otherwise transaction fees will eat up the value of the transaction).

If transactions are all pretty big, why the heck do we have 8 decimal places for the transaction amount?

Don't get me wrong, I still think the bitcoin network is the wrong solution for sub-US-penny payments. But I see no reason why it can't continue to work well for small-amount (between a US $1 and $0.01) payments.

If there are a very limited number of transactions per day and billions of dollars worth of BTC being transacted (that's what we all want, yes?) then obviously each transaction must be large. So, again, why bother having 8 digits after the decimal point if each transaction is hundreds of bitcoins big?

------

Second half-baked thought:

One reasonable concern is that if there is no "block size pressure" transaction fees will not be high enough to pay for sufficient mining.

Here's an idea: Reject blocks larger than 1 megabyte that do not include a total reward (subsidy+fees) of at least 50 BTC per megabyte.

"But miners can just include a never broadcast, fee-only transactions to jack up the fees in the block!"

Yes... but if their block gets orphaned then they'll lose those "fake fees" to another miner. I would guess that the incentive to try to push low-bandwidth/CPU miners out of the network would be overwhelmed by the disincentive of losing lots of BTC if you got orphaned.

I love Gavin's thoughts.

I also love his half-baked thoughts.

Although I'm sure no one cares what I think, I fully support Gavin and the lead developers on their thoughts on this.

[ElectricMucus]

The changes in the last year were "soft forks" -- forks that required all miners to upgrade (if they don't, their blocks are ignored), but that do not require merchants/users to upgrade.

-------

A couple of random, half-baked thoughts I had this morning:

If you think that the block size should stay at 1 megabyte forever, then you're saying the network will never support more than 7 transactions per second, and each transaction will need to be for a fairly large number of bitcoins (otherwise transaction fees will eat up the value of the transaction).

If transactions are all pretty big, why the heck do we have 8 decimal places for the transaction amount?

Don't get me wrong, I still think the bitcoin network is the wrong solution for sub-US-penny payments. But I see no reason why it can't continue to work well for small-amount (between a US $1 and $0.01) payments.

If there are a very limited number of transactions per day and billions of dollars worth of BTC being transacted (that's what we all want, yes?) then obviously each transaction must be large. So, again, why bother having 8 digits after the decimal point if each transaction is hundreds of bitcoins big?

------

Second half-baked thought:

One reasonable concern is that if there is no "block size pressure" transaction fees will not be high enough to pay for sufficient mining.

Here's an idea: Reject blocks larger than 1 megabyte that do not include a total reward (subsidy+fees) of at least 50 BTC per megabyte.

"But miners can just include a never broadcast, fee-only transactions to jack up the fees in the block!"

Yes... but if their block gets orphaned then they'll lose those "fake fees" to another miner. I would guess that the incentive to try to push low-bandwidth/CPU miners out of the network would be overwhelmed by the disincentive of losing lots of BTC if you got orphaned.

I love Gavin's thoughts.

I also love his half-baked thoughts.

Although I'm sure no one cares what I think, I fully support Gavin and the lead developers on their thoughts on this.

Where is Atlas when you need him?  

Seriously that sounds like a reasonable compromise I could live with. Although I have to say it's a compromise and compromising can lead to a slippery slope, imo.