Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)

[VeritasSapere]

I do not trust them to increase the block size, that is why it should be implemented by an alternative client. Unless the Core devs increase the blocksize, I will not trust them to do it.

I don't trust Gavin/Hearn to implement anything, since the basis for scaling in BIP101 is Moore's Law (unproven, unscientific, failing) and nothing more than the baseless assumption that we can address issues of scaling on an exponentially increasing schedule. Literally, the only answer provided to questions of delayed block propagation times is that "technology gets better over time." Never mind the basic premise in large scale systems that conditions in small scale =/= conditions in large scale, and how this basic oversight could force us to fork the limit down after a serious security lapse. One cannot test a regime in a .4MB block environment and simply assume that it is stable in an 8GB block environment.

We are simply supposed to believe that "technology gets better over time, therefore exponentially increasing block size limit presents no threats to bitcoin."

Pfff.....

If you believe a block size limit increase is necessary, it doesn't logically follow that you should accept the first reckless proposal that comes along.

You do not need to trust Gavin and Hearn, they have already released the code and everyone can see for themselves what is in there and what the schedule for the increase will be. The Core team however will not even give us a definitive time line for when they plan to increase the block size, so trusting that Core will increase the block size is just that, trust.

I do believe that a block size increase is necessary, therefore it does logically follow that I should support the first proposition to do so. I am not an unreasonable person, as soon as a third alternative presents itself I will most likely adopt that instead. I just do not want to entrust these or any other developers with the future of Bitcoin. Right now we only have two choices, and even if it is a choice between the lesser of two evils, we do still have to choose.

[poeEDgar]

I do not trust them to increase the block size, that is why it should be implemented by an alternative client. Unless the Core devs increase the blocksize, I will not trust them to do it.

I don't trust Gavin/Hearn to implement anything, since the basis for scaling in BIP101 is Moore's Law (unproven, unscientific, failing) and nothing more than the baseless assumption that we can address issues of scaling on an exponentially increasing schedule. Literally, the only answer provided to questions of delayed block propagation times is that "technology gets better over time." Never mind the basic premise in large scale systems that conditions in small scale =/= conditions in large scale, and how this basic oversight could force us to fork the limit down after a serious security lapse. One cannot test a regime in a .4MB block environment and simply assume that it is stable in an 8GB block environment.

We are simply supposed to believe that "technology gets better over time, therefore exponentially increasing block size limit presents no threats to bitcoin."

Pfff.....

If you believe a block size limit increase is necessary, it doesn't logically follow that you should accept the first reckless proposal that comes along.

You do not need to trust Gavin and Hearn, they have already released the code and everyone can see for themselves what is in there and what the schedule for the increase will be.

I've stated pretty clearly why no one should run that code. It's reckless and completely lacks technical forethought. And neither Gavin nor Hearn will address legitimate criticism from the community nor update their code to reflect it.

The Core team however will not even give us a definitive time line for when they plan to increase the block size, so trusting that Core will increase the block size is just that, trust.

This has nothing to do with whether bitcoin is trustless. It's just a red herring. This is a controversial issue and I see no problem with Core devs refusing to throw their weight behind Team BIP100, Team BIP102 or Team BIP103. The emphasis should be on finding a robust solution that can achieve consensus, not panicking on the basis of unwarranted urgency and implementing a "fix" that could end up crushing confidence in bitcoin.

I do believe that a block size increase is necessary, therefore it does logically follow that I should support the first proposition to do so.

