Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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.

I actually agree with this one hundred percent, I am not the ideological opponent that you think that I am.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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.

We do disagree on this point, I suspect that it will be much more difficult increasing the blocksize the second time around, I even think it could cause a split in the future. This is not a question of engineering however but of social dynamics and psychology.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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.

Bitcoin is a form of democracy where the economic majority decides, whether you like it or not this has always been the case. I can agree with you however that we should not build similar systems of governance that states have today since that would lead to some of these same problems, which is why I think that governance should take place on the multiple implementations level as opposed to attempting to build governance structure on top of Bitcoin Core which in my opinion would be doomed to failure exactly because of these same political problems.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

Quote from: VeritasSapere on October 02, 2015, 01:00:08 AM

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.

I would not give Mike Hearn a free pass no matter what, I could be wrong and I am totally open to admiting my fault if I am. I have so far not seen any evidence that would justify banning him from the developer list. Especially considering the things that he has said that has lead to him being banned I actually agree with. However if he has been disrespectful or completely unreasonable then I will admit that I was wrong about the person, I would still support the code however even if I despise the individual responsible for it.

Quote from: VeritasSapere on October 02, 2015, 01:00:08 AM

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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.

I disagree and I found his arguments to be rational. https://medium.com/faith-and-future/why-is-bitcoin-forking-d647312d22c1

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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.

This is exsectly my point, we should not attempt to make the BIP model the governance model for Bitcoin, for the same reosons I explained before this would be a terrible idea since it will recreate some of the same problems of governance that large states do today. Mike Hearn did take action and I take action by supporting BIP101, I do respect this.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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 do think that any one of these five Core developers have the power to veto any change to the blocksize. It would only take one unreasonable person to completely stall development in Bitcoin Core. This in my opinion is a dangerous situation especially considering we do not yet have widespread support for alternative implementations. I do consider not increasing the blocksize at all over the long term to be a very real threat to the continued success of Bitcoin. This article explains very well why I think that such a scenario would be catastrophic for Bitcoin:https://bitcointalk.org/index.php?topic=946236.0

Quote from: VeritasSapere on October 02, 2015, 01:00:08 AM

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.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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#msg12332549

I have already responded to most of the issues you have raised there and you do not acknowledge my counter arguments because they are political in nature.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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

I do not think that BIP101 threatens network security, and the treat of a political civil war should not sufficient reason to not support a contentious fork.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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

I think that fifty one percent is enough to justify a fork, therefore according to that logic seventy five percent is more then enough to justify such an action. I would support miners supporting one chain or another purely out of political believe, I actually think that this is a good thing. I actually think that over the long term Bitcoin will have to split and that this is off political necessity because of the spectrum of different beliefs that exists, and people would want different Bitcoins to reflect their different beliefs. This over the long term is inevitable in my opinion. Part of the beauty of this solution is that it does solve the problem of the tyrrany of the majority.

Quote from: VeritasSapere on October 02, 2015, 01:00:08 AM

This is the article I wrote on the subject you are welcome to criticize me on the thread that I started:
https://bitcointalk.org/index.php?topic=1164464.0

If you would like to continue the discussion we where having last time I believe this is where we left it at last:
https://bitcointalk.org/index.php?topic=1163319.msg12357136#msg12357136

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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 felt like you where actually ignoring my arguments which according to your own admission you where, because you do not consider them valid because they involve political thought.

Quote from: VeritasSapere on October 02, 2015, 01:00:08 AM

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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 Wink

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

I have discussed this issue extensively and it again seems like you are ignoring my arguments. I have reasoned that there is a free market of pools and that pools are actually a type of representative democracy for miners. The vast majority of miners do not run full nodes and point their hashing power towards pools instead. Pools can be setup by anyone almost anywhere in the world in data centers or locations that have high bandwidth which have favorable conditions for block propagation even with much larger blocks then we do today. This is where the decentralization of the hashing power becomes more important then the decentralization of pools as long as the individual pools do not grow to big, which the miners or the people in control of the hashing power will not allow to happen because of how incentives are aligned and game theory. Miners do not run full nodes the pools do, that is why miners will not be effected by an increase in the block size. Increasing the blocksize does not lead to increased mining centralization. The threat of mining centralization is more related to economies of scale and access to technology, centralization of the manufacturing of ASICS for instance. https://blockchain.info/pools. I do agree with you that conservative is the correct approach here which is why BIP101 might not be the perfect solution, however BIP101 does not follows Moore's law since its starting point is lower then current bandwidth can handle and it is not Exponential since there is an end point. In terms of being conservative however I consider Core with their present one megabyte limit for an unspecified amount of time more radical then BIP101, so I am definitely looking forward to seeing an implementation that strikes more of a middle ground between these two extremes since I would most certainly support that instead once implemented and released.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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

