Topic: How a floating blocksize limit inevitably leads towards centralization - page 16. (Read 71612 times)

If the soft limit reached, I would prefer putting some transaction limit into each client, e.g. you have one low fee transaction every xxx hour, and further transaction will have to pay higher fee

If a hard fork happened and generated unexpected devastating effect, investors lost lot's of wealth, who is going to responsible for that? I do not think any developer can stand for that, not even btc foundation

Of course there is always an option to roll back to original chain, but maybe by then the original chain also become heavily hurt, since the promise of limited supply has broken (each fork will double the existing coin supply), now there are two different bitcoin at various different locations, people will question how many fork there will be, and which branch of btc you are talking about, these all created a whole lot of confusion and uncertainty, which will almost for sure cause a mass sell off. Even FED has never created that amount of inflation at any given day

All my concern is about the fork, not related to block size limit, they are totally different level discussion

I think the community should have a constitution: Never ever change the original protocol

Perfectionism kills, it is much less risk to deal with the imperfection in original protocol with client side solutions. Consistency and integrity of the protocol will gain people's trust and increase the adoption rate

Another possible solution to the scarcity of transaction space versus an infinately growing transaction queue (with infinately growing free transaction confirmation delays) is to permit an unlimited (or massively huge limit) block to legally occur under specific conditions that would not incentivise miners towards anti-competitive activities.

For example, there could be an exception rule for the blocksize limit if zero fee paying transactions were included into the block.  This rule would permit a miner to queue dump for his own reasons, be it that his queue is too large, it's owned by a major bitcoin holder that simply wishes to help the network at his own expense, or a major retailer (think WalMart) that has a huge amount of free transactions from customers to process, and mining isn't directly their business model.

Another method would be to permit an un-limited block based upon an interval that miners could not depend upon.  For example, the difficulty is adjusted every two weeks or so, but the difficulty adjustment block could also be an unlimited block, also permitting (perhaps expecting) the miner that finds that block to not only include every single fee paying transaction in the block, but also every single transaction still in his queue.  This would limit the delay for free transactions to a two week maximum, and only burden the bandwidth challenged clients and miners once every two weeks and on a predictable schedule.

Occasionally flushing the transaction queues would benefit all players, without significantly impacting the scarcity of transaction space for the remainder of the time period.  However, the second method is likely to encourage free transactions leading up to the unlimited block's expected arrival; whereas the prior method of permitting unlimited blocks based upon a fee-less transaction queue would not encourge same, but nor could users be certain that their free transactions be processed in any reasonable time frame, as there is not way to be certain that any miner would be willing to do this.

This doesn't take scarcity into account and would require an oracle to provide the constants for the necessary formula linking size to difficulty. It's easy to see the case where difficulty outpaces transaction volume; We're about to see that now with ASICs coming online. Once the maximum block size is sufficiently large so that all pending transactions can fit, now we're back to the case where there's no limit and fees trend to zero. Hopefully this example should kill off any ideas about tying block size to difficulty.

I'll repost the scheme I described elsewhere. It uses only information found in the block chain, and should be resistant to miners gaming the system. It increases the maximum block size based strictly on scarcity (preserving it). It doesn't depend on measurements of time or bandwidth. I'm not claiming this is the perfect system, but it provides some ideas to use as a starting point:



Any adjustment to the maximum block size must preserve scarcity. The question is not how many transactions can be handled by a one gigabyte hard limit, but rather will a one gigabyte hard limit produce sufficient scarcity?

The block size limit doesn't have much meaning if there are other systems in place that make it impossible or impractical to create super large blocks. However my favorite solution right now is to simply link the max size with difficulty in some fashion, that makes most sense to me.

No we are not.  At least I'm not.  I'm talking about off-network Bitcoin transactions, of any type, but that are still denominated in bitcoins.  This could be people who trade in sets of private keys (unsafe, yes; but possible), it could be people who trade in a paper currency denominated and/or backed by a bitcoin reserve, or this could be people trading within a single online wallet service (think Ebay, using something like MyBitcoin.com rather than Paypal as the default transaction method) or a potential parrallel network of wallet services that function like banks, taking the Bitcoin equivilant of bankchecks and settling up with one another on much longer intervals.

All of these methods, at least all that I can think of, require more trust between parties and involve greater risk than using the main Bitcoin network; but that is also why they would be a cheaper alternative most of the time.  If you're going to be buying/selling a car with bitcoins, you're going to want to use the Bitcoin network; but if you're buying a snickers bar at the store, a standardized method of trading private keys might be a viable alternative to a blockchain transaction fee.  Microtransactions were never Bitcoin's strong point; distance & high security with low trust were.  Not all transactions require that kind of certainty.


