41–50 of 96 posts
Earlier quoted context omitted.
You are getting downvoted (you and the other green username) because hacker news is not a community that values posts that are purely personal insults. Try posting some ideas next time.
There's no insults in my comment, just statements of fact and links to supporting evidence.
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 incre…
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…
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.
What is more likely is that when that problem is solved it will be applied to bitcoin rather than create a new coin.
Earlier quoted context omitted.
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.
It sounds like the full blocks happened spontaneously for several months before the stress test.
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…
An 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. 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…
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.
Earlier 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…
Anyone can "fork" bitcoin.. No one will accept their fork, but they can go right on and do it. This is my first hearing of Mike Hearn, but I don't understand your attacks on him. For one, I'd be ok with Tor traffic being de-prioritized in an attack since that is commonly where an attack is coming from anyway. The centralized list is concerning, but de-prioritization rarely matters anyway (ie, outside of when the netw…
The hardcoded list of "bad" peers is effectively worthless (it's already hopelessly out of date), and the additional service which downloads a new blacklist from a centralized website is completely insane. The reality of the situation is that if anybody with criminal intent wants to attack the Bitcoin network you need exactly two IP addresses (one v4, one v6) to completely disable all new incoming connections on all nodes in the network. This patch doesn't change that fact, nor that criminals often have botnets with unlimited access to new IP addresses every second of the day.
It doesn't achieve the stated design goal, and introduces new vulnerabilities which aren't stated in the commit.
> All of his other proposals are just that, proposals and "lets talk about this and the problem". I hate to think if I proposed/discussed a bad solution to a problem and suddenly I'm part of some conspiracy theory.
Bitcoin isn't like any other software on earth, it can't exist in fragmentation or in consensus incompatible forks. Operating on a fork of the software with soft consensus changes or simply operational changes that do not affect consensus are completely fine, that happens today under the assumption that you are somewhat at risk if you run software that is even slightly different to anybody elses. Some nodes in the network for example support different P2P commands, and that's fine because the P2P network is not part of the consensus at all. The linked discussions are mostly harmless, it is extremely positive that all scenarios and eventualities are debated out in the open.
Prompting companies and individuals to attempt a hard fork of the network without consensus is another matter entirely. In the light of that, the previous discussions lose their innocence somewhat.
Earlier quoted context omitted.
Also not addressed, why not decrease block dissemination time to 5 min, will that not do the same as doubling the block size?
For 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-...
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
An 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.
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 to reduce their orphan rates.
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.
So no, BTC is not much good for illicit goods.