It is true that I am not a developer or an engineer. I would not even consider myself to have a technical background compared to most of the people in the Bitcoin community. I am a miner however, and I have been spending most of my time learning about cryptocurrency over the last year. I have a background in political philosophy and history among other things. Which does allow me to contribute to this discussion is a meaningful way I think. It is important to look at a problem sometimes from different disciplines of thought since they can sometimes give different answers to the same question. I actually do think that you are most likely correct from an engineers perspective, however that from a political philosophy perspective you might not be. I think we should consider many disciplines of thought in this question including engineering and philosophy. Bitcoin itself in its current form and even in its original state represents such a compromise. Since from an engineers perspective the most efficient payment system would be one that is centralized, decentralized systems are less efficient but they are better because of very human reasons. The subjective definition of what is better is a result of our ideology and the priories we apply to this problem. This should be the product of ethics and political philosophy with a grounding in the technical realities in terms of what is possible. I also never said that nothing bad can happen, I do acknowledge that increasing the blocksize should be a balancing act considering many variables.

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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.

I do not think that the scenario that you describe could play because of the explanation I gave before relating to the relationship between the miners and the pools, and the selfish mining attack actually incentivizes the creation of smaller pools. BIP101 is not limitless in terms of the increase of the blocksize, this is just not true. I do not think it would be practical to do hard forks like this on a regular basis in order to perfectly match demand, from an engineering perspective I would agree, however practically in the real world this could cause more problems then it solves. We do differ in opinion on this point.

Quote from: VeritasSapere on October 02, 2015, 01:00:08 AM

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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.

You disagree with me that when time runs out with which I mean blocks become consistently full and transactions become unreliable and more expensive, people will choose the lesser of two evils that solves this problem even if the code is not perfect. Yet then you say this:"The lesser of two evils is the protocol that achieves consensus". You are contradicting yourself, it does matter however since that does mean I agree with you even though you are saying that is not the case and that I misunderstand consensus. The lesser of two evils is the protocol that achieves consensus, I entirely agree. However Bitcoin does not remain if this scenario plays out: https://bitcointalk.org/index.php?topic=946236.0. Bitcoin needs to change in order to stay the same.

Quote from: VeritasSapere on October 02, 2015, 01:00:08 AM

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

I can agree with you that scaling should be a measure 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.

I would actually disagree with increasing the minimum size for a transaction. I do not think we should discriminate between transactions since it is impossible to tell the difference between "spam" and a legitimate transaction like remittance. Also if the price of Bitcoin increases then this minimum transaction size would need to be adjusted again as well, I do not think we should add features that are so dependent upon possibly centralized organizations outside of the protocol needing to constantly make decisions and changes, it should be done algorithmically if at all which in this case I do not believe is possible. If low fee transactions did ever become a problem for the miners they could just choose not to include low or zero fee transactions, they do have that discretionary power after all, I suppose that is an incentive based solution. I do agree with you however that presently it is far to inexpensive to flood the network with transactions thereby in the process hurting Bitcoin, this attack would be become far more expensive however with increased adoption and an increased blocksize however.

Quote from: VeritasSapere on October 02, 2015, 01:27:57 AM

Quote from: poeEDgar on October 02, 2015, 08:14:58 AM

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

Are you saying that BIP101 is buggy? Because as far as I understand this is certainly not the case. Actions do speak louder than words and Core has still not implemented anything yet. How long would you wait for Core before you lost faith? I suspect that another implementation will come along that we will all be able to agree with instead, which is why I keep saying that we are not ideological opponents we do both want to see the blocksize to be increased after all.