I get this, and I agree from an economic incentives perspective.  This is the very same problem of scarcity that prompted a minimum fee rule, in order for a transaction to be considered a fee paying transaction according to the priority score algo that Gavin put in a couple of years ago.  The limits prompt delays in free transactions, and that is a cost to consumers.  Wise consumers will pay a fee for speed, but not more than they must.  If the transaction fees can ever be expected to replace the decending block reward, there must be some kind of scarcity there.  If we remove the limits altogether, the supply of transaction space will (functionally) be as close to infinate as the supply of bandwidth availabe to email spammers.  There will be no incentive for the majority of users to contribute a fee, even after the block rewards decrease to nominally zero, unless they are running up against some kind of limiting resource.  I believe that free transactions should always be possible, but if speed of confirmation is the concern you're going to have to contribute.  We can suffer a lot more 'freeloading' than can VISA or Mastercard, but the network is not costless, so the service to users cannot be costless either.

I beg to differ. There are plenty who feel that there should be no limit, so that Bitcoin will "scale" to accommodate any amount of transaction volume. It should be clear that, storage and bandwidth issues aside, this will result in fees trending to zero.


It seems obvious that all miners will converge on the same algorithm for producing blocks: Include all transaction with fees. This maximizes mining revenue. But only in the short term. Once ALL miners start doing this, then we have the equivalent of no limit and my comment earlier applies: fees will trend towards zero. Giving "freedom" to miners isn't really a choice. We already know what strategy miners will use. It will be to maximize their fees. Anyone who doesn't follow this strategy will go bankrupt.


Any scheme for dynamically adjusting the block size should be based ONLY on the information contained in the block chain, and not any other information like the "speed" of nodes, or more importantly attributes of the memory pool of pending transactions.

On the other hand I kind of like the solution where the block size is calculated based on mining difficulty. That makes sense from the perspective of mining incentive. If mining becomes less profitable, difficulty lowers, max block size becomes smaller. Thus blocks would have more scarcity and users would need to pay more fees to get transactions into the blockchain, thus giving the miners more incentive. Some kind of equilibrium would happen.

I mean, if the average speed of a full node is the main factor we use to determine this, it really doesn't mean anything other than the fact that we can be reasonably sure that running a full node will remain in reach of regular users. It doesn't actually do much else.

Linking it to mining difficulty would increase mining (our security) if there was more Bitcoin usage and more fees (a higher reward, more miners, more difficulty), thus allowing for a larger block size.

I just changed my mind, I do believe that is actually the best solution. It requires more study for sure, to make sure there isn't some huge loophole. There is obviously the question of how exactly is the max block size calculated from the difficulty.

Or maybe when people can't get their transactions processed in a timely fashion, regardless of how much they pay in fees, they'll just abandon Bitcoin entirely and the miners will get nothing.

Seriously though, if reducing the number of transactions will increase miner revenue then why stop at seven transactions per second? Reduce the limit so that only one transaction is allowed per block and watch miner profitability go through the roof.

misterbigg, I don't think many here are rooting for a change where all scarcity is removed from the equation. I think that could be a disastrous move long term. There are however methods to retain some scarcity without having too much of it. My favorite so far is the solution where we give more freedom to the miners, they can basically decide the block size. At the same time we would put hard limits on block validation so that the full nodes will have to be able to validate them reasonably fast. This way the miners can't just create super large blocks since they would all be rejected.

I believe the hard limit for block size needs to be massive or lifted entirely, so that we don't have to ever do another hard fork, at least not thanks to this issue. The soft limit is another issue, it might not be needed either if the system in place is reliable.

It's because VISA and MasterCard are not Bitcoin. They are each a centralized, private payment system. There's no limit on the number of transactions they can process.

Do you understand that it is only scarcity of transaction space that guarantees a non-zero equilibrium level of fees (in the Bitcoin system)? When miners are forced to choose which transactions to exclude in a candidate block, due to limited space, they will obviously discard the transactions with the lowest fees (per kilobyte). This creates competition and drives the fees up to a new equilibrium level.

See my earlier post which predicts the future of block size and transaction fees.

While I can see your point, I still think that there should be a hard limit, however high that might be.  In this way, there is always an absolute for which large miners 'cheating' by trying to force out smaller players (via padding of the transaction queue or similar) will run into that limit.  Hopefully this absolute limit will discourage those unscrupulous players from turning to the dark side, simply based on the idea that there are going to be a percentage of players that they could not force out of the mining business, no matter how much larger they could grow on a relative basis.

