Earlier quoted context omitted.
Classic 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 proce…
If you required each block to be at least 75% full, what's to stop miners padding out the blocks with trivial transactions?
The Bitcoin Blocksize: A Summary
61–70 of 96 posts
Re: The Bitcoin Blocksize: A Summary
#62Earlier quoted context omitted.
The 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…
> they may choose not to, from the belief that enough of them will turn into $0.16 offered fees in the future Another miner will pickup those transactions and mine them. Blocks are either full and there are fees or blocks are not full and fees are approximately zero. Unfortunately the block size cannot be limited by individual miners.
(Which I realize is for a long time in terms of there being a block reward, but if bitcoin falls by 50%, so does the reward...)
Re: The Bitcoin Blocksize: A Summary
#63It 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.
Re: The Bitcoin Blocksize: A Summary
#64Important 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
#65Earlier quoted context omitted.
> they may choose not to, from the belief that enough of them will turn into $0.16 offered fees in the future Another miner will pickup those transactions and mine them. Blocks are either full and there are fees or blocks are not full and fees are approximately zero. Unfortunately the block size cannot be limited by individual miners.
This is only true while there is a glorious block reward subsidizing everything. (Which I realize is for a long time in terms of there being a block reward, but if bitcoin falls by 50%, so does the reward...)
(In general you cannot get 10+ MW of power without agreeing to pay for installed capacity and energy separately)
Re: The Bitcoin Blocksize: A Summary
#66Earlier quoted context omitted.
Classic 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 proce…
> Classic tragedy of the commons You're absolutely right on that, but you have the issue backwards. Each individual miner has an incentive to build a block which pays the most in fees. That means that as long as the transaction rate is less than the absolute limit, fees will tend towards zero. (Any fee is marginally better than nothing). The size of the block and propagation time are no longer strongly correlated tha…
Everyone also benefits from high scalability of transaction processing, so ideally transaction fees should stay low or zero. I don't accept the idea of meta-currency (alt-currencies and sidechains) to rectify this situation - too much risk when you have a known quantity that works pretty OK. It also decreases security by splitting processing power. If the problem is that it doesn't scale well, fix it, don't replace it. Joel on Programming's #1 Thing You Should Never Do: start over from scratch.
It's impossible to maintain the massive amount of processing power spent on this solely through transaction fees. Block rewards effectively socialize this collective interest in network security though a very low level of inflation, which hits the right population (Bitcoin holders as a whole). To me transaction fees should be nothing more than spam prevention, to prevent a DOS attack from clogging up the transaction blocks.
Really there's no reason you couldn't have an arbitrarily-large transaction block as long as the bandwidth is reasonable. You still have the problem of the chain becoming too great in size, but that's a problem with some pretty obvious answers.
Re: The Bitcoin Blocksize: A Summary
#67Earlier quoted context omitted.
Read 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 so…
I was ready to be persuaded by your first statement: "In 2011 he was proposing to Satoshi that he should take over the project[0]", but then I actually clicked through the link you provided and, while expecting some shocking revelation, I instead found what seems to be a solitary email sent to the ether so to speak and a very reasonable email too at that. This "attack" on someone who worked for google as a network en…
Re: The Bitcoin Blocksize: A Summary
#68An 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.
> My best guess is that the optimal current block size is somewhat larger than 1 MB. The optimal current block size is without a doubt smaller than 1MB. The two most important metrics for block size limit are node count and miner validation. Node count has been continually dropping for years despite heroic efforts to improve performance in bitcoin core. Miners have been found to be blindly mining blocks in an attempt…
... see what I did there?
Re: The Bitcoin Blocksize: A Summary
#69Important 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.
You have a lot to learn; I recommend starting here: https://medium.com/@lopp/the-multifaceted-nature-of-bitcoin-...
A deeper dive here: https://www.youtube.com/watch?v=IgETC2JMUBI
Re: The Bitcoin Blocksize: A Summary
#70Earlier quoted context omitted.
> Classic tragedy of the commons You're absolutely right on that, but you have the issue backwards. Each individual miner has an incentive to build a block which pays the most in fees. That means that as long as the transaction rate is less than the absolute limit, fees will tend towards zero. (Any fee is marginally better than nothing). The size of the block and propagation time are no longer strongly correlated tha…
Separate of the blocksize issue - fundamentally I don't think the network should run on the back of transaction fees. The benefit of a high hashrate (a secure network) isn't limited only to those actively transferring money. Anyone who holds Bitcoin has a stake in the network. Everyone also benefits from high scalability of transaction processing, so ideally transaction fees should stay low or zero. I don't accept th…
0.00625 BTC in fees is enough to match the current block reward.
That's to say the current security of the network would continue on if everybody paid $1.63 per transaction in fees.
> You still have the problem of the chain becoming too great in size, but that's a problem with some pretty obvious answers.
Uh... like what?