In the absence of an acceptable solution, the status quo is the only acceptable solution. That doesn't mean the debate is over, but that it is irresponsible to back code that is a) severely untested, b) necessarily completely untested in environments that are remotely similar to those that are hard-coded (conceivably, we can test a 2MB block regime in a .5MB environment -- can we test an 8GB block regime in a .5MB environment? no, that's insulting), c) peer reviewed by one person, d) lacking in technical explanation for the basis for its scaling schedule (why Moore's Law?) or how we can assume that all forms of technological throughput will improve at the rate of (or faster than) the exponential scaling schedule in BIP101, e) the list goes on but I don't have time for this.

Right now we only have two choices, and even if it is a choice between the lesser of two evils, we do still have to choose.

No, we don't.

[VeritasSapere]

I've stated pretty clearly why no one should run that code. It's reckless and completely lacks technical forethought. And neither Gavin nor Hearn will address legitimate criticism from the community nor update their code to reflect it.

I do not see what is so reckless about running Core with a BIP101 patch, since that is all that it is. BIP101 being a proposal with the Core client after all. Unless you are refering to the scedule of the blocksize increase which is a fair critisism. I would adopt a middle ground between these extremes as soon as it becomes real, even if it is because Core capitulates and increases the block size. https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

The Core team however will not even give us a definitive time line for when they plan to increase the block size, so trusting that Core will increase the block size is just that, trust.

This has nothing to do with whether bitcoin is trustless. It's just a red herring. This is a controversial issue and I see no problem with Core devs refusing to throw their weight behind Team BIP100, Team BIP102 or Team BIP103. The emphasis should be on finding a robust solution that can achieve consensus, not panicking on the basis of unwarranted urgency and implementing a "fix" that could end up crushing confidence in bitcoin.

I never said that this had anything to do with the trustless aspect of Bitcoin and it is therefore not a red herring. Choosing an alternative client should be a way for people to express this consensus and how ultimately consensus should be reached as well. The consensus of the Bitcoin network should not be synonymous with the consensus of the Core development team.

I do think that some urgency is warranted, since if there is a significant global event it could possibly lead to a spike in adoption, then the network would become overloaded. the consequences of this would seriously hamper adoption and public perception. It would also not be good to do a hard fork at short notice when this does become a problem since that would lead to a situation that would be much more chaotic and confusing, and might indeed "crush" confidence in Bitcoin for many people.

I do believe that a block size increase is necessary, therefore it does logically follow that I should support the first proposition to do so.

In the absence of an acceptable solution, the status quo is the only acceptable solution. That doesn't mean the debate is over, but that it is irresponsible to back code that is a) severely untested, b) necessarily completely untested in environments that are remotely similar to those that are hard-coded (conceivably, we can test a 2MB block regime in a .5MB environment -- can we test an 8GB block regime in a .5MB environment? no, that's insulting), c) peer reviewed by one person, d) lacking in technical explanation for the basis for its scaling schedule (why Moore's Law?) or how we can assume that all forms of technological throughput will improve at the rate of (or faster than) the exponential scaling schedule in BIP101, e) the list goes on but I don't have time for this.

I do not think the debate is over. I am looking at this from a realist political perspective. We have a choice, you can vote for an increased blocksize or you can vote to keep it the same. I think that keeping one megabyte blocks forever would be very bad for Bitcoin from my ideological perspective, I am not saying that this is the position of the Core development team, irregardless however they do not have a plan in place to increase the block size now. So being forced between these two extreme choices I choose BIP101, but I appreciate that I do have the choice, the very existence of BIP101 is acting as a catalyst for change as well, and like I said I would adopt a proposal that would represent the middle ground between these two extremes as soon as it becomes reality.

I also believe that when you look at this problem from a philosophical political perspective you can get a different answer compared to looking at this from a purely technical point of view, and in my opinion the technical ideal needs to be compromised for political goals. It might be true like you say, that some of these things can not be tested. This is true, but because they are unprecedented in history, that is why it is inconceivable to attempt to factor in all of the variables into mathematical models. It would make more sense to stay true to the philosophical principles that make Bitcoin what it is while keeping a grounding in the technical realities to help guide us through its evolution.

Right now we only have two choices, and even if it is a choice between the lesser of two evils, we do still have to choose.

No, we don't.

As a miner and a full node operator I do have to choose, you literally can not do these things without casting a vote to either side, therefore it is impossible to be neutral under these circumstances.

[poeEDgar]

VeritasSapere, my problem with your entire approach is that you are trying to make a political debate from a technical one. That others are making it political (e.g. one vision of bitcoin vs. another) does not change the fact that one of those visions is technically unacceptable for many, many reasons, as stated above.

....And why does the existence of XT make Core one of two evils?

[VeritasSapere]

VeritasSapere, my problem with your entire approach is that you are trying to make a political debate from a technical one. That others are making it political (e.g. one vision of bitcoin vs. another) does not change the fact that one of those visions is technically unacceptable for many, many reasons, as stated above.

....And why does the existence of XT make Core one of two evils?

I do think that this is a fundamentally political debate. The reason why I consider Core to be the greater of the two evils is because keeping the block size at one megabyte would be devastating from my ideological perspective at least. I also do not want to just "trust" the Core devs to increase the block size, in the same way that we should also not trust politicians. I trust in the economic majority more then I do a small group of technical experts, and when the technical experts are telling us contradictory things, then we must decide for ourselves which path we should take. I do not think that the the Core team should be the "authority" on Bitcoin. Which is why in part I support any alternative implementation that seeks to compete with Core. Since centralization of development should also be considered as a danger that we must guard against. It seems like the majority does want the blocksize to be increased, therefore Core should at least make a statement that they do plan to increase the block size, because they have not done so it makes sense for me to support alternative clients outside of Core that reflect my own beliefs more accurately.

This explains well why not increasing the blocksize concerns me:
https://bitcointalk.org/index.php?topic=946236.0

This is a good talk about the politics of bitcoin:
https://www.youtube.com/watch?v=YaaknMDbQGc

[poeEDgar]

That's all well and good. But again, regardless of your ideological position, you (nor anyone else) has provided adequate answers to the many, many technical criticisms of BIP101. As someone who is significantly invested in bitcoin, supporting a technically unsound solution is completely unacceptable to me. You can make your ideological opinion known, but this still leaves us at square one.

No matter what vision you have for bitcoin, ideologically, bitcoin will be broken if network security is of no concern.

[VeritasSapere]

That's all well and good. But again, regardless of your ideological position, you (nor anyone else) has provided adequate answers to the many, many technical criticisms of BIP101. As someone who is significantly invested in bitcoin, supporting a technically unsound solution is completely unacceptable to me. You can make your ideological opinion known, but this still leaves us at square one.

No matter what vision you have for bitcoin, ideologically, bitcoin will be broken if network security is of no concern.

I do not necessarily think that BIP101 would compromise network security. However since we are both reasonable people I do think that there will be a third alternative that we will both be able to agree with in the near future.

You could even send me some links in a PM if you would like, I am genuinely interested in learning about your concerns about BIP101 security. Since I am researching this subject in depth, I do appreciate such criticisms.

[johnyj]

You can not simulate or test the social and economy impact of 8MB blocks in the test net, that's the key difficulty

No one can see the future of a complex decentralized social and economy system, the safest way is to make the change as small as possible, one small step at a time

[VeritasSapere]

You can not simulate or test the social and economy impact of 8MB blocks in the test net, that's the key difficulty

No one can see the future of a complex decentralized social and economy system, the safest way is to make the change as small as possible, one small step at a time

I do like that idea, however that means we would have to hard fork on a regular basis. I do not think that this is practical or even possible without splitting Bitcoin, especially as more people become involved, it will become even more difficult to reach consensus. It would be better if we do not have to debate this again in a few years from now.

This is a great example of something that makes perfect sense technically, which however might not be as practical or feasible from a political perspective.

[mookid]

I think it's very important for the community to know the things that are going on right now. Some devs are kinda opaque about this discussion, Mike Hearn stated that he has tried to contact some core developers and has not received answers. How can we build a meaningful discussion and consensus about the issues that bitcoin faces if devs are still waiting for some miraculous voting system to appear from nothing?

[tvbcof]

I think it's very important for the community to know the things that are going on right now. Some devs are kinda opaque about this discussion, Mike Hearn stated that he has tried to contact some core developers and has not received answers. How can we build a meaningful discussion and consensus about the issues that bitcoin faces if devs are still waiting for some miraculous voting system to appear from nothing?

That what happens when you become a pariah.  Mike and Gavin need to suck it up.  They made their bed and now they get to sleep in it.

[poeEDgar]

You can not simulate or test the social and economy impact of 8MB blocks in the test net, that's the key difficulty

No one can see the future of a complex decentralized social and economy system, the safest way is to make the change as small as possible, one small step at a time

Exactly. My thinking is that allowing for exponential scaling in this fashion is basically turning the blockchain into a testnet for the next two decades. There is too much money at stake to naively assume that nothing will ever go [very, very] wrong on the path to scaling 8000x in block size limit when we have never scaled past 1x.

An incremental approach is the only responsible approach. As I said above, we can probably safely run a 2MB block regime coming from a .5MB environment -- but an 8GB block regime from a .5MB environment? That's simply irresponsible. Everything that can go wrong will go wrong.

I do like that idea, however that means we would have to hard fork on a regular basis. I do not think that this is practical or even possible without splitting Bitcoin, especially as more people become involved, it will become even more difficult to reach consensus. It would be better if we do not have to debate this again in a few years from now.

I keep hearing this. People need to get over the fact that bitcoin is, and has always been, a work in progress. This is absolutely not the last contentious debate the community will have (likely this will pale in comparison to future issues). And it is very, very silly to have the mindset that "this is the fork to end all forks." Irrational fear of controversy, and of the idea of hard forking in the future (i.e. making decisions) is not an adequate reason to push a reckless regime of exponential scaling.

[S4VV4S]

You can not simulate or test the social and economy impact of 8MB blocks in the test net, that's the key difficulty

No one can see the future of a complex decentralized social and economy system, the safest way is to make the change as small as possible, one small step at a time

I do like that idea, however that means we would have to hard fork on a regular basis. I do not think that this is practical or even possible without splitting Bitcoin, especially as more people become involved, it will become even more difficult to reach consensus. It would be better if we do not have to debate this again in a few years from now.

This is a great example of something that makes perfect sense technically, which however might not be as practical or feasible from a political perspective.

Not necessarily.
If consensus is reached, a time/size limit can be imposed for every 2 years let's say then the blocksize can be increased gradually.

[uxgpf]

Irrational fear of controversy, and of the idea of hard forking in the future (i.e. making decisions) is not an adequate reason to push a reckless regime of exponential scaling.

Have you considered that it's technically much better to have generous limits which you can reduce via soft forks if needed, than having the limit set too low and then be forced to do another hard fork to raise it.

Also we've already had 32 MB limit in Bitcoin's history and it created no problems. And the fact that Satoshi's idea was to remove blocksize limit entirely when light clients became available.

The eventual solution will be to not care how big it gets.

[DarkHyudrA]

Irrational fear of controversy, and of the idea of hard forking in the future (i.e. making decisions) is not an adequate reason to push a reckless regime of exponential scaling.

Have you considered that it's technically much better to have generous limits which you can reduce via soft forks if needed, than having the limit set too low and then be forced to do another hard fork to raise it.

Also we've already had 32 MB limit in Bitcoin's history and it created no problems. And the fact that Satoshi's idea was to remove blocksize limit entirely when light clients became available.

So you want to increase to reduce later?
Very clever indeed.

[uxgpf]

So you want to increase to reduce later?
Very clever indeed.

Yes, reduce if necessary.
What's the problem with this?

If technology and adoption won't grow at rates projected, and if all that slack would cause some issues, it would be easy to adjust the future limits downward.

[brg444]

I will believe it when the block size will be increased. Not before. I have absolutely no reasons to trust them.

Believe what? Their code is already out in the open. Are you even aware that the last functioning proposal for a Lightning network implementation was created by someone outside of Blockstream? No one's asking you to trust them.

I do not trust them to increase the block size, that is why it should be implemented by an alternative client. Unless the Core devs increase the blocksize, I will not trust them to do it. Especially since this has become a fundamental ideological disagreement, since not increasing the block size at all would lead to a very different future for Bitcoin compared to the future that restricting the block size would lead to.

Blockstream does not decide if changes are made to the Bitcoin core, the community of devs does.

[uxgpf]

Blockstream does not decide if changes are made to the Bitcoin core, the community of devs does.

Yes, the blockstream controversy is likely just another conspiracy theory. Along the lines of Gavin being a CIA mole, etc. I think it's just that the "community of devs" often disagree and Wladimir doesn't want to dictate the direction.

[brg444]

Blockstream does not decide if changes are made to the Bitcoin core, the community of devs does.

Yes, the blockstream controversy is likely just another conspiracy theory. Along the lines of Gavin being a CIA mole, etc. I think it's just that the "community of devs" often disagree and Wladimir doesn't want to dictate the direction.

tbh there's more credibility to the "conspiracy"  that Gavin has been compromised by corporate interests than anything related to Blockstream 

[DarkHyudrA]

So you want to increase to reduce later?
Very clever indeed.

Yes, reduce if necessary.
What's the problem with this?

If technology and adoption won't grow at rates projected, and if all that slack would cause some issues, it would be easy to adjust the future limits downward.

But there's no projection. It simply keeps doubling and the network don't grow at that rate.
Unless everybody will have Google Fiber 24/7 in a few years and there a mass adption like a big bank acceptin Bitcoin and promoting it, and that will not happen.