I haven't seen any compelling arguments as to this supposed conflict-of-interest with Blockstream, to be honest.
It's pretty simple. Blockstream is in the business of off-chain scaling. Probably both mainchain and offchain scaling is required for Bitcoin.
You can't expect those core devs to be objective. Because of their business interests, they are going to be slightly to strongly biased
against mainchain scaling, even if that is not in the best interests of the larger community.
When you say "in the business of" what do you mean, exactly? What is the business model here, and where does the profit come in? In any case, we're talking about volunteers here, so I'm not sure it's even fair to say that devs on an open source project can't have bitcoin-related interests. Let's assume that some devs
do have some conflict of interest that would cause them to stonewall attempts increase the block size limit. Even so, don't we have to assess any proposal to increase the limit on its own merits (vs. accepting it on the basis that it is an alternative to Blockstream)?
The code has to be taken on its own merit. Whether its Core or XT. I am not here arguing against Gavin, the person (whatever his conflicts of interest may be).
And like I said, there's nothing wrong with forking the code if Core devs are indeed "compromised." But if the code is not technically sound or is opposed on a philosophical level by most devs, miners and users, it simply won't be adopted. The best chance for a limit increase is to take a much more conservative approach than BIP101, which actually has a chance at reaching consensus. The bolder the scaling regime, the less chance it has. It's as simple as that.
There's this bizarre idea that we have to determine the block size limit (if any) forever,
today, partly because people are terrified of the idea of forks down the road. The fact is: of course there will be hard forks in the future. There will be debates about protocol changes in the future that will make this issue pale in comparison. Get used to it, people. I actually believe quite the opposite of most XT supporters on this question -- I think if we conservatively and incrementally increased the limit (to say 2MB) and did not experience serious detriments to security, that it would be unquestionably easier to fork the limit up the second and third times around.
This is how consensus works -- it's messy, painful and takes time, but it's the best damn thing we have. A democracy for bitcoin is the death of bitcoin -- it will simply be co-opted as all governments have been.
I was referring to those quotes in my earlier post, I still do not consider other people saying bad things about Mike Hearn to be evidence of his wrongdoing.
Since you are not a Core developer, nor do you read the bitcoin dev list, you would not know. Thus, it sounds like you would not budge regardless of his behavior, or impediment on development. That's not a reasonable position -- it means you give Mike Hearn a free pass no matter what. Ignorance is not an excuse for that.
How would you approach a child endlessly screaming in a classroom -- disrupting all the other children's capability to learn? Let him stay and endlessly disrupt, to the detriment of progress?
I urge you to do your own research and actually
read the past several months of threads on the bitcoin dev list. Endlessly flailing around like a child and making threats to have commit privileges pulled is not constructive. Whether you want to take the word of several devs
other than Mike Hearn is up to you. But again, you are taking a completely one-sided position.
So people should not question the project? More specifically I suppose this relates to questioning the governance of Bitcoin? I would strongly disagree that we should not question the governance of Bitcoin especially considering the problems we are facing and the importance of the questions that need to be answered, who decides is a political question not necessarily a technical one.
Of course, people should question everything. I'm a skeptic. But there is a significant difference between that and turning every technical discussion into a political one, and refusing to cede any ground in any argument. At some point, no one will be willing to work with you. That's just a practical reality. Hearn simply cries louder and louder when people reject his ideas, and tries to leverage allegations of character assassination and censorship to rally the user base against those who oppose him. Unfortunately for him, crying might work for babies, but it doesn't work for adults.
You want to change the governance model? Go ahead and propose changes to the BIP model. Do it. And if your ideas are well-reasoned and achievable, you may gain some ground. If not, you can fork the code.
That's how this works. Endlessly crying about changing the governance model or the need for alternative implementations will achieve precisely nothing. Take action or don't. Don't complain to me about it. If no one supports your ideas, you're just irrelevant. Remember, bitcoin already exists, and is chugging along just fine. So until you -- and others that are so disgusted by Core -- come up with alternatives with widespread support, this is a non-issue.
I am not as a matter of fact I would support most of the other BIPs, I am somewhat fixated on the need for the code to be implemented however before I can support it in the form of running full nodes or mining. If you think that time is completely irrelevant in relation to increasing the blocksize then you are the one not in touch with reality, time is most definitely relevant to this discussion.
Why do you constantly ignore everything I say? I said "time is irrelevant
without technically sound code to run." Inventing this sense of urgency (yeah, blocks are less than half full, and no, a temporary fee market is not the end of the world) doesn't justify running technically unsound code. Again, feel free to respond to my technical arguments made here:
https://bitcointalk.org/index.php?topic=1163319.msg12332549#msg12332549Produce a workable alternative, and we can talk. Implementing code that a) threatens network security and b) threatens a political civil war that may fracture bitcoin's user base forever, is not a workable alternative. Most people intelligent enough to use bitcoin simply won't fall for that kind of idiocy, no matter how much false urgency you attach to it (and that was made apparent by XT's demise).
Regarding b), you do realize that's what Nick Szabo was getting at re: "civil war," right? Because if the consensus threshold is lowered to an extent that it is a "democratic" decision (majority rules, like 75%), one must have a very elementary understanding of market incentives (and a lack of understanding of game theory) to assume that only one blockchain will survive. Consider that a fork is achieved with 65% of hashing power + a lucky streak. Post-fork, hashing power is split 65-35. Now --
if a miner believes that the Core chain will prevail, then by remaining on the Core chain, he will increase his relative hashing power (and share of mining rewards) by nearly 300%. That is a
huge incentive not to cede to the mining majority. Then you have miners who will support one chain or the other purely out of political beliefs. Then you have miners who will do just that, up to a point where economic disincentive (or rather, fear of economic disincentive) becomes too great. Then you have potential attacks (like NotXT) which would make miner support even more opaque leading up to a hard fork. In such a situation, multiple surviving blockchains (and not necessarily just two) is a very real possibility. And if that goes on for long, too much money will have changed hands to ever turn back the clock. Bitcoin will be forever broken into multiple blockchains.
Actually, I'd rather just refute you here. I stopped responding to you in that thread because you repeatedly ignored nearly every argument I made, and continually repeated arguments that I had already addressed. This is the "Mike Hearn" approach. At some point, I'm not going to keep talking to a brick wall. I can't waste my time on that shit.
I do not think that increasing the blocksize would lead to a massive increase in orphaned blocks. Since most pools today are already run in high bandwidth data centers which would not be severely effected by increased block propagation times due to an increased blocksize. It would also be unwarranted to think that no increase in the blocksize is technically feasible considering that one megabyte is just an arbitrary number, why not half a megabyte or two megabytes? There is nothing special about the one megabyte blocksize limit it was put there just as a temporary fix after all.
Regarding "Since most pools today are already run in high bandwidth data centers which would not be severely effected by increased block propagation times due to an increased blocksize" I ask that you provide evidence. I won't accept that at face value. What is your definition of "high bandwidth data center" and you assign this label to what percentage of miners? What proportion of Chinese miners vs. others, and does it matter to you whether Chinese miners are disproportionately affected? (Of course, that point will determine whether you have miner support for any fork
) Should the rest of the miners be written off (they should create their own altcoin, as Hearn says)? No increase in orphaned blocks -- at 8MB? 32MB? 1GB? Show me numbers. Show me proof that bandwidth capabilities will keep up with the limit -- hint: you can't. And I highly doubt they will, considering the scaling regime is based on Moore's Law, whose obituary is being written as we speak. We are talking about
seconds among multiple peers here. Not minutes. Conservative is the
only acceptable approach.
That "you don't think something will happen" isn't an argument. It's quite obvious you are not a developer or engineer. It's pretty well understood from an engineering perspective that conditions at drastically different scales are not similar (thus, not predictable). So much of your understanding of technical issues seems to be little more than "nothing bad can possibly happen." Quite the opposite: the saying goes "everything that can go wrong, will go wrong."
Regarding 1MB -- I'm not arguing for a permanent 1MB limit. But implementing a limit that is unrelated to demand is essentially limitless, and therefore very dangerous. Keep it in line with demand and we can likely simulate the conditions and prevent attack vectors before people lose many millions of dollars over unnecessary recklessness. In the thread I linked above, I laid out one possible attack vector that, with sufficient hashing power, might enable a miner to use spam attacks to increase block size (up to say, 8x or 16x the current limit, whatever the case may be), and subsequently force high-latency miners to SPV mine. With enough hashing power, he could then exploit SPV miners by selfish mining. This is very relevant to the bandwidth capability of Chinese miners.
Time is relevant and if we do not have the perfect code by the time does run out then we will just have to choose the lesser of two evils, that is reality.
No, that's a fundamental misunderstanding of consensus. You have it backwards. Time does not run out, and bitcoin remains. Robust as fuck, that bitcoin! The lesser of two evils is the protocol that achieves consensus. Anything less is not bitcoin. So if your alternative doesn't cut the mustard.... sorry. Then the status quo prevails until something better comes along. (Shrug)
I can agree with you that scaling should be a meusure of throughput and not just blocksize and that any other means to make throughput more efficient should be implemented, I do not oppose this. However it is impossible to tell the difference between "spam" and legitimate transactions which is why I find most solutions to the "spam problem" problematic, a feature of a permissionless network I suppose.
Not at all, it's quite simply, really. And it's not a consensus issue, so it's an easy fix. The default Core settings already define outputs < 546 satoshis as spam. Now, it's possible for smaller outputs to be relayed, but only if node operators alter the conf files. In practice, rarely do smaller outputs get relayed. Personally, I don't view the ability to send outputs of fractions of a cent on the main blockchain to be important, and would be quite happy to see such spammers penalized for bloating the chain. As it stands, the cost of their bloat is being socialized among all bitcoin users transacting on the blockchain. We could raise the dust threshold and/or have the default Core settings require additional fees based on dust outputs to disincentivize spam.
https://bitcointalk.org/index.php?topic=1171182.msg12331532#msg12331532Not increasing the blocksize in Core is forestalling and most definitely is a form of inaction. It can only be defined as action once the code is actually implemented. Actions speak louder then words as they say.
Again, this isn't how engineering and software development work..... If you were preparing a new release of a major, acclaimed video game, would you release it as buggy, scarcely-audited code? Or would you do it right? Indeed, actions speak louder than words.
I've got too much goddamn money on the line to fall for that bullshit.And now that I've wasted probably 2 hours of my life writing this book -- don't take it as a victory if I don't respond to your next post. I've wasted too much time already, and I think this forum likely by now is less prone to fall for these "sky is falling" and "Core is evil" arguments.
