The Bitcoin Blocksize: A Summary • Hacker News Board

Re: The Bitcoin Blocksize: A Summary

#21

Post by joosters » Wed, Aug 12, 2015, 3:59 PM UTC

tromp wrote: post #18

Aqueous wrote: post #13

Earlier quoted context omitted.

You 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.

You 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.

Why 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.

Re: The Bitcoin Blocksize: A Summary

#22

Post by DennisP » Wed, Aug 12, 2015, 4:08 PM UTC

davidgerard wrote: post #16

Important 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.

From the article: "In the last few months there have been increasing runs of full blocks, causing backlogs for a few hours."

Re: The Bitcoin Blocksize: A Summary

#23

Post by maaku » Wed, Aug 12, 2015, 4:15 PM UTC

kbenzle wrote: post #3

pmorici wrote: post #2

Something 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.

Also not addressed, why not decrease block dissemination time to 5 min, will that not do the same as doubling the block size?

Because 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.

Re: The Bitcoin Blocksize: A Summary

#24

Post by maaku » Wed, Aug 12, 2015, 4:17 PM UTC

t0mbstone wrote: post #9

The 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.

> 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.

Yup. But I wouldn't hold my breath. No one has ever created a decentralized consensus algorithm with the properties bitcoin has, before or since. And since bitcoin achieves its unique properties as a result of the economic costs of mining, asking for a mining-less bitcoin is kinda like wishing for a perpetual motion machine.

Re: The Bitcoin Blocksize: A Summary

#25

Post by maaku » Wed, Aug 12, 2015, 4:19 PM UTC

davidgerard wrote: post #16

Important 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.

> Bitcoin's only real-world use case is illicit goods.

Please get up to date with things. Bitcoin is huge in the remittance world, and bitcoin-like technology is being tentatively explored in all realms of financial technology.

Re: The Bitcoin Blocksize: A Summary

#26

Post by jackgavigan » Wed, Aug 12, 2015, 4:21 PM UTC

What'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).

Re: The Bitcoin Blocksize: A Summary

#27

Post by davidgerard » Wed, Aug 12, 2015, 4:22 PM UTC

maaku wrote: post #25

davidgerard wrote: post #16

Important 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.

> Bitcoin's only real-world use case is illicit goods. Please get up to date with things. Bitcoin is huge in the remittance world, and bitcoin-like technology is being tentatively explored in all realms of financial technology.

> Bitcoin is huge in the remittance world

Really, who with? I recall rebit.ph saying the problem was they couldn't actually sell enough BTC for PHP at the .ph end, for example. Bitcoin makes the transmission bit cheap, but that bit was cheap already.

Actual remittances startup company guy talks about why Bitcoin doesn't work for remittances: https://www.regalii.com/blog/the-bitcoin-remittance-myth

Re: The Bitcoin Blocksize: A Summary

#28

Post by maaku » Wed, Aug 12, 2015, 4:23 PM UTC

haakon wrote: post #4

pmorici wrote: post #2

Something 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.

Miners 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 aucti…

> 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.

Re: The Bitcoin Blocksize: A Summary

#29

Post by davidgerard » Wed, Aug 12, 2015, 4:23 PM UTC

DennisP wrote: post #22

davidgerard wrote: post #16

Important 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.

From the article: "In the last few months there have been increasing runs of full blocks, causing backlogs for a few hours."

Yes, I covered that in the second point.

Re: The Bitcoin Blocksize: A Summary

#30

Post by wsxcde » Wed, Aug 12, 2015, 4:25 PM UTC

pmorici wrote: post #2

Something 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.

I 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.