On the blog of Peter Vessenes's Bitcoin Foundation Gavin Andresen offered an outline of measures he would like to see to improve the ability of Bitcoin to scale in the future, and one measure he proposes is a hard fork over blocksize. The measures mentioned include:
- Changes to initial block synchronization that includes downloading a chain of block headers before downloading actual blocks.
- A library, 'libsecp256k1' by Pieter Wuille optimized for Bitcoin's elliptic curve used for transaction signing to replace the current implementation imported from OpenSSL.
- A "pruned" block database implementation for clients that have gone through initial sync, and which may eventually be enabled by default.
- Initial synchronization by downloading the set of unspent transactions rather than the whole blockchain is mentioned as something that may be explored eventually.
After this Gavin presents his case for a hardfork over maximum blocksize. Below are highlights of his proposal for a new maximum blocksize:
- A new Inital maximum block size such that a full node may be run by "somebody with a current, reasonably fast computer and Internet connection, running an up-to-date version of Bitcoin Core and willing to dedicate half their CPU power and bandwidth to Bitcoin."
- After that Blocksize increases 50% per year for the next 20 years.
Gavin offers this 50% yearly figure based on Nielsen's Law of Internet bandwidth which supposes high speed Internet connections double in speed every year. This proposal for a jump to a new larger block size then committing to doubling block size every year for two decades is likely in the long run to present a substantial increasing barrier to entry for operators of full nodes, particularly in geographic areas where bandwidth growth has been inconsistent.
mircea_popescu the problem with gavin's idiocy is that roughly speaking, the square of the block size and the total network hash are on opposite sides of an equality, which describes total network security.
mircea_popescu so basically, he's proposing significant downstepping of current blockchain security.
mircea_popescu neither of these are getting merged into bitcoin, whatever gavin says or whatever forks happen.
mircea_popescu if indeed they're stupid enough to fork it, i will sink their fork on the open market.
mircea_popescu and if that's the path they wish to use to introduce faux bitcoin-lite for the us domestic market, that's fine, but it won't go over any better than an attempt from scratch.
mircea_popescu "we" know what bitcoin is and why we're using it.
This is very true.
Mircea, can you explain what you mean by "the square of the block size and the total network hash are on opposite sides of an equality"?
Consider the simple problem of a blockchain with infinite block size and zero block reward. Is its security then zero ?
Consider the reverse problem, of a blockchain with zero block size. Is its security then infinite ?
Consider a finite block size and infinite block reward (disregarding 2ndary effects). Is the security also infinite ?
Consider the case of oil supply halving. Does price double or explode ?
So that's what it is. The only way Bitcoin has a future is through the block size remaining limited. Bitcoin is not here to serve the poor. Fuck them. That's what Bitcoin means.
Thanks, but my question was specifically regarding the equality you mentioned which interests me:
(Block size)^2 == Network hashrate
I know this is simplifying what you meant, but you get the idea.
I mearly meant it's not linear. The exact exponent is guesswork more than anything.
Consider the variables network security (S), network hashrate (H), and block size (B).
If there is a higher hash rate, then it is harder for an attacker to insert malicious blocks, so the security is higher, thus they are modeled by some function:
(1) S = k * H ^ x
with some positive values for k and x.
If the block size were decreased, then there would be more competition to get transactions into blocks and people would pay more transaction fees, therefore mining rewards would rise, therefore people would increase mining power, and the network hash would rise. The opposite happens if the block size is increased, so block size and net hash are inversely proportional, modeled as:
(2) H = k / (B ^ y)
again for some positive values for k and y. Put these together and you get a function describing network security as a function of block size and hash rate:
(3) S = k (H ^ x) / (B ^ y)
which can also be written:
(4) S (B ^ y) = k (H ^ x)
which represents the equation alluded to by Mircea Popescu, and he suggests that x is about 1 and y is about 2.
Thanks Peter.
As I understand it, the argument hinges on the statement:
"If the block size were decreased, then there would be more competition to get transactions into blocks and people would pay more transaction fees, therefore mining rewards would rise, therefore people would increase mining power, and the network hash would rise."
I'm not sure that's a given. Obviously in both extreme cases of a block size of either zero or infinity, transaction fees will not be paid. This means that the function will have a maximum at some point.
I don't think anyone has proven that this optimum size is less than (or more than) the current block size, so I think the
H = k / (B ^ y)
equality cannot be assumed correct.
Yes, it is hard to say how things will work if the blocksize is changed, since we have no experimental data to base this on.
After thinking some more, I agree that the situation is more complex than I stated before. The miner reward are influenced by two things, the number of transactions per block and the fees per transaction.
As the blocksize approaches 0 the number of transactions is limited and is forced down toward 0, and people find the system less useful so the use less transactions, or they come up with ways to combine transactions together, or they work off the blockchain and only put important stuff on there. As blocksize increases, there will not be an infinite increase in transactions per block, at some point people have done all the transactions they want to do and so the number levels off.
Looking at the fees per transaction, as you approach 0 blocksize people will be forced to pay more to get their transactions included, so the fees rise, but only up to a point. People will not pay infinite amounts to get transactions included, they would just find other systems to use. At the other end, if blockspace is unlimited, then everybody will send zero fee transactions. So the graph is something like e^(-x), with a finite amount at x=zero and decreasing asymptotically toward zero as x increases.
Since miner reward = (number of transactions) x (fees), we can multiply these two functions together, and what we get is a graph that starts at zero, rises toward some maximum, and then decreases toward zero.
As you say, there is no way to know now which side of the maximum we are at, unless we change the block size and see what happens experimentally. The location of the maximum will also shift over time as the total demand on the system changes. But we can say that an infinite expansion of block size will reduce miner rewards, and therefore will lower security (also, decreasing block size would limit usage, lower total miner rewards, and decrease security).
The big question we have yet to answer: if we were to increase the block size a small amount there is a possibility total block reward would increase, but would the small increase in network security outweigh the costs associated with a hard fork and increased memory/bandwidth usage?
Thanks for taking them time to discuss, Peter. I agree with you there about reducing block size – as block size approaches zero the system is becomes less useful and other systems will be used.
I tend to disagree with you about the fees per block as they increase. Pools and solo miners determine the txs that go into a block. Well mempool does, but txs can be filtered. If a pool wants to, they include whatever txs they wish.
If increasing blocksize meant more zero fee txs, as a pool I'd just decide to not process them. If it becomes obvious that tx time to confirmation becomes a function tx fee, there is no downward pressure on the tx fee.
On your last question, I have no idea how to assess that. A related but simpler question would be "will the fee per kb per block remain the same?" . That is much easier to assess, although not predict.
In summary: the situation is still too complex to confidently predict an outcome. I can see advantages and disadvantages to both smaller and larger block sizes, but I can't prove which is likelier, and I don't think anyone else should be confident of predictions of the outcome at this point in time.
Nobody is proposing an infinite block size.
A) You're the enemy here. Stop pretending, it may work on tarddit and tardstalk.org and wherever else retards gather.
This isn't that. We've known you've turned for a while, we took measures to sterilise that a while ago, it's a fixed problem. Stop pretending like your castration never happened, or that because you're now castrated you're also now forgiven. You're not.
B) Yes, you are. The series x + (1/2)^k x is infinite. And fuck you for imagining the USG patented retardation of "sunset clauses" is going to fool anyone. Just how fucking retarded are your handlers, huh ?
Seeing how the earlier discussion actually neglected to mention a perfectly valid alternative avenue to evaluate the idiocy of this proposal, consider that the main (really, in practical terms the only) vulnerability of Bitcoin at the moment is that while miners are rewarded for mining, relayers are not rewarded for relaying. This is a sore oversight on the part of Satoshi, privately admitted at that, and unfortunately very difficult to fix.
USGavin's proposal consists of significantly increasing the burden on the full nodes, while doing nothing to address the actual problem threatening Bitcoin. This, of course, is not the direction a responsible head of a FOSS project steers things. It is however the exact direction a puppet of Microsoft tries to steer a standards discussion.
Interestingly Eric Matrindale of Bitpay wants to come up with a solution for rewarding full Bitcoin nodes for relaying transactions. He also had a few ideas of how this would be implemented. But as you have stated, this is a difficult problem to solve. I.E. it's not getting solved anytime in the near future.