11 ms·
The Bitcoin Blocksize: A Summary
- pmorici 11y agoSomething I haven't seen discussed that I'm curious about is why a larger max block size necessarily means lower transaction fees. Ultimately miners decide which transactions to include in a block or reject so if miners feel they need to get a certain fee per transaction that is their prerogative regardless of the block size.
- kbenzle 11y agoAlso not addressed, why not decrease block dissemination time to 5 min, will that not do the same as doubling the block size?
- kardos 11y agoFor the same reasons that they made it 10 min rather than less to begin with [1] [1] http://bitcoin.stackexchange.com/questions/1863/why-was-the-target-block-time-chosen-to-be-10-minutes http://bitcoin.stackexchange.com/questions/1863/why-was-the-...
- DennisP 11y agoRight, bigger blocks take longer to propagate so you get more forking with a block that's too big compared to the time interval. This might change if Gavin's IBLT proposal [0] gets implemented. Basic idea is that the miners have most of the transactions already (otherwise they couldn't mine), so you don't have to transmit them again in the block itself. You just need a small fixed-size data structure that lets miners reconstruct the full block from the transactions they have already. Another idea is GHOST [1], which shortens the block time by letting all the forks take part in the consensus process, and get rewarded even if they don't end up in the final linear chain. It was proposed as a Bitcoin modification but just got its first production launch with Ethereum. [0] https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 [1] https://eprint.iacr.org/2013/881.pdf https://eprint.iacr.org/2013/881.pdf
- pstrateman 11y ago> This might change if Gavin's IBLT proposal [0] gets implemented. Such a thing already exists, blocksize has little to no effect on propagation time to other miners. http://bitcoinrelaynetwork.org/ http://bitcoinrelaynetwork.org/ Edit: not that this is not IBLT but another actually implemented setup
- maaku 11y agoBecause lowering the interblock time has a more detrimental effects, and raising it has more beneficial effects. To achieve maximum scalability you actually want the longest possible interblock time you can stand. 10 minutes is actually alright in that regard. I would have gone with 15 minutes myself.
- haakon 11y agoMiners typically include the highest-paying transactions first, naturally. If there is a consistent backlog of transactions waiting to be included, low-fee or no-fee transactions may have to wait a long time, perhaps indefinitely. This creates fee pressure - at least in a scenario where Bitcoin clients are intelligent about fees and are able to add fees to pending transactions so that block space is effectively auctioned out. This is not necessarily today's scenario, but Bitcoin is working towards it. But if blocks are not consistently full and there's no significant backlog, there is room for cheap transactions. This has been the case up to now. If the block size limit were to be increased, the assumption goes, there would again be room for cheap transactions - until they fill up again. In practice, we don't know if miners would actually include cheap transactions if it makes their blocks significantly bigger. Their incentives seem to be against it, since bigger blocks have higher orphan rates.
- prolixus 11y agoI think your last paragraph is right. Right now there's a default transaction inclusion policy in Bitcoin Core that only includes a small number of low to zero fee transactions. Under current conditions zero fee transactions have to wait a while to be confirmed. There's no proposal to change the default allowance for below standard fee transactions if the block size increases, so assuming cheap means zero or very low fee the increase in size will come from standard fee transactions which means increasing capacity won't drive down existing fees.
- maaku 11y ago> In practice, we don't know if miners would actually include cheap transactions if it makes their blocks significantly bigger. Their incentives seem to be against it, since bigger blocks have higher orphan rates. This is incorrect in fact. The Google search term you'll need is selfish mining. It's a well studied phenomenon that for sufficiently large miner they stand to benefit from having larger blocks.
- kardos 11y agoIf the pending transactions fit in a block, there's not much incentive to not include them -- it doesn't cost much, so miners can include them all in order to maximise fee revenue. But when there are more pending transactions than fit in a block, miners will sort by fee and include the biggest fees and reject the lowest fees. By growing blocksize, you avoid the situation where there are more pending transactions than can fit in a block.
- maxerickson 11y agoMiners will likely omit transactions that offer a fee that is lower than their cost of mining (at least eventually). This sacrifices some small amount of revenue on the current block, but should lead to higher revenue over the long term (assuming their cost levels make bitcoin an attractive transaction system).
- thekingofspain 11y agoHowever, that would only become a problem after centralization, correct? Otherwise, it would require a concerted effort by most/all miners to take the same approach, rather than competing for staying power etc.
- pstrateman 11y ago> Miners will likely omit transactions that offer a fee that is lower than their cost of mining (at least eventually). The marginal cost of each transaction in the block is approximately zero. The only effort is from propagation speed, however thanks to the relay network that effect is almost nothing. http://bitcoinrelaynetwork.org/ http://bitcoinrelaynetwork.org/
- maxerickson 11y agoThe cost of mining a single transaction is approximately the electricity cost to mine a block divided by the number of transactions in the block. Say it is $0.15. A miner can make extra revenue at ~0 cost by filling a block with $0.10 offered fee transactions, but if there are many of them, they may choose not to, from the belief that enough of them will turn into $0.16 offered fees in the future (the cost is clearly ~0 in the short term, it's harder to say what it costs them in the long term to propagate the impression that low fee offers will still eventually clear).
- wsxcde 11y agoI think you have the reasoning backwards. The argument the small-blockers are making isn't that we want to keep block size small to attempt to increase fees. Instead they're saying we want to keep block size small to avoid centralization pressures, and if this means higher fees then so be it. > Ultimately miners decide which transactions to include in a block or reject so if miners feel they need to get a certain fee per transaction that is their prerogative regardless of the block size. Again the issue is a bit more complex. A miner can of course enforce any fee policy they want, but that policy will only have a significant effect if it is enforced by a large pool. And suppose a large pool decided that they will accept all transactions, regardless of fees, up to the max block size, then all other miners have to deal with the consequences of this decision, because they have to validate the blocks produced by the large pool. This is what Rusty is calling large miners attacking smaller miners.
- CydeWeys 11y agoAn important thing to consider is that, while there probably is an ideal block size for the current set of conditions (risk of centralization, average Bitcoin network latency, rate of transactions), there's no a priori reason that it should be 1 MB. It may well be less than 1 MB, or it may well be more. 1 MB is arbitrary. My best guess is that the optimal current block size is somewhat larger than 1 MB.
- wsxcde 11y ago> My best guess is that the optimal current block size is somewhat larger than 1 MB. I disagree. There's good reason to believe the ideal block size is now smaller than 1 MB because large pools have been caught red-handed not validating blocks. (Which is like their ONE job and the the thing they get paid the big bucks for!) Presumably, the only reason they're doing this is because orphan rates are too high, which in turn suggests block sizes are too high.
- paulmd 11y agoClassic tragedy of the commons: for everyone as a whole, it's better to process transactions as fast as possible. But with the way incentives are currently structured, it's better for any individual miner to produce an empty block that propagates faster. Or in other words, to process transactions as slowly as possible. There's two ways you can fix the incentives. One would be to kill the block reward. You don't process transactions, you don't get any fees. This would likely cause a massive increase in transaction fees if the network were to retain its current hashrate (and thus level of security). The other way is to make a law, basically. You'd need a hardfork that refuses to recognize any block that isn't at least 75% full, but you keep the block reward and thus avoid blowing up transaction costs. This has the problem that the network could "stall out" under the right conditions (no incoming transactions, gigabyte blocksize, etc). Or instead of messing with incentives you can change the protocol itself - if everyone works on the same transaction set then all you really need is a fixed-size structure to propagate the winning hash, and there are no empty blocks unless there's no incoming transactions. Again, you're talking a hardfork and this one would involve core changes to the Bitcoin protocol.
- t0mbstone 11y agoThe problem with bitcoin is the idea that it even requires a mining pool or transaction fee. Bitcoin will die the moment someone figures out how to build a decentralized crypto-currency that doesn't need a stupid idea like "mining" to be functional and secure.
- wcummings 11y ago>Bitcoin will die the moment someone figures out how to build a decentralized crypto-currency that doesn't need a stupid idea like "mining" to be functional and secure. I'm not holding my breath
- sp332 11y agoTransactions will get processed eventually without a mining fee. It will just take longer, because many miners prioritize transactions with fees. "Mining" will eventually be unprofitable as well. And the only advantage to mining pools is to reduce variability in block payouts.
- Aqueous 11y agoYou can't get rid of mining - that's the cost of trust-less decentralization. You might be able to make mining more efficient, or based around some other finite resource besides computation power (like storage), but even that's a long-shot.
- tromp 11y agoYou could make mining more memory bound rather than compute bound, somewhat reducing electricity costs and requiring bigger upfront investments (in DRAM chips). This also vastly reduces the performance gap between commodity and custom mining hardware.
- joosters 11y agoWhy would that reduce costs? Miners would have to compete for memory & CPU then. Even altcoins that have tried this approach have seen custom hardware appearing if the coin grows popular enough. The approach just seems to be a desperate hope that home users will be able to mine profitably, but ultimately it still fails because those with more resources will win out.
- davidgerard 11y agoImportant point about this debate: * There is not the organic transaction growth for this to even be a problem, and there is no evidence there ever will be. Bitcoin's only real-world use case is illicit goods. * Even 20MB blocks would be susceptible to a cheap spam attack like the DDOS "stress test" a few weeks ago. This is the quintessential bikeshed: a fight to the death for insanely low stakes.
- Rmilb 11y ago> Bitcoin's only real-world use case is illicit goods. I think the 400 Million[1] in venture capital alone can disqualify this statement. [1] http://www.coindesk.com/bitcoin-venture-capital/ http://www.coindesk.com/bitcoin-venture-capital/
- davidgerard 11y agoThat would surely be "speculation on future real-world use cases". Which isn't nothing, but isn't present real-world use cases.
- DennisP 11y agoFrom the article: "In the last few months there have been increasing runs of full blocks, causing backlogs for a few hours."
- davidgerard 11y agoYes, I covered that in the second point.
- DennisP 11y agoThat doesn't sound like the same thing. A fuller quote: "In the last few months there have been increasing runs of full blocks, causing backlogs for a few hours. More recently, someone deliberately flooded the network with normal-fee transactions for several days" It sounds like the full blocks happened spontaneously for several months before the stress test.
- jackgavigan 11y agoWhat's really interesting for me about the Blocksize Debate is what it reveals about Bitcoin's governance. Most of the people involved agree that the blocksize limit should be increased (with the notable exception of Peter Todd) and the main disagreement seems to be about how (and how quickly) and the increase should happen. There also seems to be a hint of power struggle in the backlash against Gavin's push to increase the limit to 8MB. I personally believe that Bitcoin will need to evolve if it has any hope of surviving and maintaining its value. The fact that the core community appears to be having a tough time reaching consensus on this particular issue doesn't bode particularly well for the sort of changes that may be required in the future (e.g. changing the proof-of-work mechanism).
- Bae8anoh 11y agoRead up on the history of Mike Hearn, he has wanted to fork Bitcoin into his own governance for years, this is just an excuse. In 2011 he was proposing to Satoshi that he should take over the project[0], in 2013 he was trying to pitch the concept that development was stagnant and that a fork was needing to fix it[1][2], and now in 2015 it's again come about that he has found an excuse to attempt it (this time with some mild enthusiasm from part of the community). In the past Mike Hearn has pitched censorship features in Tor[3], attempting to subvert the inclusion of privacy fixes in Tor[4], proposed "redlists" of supposedly undesirable transactions in Bitcoin[5]. The current branch of Bitcoin XT already includes an alarmingly ill advised hardcoded blacklist of supposedly Tor exit nodes which are de-prioritized[6]. The measure of "consensus" has already slipped down to 75% when it become clear that 95% of the hashrate was never going to happen. The solution from Mike Hearn is that if miners don't want to get to 75%, he will simply hardcode his own centralized markers into Bitcoin wallets[7] to make sure it happens regardless. This is unbelievably toxic stuff, and spells certain death of Bitcoin if it goes ahead. [0]: http://pastebin.com/raw.php?i=3kt5Reeh http://pastebin.com/raw.php?i=3kt5Reeh [1]: https://www.reddit.com/r/Bitcoin/comments/29qafs/circle_ceo_issues_thinly_veiled_threat_of_hard/ https://www.reddit.com/r/Bitcoin/comments/29qafs/circle_ceo_... [2]: http://www.coindesk.com/bitcoin-core-development-falling-behind-warns-mike-hearn/ http://www.coindesk.com/bitcoin-core-development-falling-beh... [3]: https://lists.torproject.org/pipermail/tor-dev/2014-July/007167.html https://lists.torproject.org/pipermail/tor-dev/2014-July/007... [4]: https://lists.torproject.org/pipermail/tor-dev/2014-July/007173.html https://lists.torproject.org/pipermail/tor-dev/2014-July/007... [5]: https://bitcoinfoundation.org/forum/index.php?/topic/505-coin-tracking/ https://bitcoinfoundation.org/forum/index.php?/topic/505-coi... [6]: https://github.com/bitcoinxt/bitcoinxt/blob/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23/src/torips.h https://github.com/bitcoinxt/bitcoinxt/blob/73c9efe74c5cc8fa... [7]: http://sourceforge.net/p/bitcoin/mailman/message/34162353/ http://sourceforge.net/p/bitcoin/mailman/message/34162353/
- nothrabannosir 11y ago> A large mining pool used their power to double spend and steal thousands of bitcoin from a gambling service[3]. When it was noticed, they blamed a rogue employee. No money was returned, nor any legal action taken. Wasn't that the point of Bitcoin?
- Andrew_Quentin 11y agoFor people who are not familiar with the whole blocksize debate which has been raging in the bitcoin community for around three months now, even leading to outright censorship by theymos, perhaps asked to do so by "someone", the author of the post is highly biased and the article is biased too. It refers for example to an attack by Ghash, and then dismisses their explanation that it was an employee without providing much evidence and without pointing that his dismissal of their explanation was simply speculation. Moreover, it suggests that Ghash gained 50% of hashing power and nothing happened. In fact a lot happened, so much so that Ghash currently has around 2% of the hashing power. It is hard to present an unbiased view when one is necessarily biased. But as an engineer, one would expect someone like Rusty to present a more complete view of the problems as both sides see them and the solutions as both sides present them. His failure to do so raises questions on his integrity pertinent to his responsibility to present to the community a software which can work and problems are not hidden under the carpet. Specifically, the Lightning Network which wishes to change bitcoin from a payment system as stated by satoshi to some experimental, uncoded, and conceptually flawed settlement system needs to be openly presented with all its attack vectors laid out as a lot of money could be lost otherwise. I do not see how I can trust such code however when one is extremely biased and makes no attempt whatever to overcome it. Good enough is not sufficient where money is concerned Rusty. And to suggest that Gavin, or even Satoshi himself, is myopic, seeing only the "user" ui point of view, is slightly idiotic and shows that you do not quite understand the debate or you wish to wilfully mislead.
- RustyRussell 11y ago> It refers for example to an attack by Ghash, and then dismisses their explanation that it was an employee without providing much evidence and without pointing that his dismissal of their explanation was simply speculation. I did not dismiss it, how did you read that? > Moreover, it suggests that Ghash gained 50% of hashing power and nothing happened. In fact a lot happened, so much so that Ghash currently has around 2% of the hashing power. That doesn't seem to be related: they were close to 50% 4 months after the theft incident, and again 10 months after. Someone else queried that, and I did some digging to ensure that my memory of event order was correct. See: https://www.reddit.com/r/Bitcoin/comments/3fxvbr/blocksize_a_debate_summary/cttdfi4?context=3 https://www.reddit.com/r/Bitcoin/comments/3fxvbr/blocksize_a... > And to suggest that Gavin, or even Satoshi himself, is myopic, seeing only the "user" ui point of view "only"? In my final paragraph I tried to draw the distinction between the priorities of the different views. You seem to have read things in my article which aren't intended :(
- meshr 11y agoI have a question, why not to solve the bitcoin issues another way: by decreasing the amount of transactions by changing the way of paying with bitcoins. I suggest using bitcoin wallets as a cash banknotes and send bitcoin private keys (i.e. the wallet itself) instead of paying from the wallet to transfer money. So everyone should have a set of bitcoin wallets with different bitcoin amounts instead of using one bitcoin wallet. This method has some advantages: instant transactions, zero fees and anonymity. The disadvantage that I can see is the necessity of development the mechanisms of having “the change”, probably specialized bitcoin fork, or it can be solved by using hybrid method: usual transaction + bitcoin wallet private keys sending. “The change” is not necessary for some types of payments: like gifts, balance replenish, or periodic payments which bitcoin has lack of support now. It’ll definitely help to decrease amount of transactions here.
- kang 11y agoBecause no one prevents the sender to keep a copy of that wallet. Wallets are nothing but list of your private keys. Suppose I gave my private keys to you, what prevents me to not use them before you use those keys?