However, upon further thought, I think that said hard limit should be pretty freaking high, in order to allow the soft limit to be our control method for many more years without further need of hard forks.  And if we are going to do this hard fork against the desires of some miners (which is probably a certainty) it's better that we get to it sooner rather than later.  If we start bumping up against the hard limit, some miners might just manage to profit from that artificial scarcity in ways that would turn a good portion of the miners aginst the idea of a hard fork, whereas they might otherwise not oppose one before we get there.

How high would such a hard limit be?  Can we estimate how many transactions per second that, say, a one Gb hard limit could process?  As already pointed out by many, we don't need to accommodate all of the transactions that occur in the world; but we need to be able to do much better than 7 per second.  What is a good target?  VISA's transaction volume?  Paypal's? Or VISA + Mastercard?  Once we decide, then we need to set it and let it go, and be willing to let the market in transaction fees and off-network transfers simply run.  We are going to get way too big to do this kind of thing twice.

Keep in mind that when we talk about off-blockchain transactions, we are talking about alternate block chains. These would be separate crypto-currencies with different properties. Ripple is one example (it relies on trust, unlike Bitcoin). I'm sure there will be others when the opportunity for profit arises.


There are a lot of things we'd rather see but the point being made is that there are limits to what can be done with Bitcoin, while keeping it Bitcoin (global consensus, proof of work, etc...) Raising the block limit by a non-trivial amount may not be practical.

It should be easy to see that if there was no limit on block sizes, that fees would trend towards zero (ignoring the OP's original stated problem of miners attacking other miners by producing large padded blocks). Do you understand that with increasing block sizes come smaller fees?

For that matter I've seen a lot of talking about bandwidth, storage, and processing power but it seems everyone has overlooked that:

Fees will decrease as block size is increased (all else being equal)

Do people not get this, or am I wrong?

I'd go as far as to saying greater than a dollar with 1/10th cent precision.

It reminds me of that 1010220 commercial. Can't buy much for less than a buck these days. That doesn't mean you don't receive change still down to the penny.

If this theory is true why don't Mastercard and Visa set a limit on the number of transactions they process in order to maximize their fee revenue?

Centralized services handling a larger amount of payments has another drawback that hasn't been discussed much, it's the fact that using a fractional reserve would become much easier. As long as the blockchain itself is the dominant transaction platform, widespread use of fractional reserve is impossible. This is one more reason to do everything possible to keep as much of the transactions in the blockchain as reasonably possible.

With this I mean the exact same thing as Gavin meant. Subcent transactions should be disregarded as not viable. Transactions worth more than $0.01 should be something that Bitcoin can handle. There really is no reason why it can't, only a whole truckload of FUD.

I don't trust off-blockchain transactions as much as transactions in the block chain.

Especially with off-blockchain transactions who rely on the "threat" that they could be executed by being put into the blockchain at any time there might be issues if it then takes high fees or a long time until these are even verified.

I'd rather see a dynamic solution with a VERY long warning beforehand, similar to what was already done in the past - something like "after this block which will be mined in 2 years block sizes following these rules will be accepted too, until then 1,000,000 bytes it is!".

+1

Freedom creates beauty every time it is tried.

Explain why this is a bad thing? A fixed block size maximizes the hashing power since it forces fees to increase to the equilibrium level. What's wrong with Bitcoin the block chain as the ultimate store of value, with the most amount of hashing power, and with the most accessibility for anyone with modest resources to verify transactions? So what if transactions are infrequent?

I consider it an enormous victory if Bitcoin's 1% of transactions becomes the lynchpin that backs the other 99% of off-blockchain activity.

There is most likely no need to do incremental changes. There are already pretty good looking suggestions on how we can simply let miners decide the block size. To do that we would need some fairly strict rules for how long validating blocks by regular nodes can take until they are rejected. This would create a cap for the block size that is actually relative to the processing power of most full nodes. That is something we want, I think.

The other interesting suggestion was linking mining difficulty and the block size. Those are the two decent suggestions so far. Finding a long term way to fix this is much better than simply making a one time increase. If there is a one time increase, it should be a massive increase together with a smaller soft limit, so that the soft limit can be raised more easily in the future if necessary.

Agreement!  I also think the max block size should be increased only by what is necessary. It still allows bitcoin to grow. It also means that that, unfortunately, a hard fork is necessary.

Gavin - the 250Kb test results. My prediction is that Eligius will pick up the slack when the blocks are saturated. Because there is a safety valve at present.