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

[kalooki]

It is absolutely unproductive and irresponsible to try to advance decentralization of Bitcoin development by encouraging incapable people to start messing around with their own implementations and risk breaking consensus.

But I think the point here is that many people believe (and interpret the whitepaper as stating) that a plethora of different implementations with regular post-fork swarming to a new consensus is actually the natural state of Bitcoin.

The idea that consensus means pre-fork agreement is wrong (as pre-fork agreement is impossible in a trustless decentralized system).

I believe the recent XT events should be the norm; new implementations being released, and standing or falling on their merits in the community, with regularity.

I think that while a lot of the "team XT" stuff was nonsense and dangerous, I think that the deliberate slowing of the blocksizes by those people with an apparent anti-competitive commercial incentive to do so, is FAR more dangerous and insidious.

If Bitpay came out and said; "we've created BIP111 and are suggesting people who like adoption run it, as we need it to process zero confirmation transactions to reduce fraud and increase adoption, so we can make money and grow" than at least that's honesty. What's going on at Blockstream is much more subtle, and much more disingenuous.

The only way that we can break this cycle of BS is for multiple parties to be developing (as they are) and the community to be accepting and rejecting CODE not PEOPLE.

[marky89]

looks like chinese pools joined team BiP100. at least they're reasonable, a bit surprising. good luck with your XT altcoin Gavin

They are not reasonable, it is an immature power grab that can cripple competition in the mining space.

An immature power grab, really? So mining pools voting in favor of an alternative proposal is a power grab, yet Gavin Anderson and Mike Hearn releasing a hard fork is not? People just sound butt hurt because XT and BIP 101 haven't a chance of moving forward. I don't think BIP 100 is anything to write home about, but at least it ended this nonsense that "supporting XT = supporting bigger blocks."

[VeritasSapere]

looks like chinese pools joined team BiP100. at least they're reasonable, a bit surprising. good luck with your XT altcoin Gavin

They are not reasonable, it is an immature power grab that can cripple competition in the mining space.

An immature power grab, really? So mining pools voting in favor of an alternative proposal is a power grab, yet Gavin Anderson and Mike Hearn releasing a hard fork is not?

I do actually agree with you on this point for a change. That is that neither one of these proposals represents a power grab because it is done through consensus.

But at least it ended this nonsense that "supporting XT = supporting bigger blocks.".

I disagree with this however. Supporting XT does equal supporting bigger blocks.

https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

[Carlton Banks]

But at least it ended this nonsense that "supporting XT = supporting bigger blocks.".

I disagree with this however. Supporting XT does equal supporting bigger blocks.

https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

Check your rhetoric, marky clearly meant "supporting XT != the only way of supporting bigger blocks." By that logic, I support BIP101, which we all know I do not.

[knight22]

looks like chinese pools joined team BiP100. at least they're reasonable, a bit surprising. good luck with your XT altcoin Gavin

They are not reasonable, it is an immature power grab that can cripple competition in the mining space.

An immature power grab, really? So mining pools voting in favor of an alternative proposal is a power grab, yet Gavin Anderson and Mike Hearn releasing a hard fork is not? People just sound butt hurt because XT and BIP 101 haven't a chance of moving forward. I don't think BIP 100 is anything to write home about, but at least it ended this nonsense that "supporting XT = supporting bigger blocks."

It is a power grab in a sense that it gives them the power to reduce the block size by allowing them to collude and removing the need for better bandwidth. It removes a technical aspect where they should compete with each others removing the opportunity for new mining pools to emerge by offering better bandwidth to the network.

[tvbcof]

Gavin and his BIP101 meets the  rest of the devs:

[knight22]

Gavin and his BIP101 meets the  rest of the devs:

[img]-nip-[img]

No substance post have no substance.

[VeritasSapere]

But at least it ended this nonsense that "supporting XT = supporting bigger blocks.".

I disagree with this however. Supporting XT does equal supporting bigger blocks.

https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

Check your rhetoric, marky clearly meant "supporting XT != the only way of supporting bigger blocks." By that logic, I support BIP101, which we all know I do not.

But at least it ended this nonsense that "supporting XT = supporting bigger blocks.".

Maybe I did misunderstand, but the emboldened part of the text is why I thought that is what he meant.

[brg444]

http://bitfury.com/content/5-white-papers-research/1-bitfury-report-on-block-size-increase/bitfury-report-on-block-size-increase.pdf

This is the mark of true industry leaders.

Nothing the clowns at Circle, BitPay, Bitgo, Blockchain.info could hope to deliver.



#REKT

[VeritasSapere]

http://bitfury.com/content/5-white-papers-research/1-bitfury-report-on-block-size-increase/bitfury-report-on-block-size-increase.pdf

This is the mark of true industry leaders.

Nothing the clowns at Circle, BitPay, Bitgo, Blockchain.info could hope to deliver.

I respectfully disagree with the good people at Bitfury. I am surprised to see that they think that it is intrinsically wrong to fork away from the Core developer team. There are very good reasons for why this is not the case, which we have already discussed on this thread. This white paper does not prove anything in terms of this question. Furthermore them just saying this, I do not find convincing, an argument for why this is the case would be better. Or if you really believe this brg444 then why don’t you rebuttal my arguments instead of just posting the opinion of Bitfury. If Core does not implement a block size increase within a reasonable amount of time, I am sure that Bitfury would change their tune on this issue eventually anyway.

[Carlton Banks]

http://bitfury.com/content/5-white-papers-research/1-bitfury-report-on-block-size-increase/bitfury-report-on-block-size-increase.pdf

This is the mark of true industry leaders.

Nothing the clowns at Circle, BitPay, Bitgo, Blockchain.info could hope to deliver.

I respectfully disagree with the good people at Bitfury. I am surprised to see that they think that it is intrinsically wrong to fork away from the Core developer team. There are very good reasons for why this is not the case, which we have already discussed on this thread.

Not what they said. They said it damages confidence, not that it's intrinsically wrong. Those two things are separate concepts, you would do well not to confuse them.

Careful, second time you have misrepresented someone's views that I have noticed, and it's on the same thread (and the same page).

This white paper does not prove anything in terms of this question. Furthermore them just saying this, I do not find convincing, an argument for why this is the case would be better. Or if you really believe this brg444 then why don’t you rebuttal my arguments instead of just posting the opinion of Bitfury. If Core does not implement a block size increase within a reasonable amount of time, I am sure that Bitfury would change their tune on this issue eventually anyway.

From the BitFury report which you claim to have read:

3. Conclusion

In order for the Bitcoin ecosystem to continue developing, the maximum block size needs to be increased.

So, three times in one page, Veritas? Are these all mistakes on your part?

[knight22]

I don't see how on earth BIP100 will reach consensus with the industry as it gives absolutely nothing in terms of predictability which they absolutely need. At this point, a middle ground between BIP100 and BIP101 is the most likely outcome scenario.

[VeritasSapere]

http://bitfury.com/content/5-white-papers-research/1-bitfury-report-on-block-size-increase/bitfury-report-on-block-size-increase.pdf

This is the mark of true industry leaders.

Nothing the clowns at Circle, BitPay, Bitgo, Blockchain.info could hope to deliver.

I respectfully disagree with the good people at Bitfury. I am surprised to see that they think that it is intrinsically wrong to fork away from the Core developer team. There are very good reasons for why this is not the case, which we have already discussed on this thread.

Not what they said. They said it damages confidence, not that it's intrinsically wrong. Those two things are separate concepts, you would do well not to confuse them.

Careful, second time you have misrepresented someone's views that I have noticed, and it's on the same thread (and the same page).

This white paper does not prove anything in terms of this question. Furthermore them just saying this, I do not find convincing, an argument for why this is the case would be better. Or if you really believe this brg444 then why don’t you rebuttal my arguments instead of just posting the opinion of Bitfury. If Core does not implement a block size increase within a reasonable amount of time, I am sure that Bitfury would change their tune on this issue eventually anyway.

From the BitFury report which you claim to have read:

3. Conclusion

In order for the Bitcoin ecosystem to continue developing, the maximum block size needs to be increased.

So, three times in one page, Veritas? Are these all mistakes on your part?

Their arguments are focused on the disadvantages of choosing an alternative client for the implementation of increasing the block size. It is true that they did not say it was intrinsically wrong, you are correct in saying that. However my arguments for why it is not intrinsically wrong can serve as counter arguments to such reasoning.

Also I never said that Bitfury does not want to increase the block size, they clearly do. This is pretty funny actually we are indeed falling into the same pattern of you accusing me of a straw man argument when that is not the case. Though granted they did not say it was intrinsically wrong and you are correct in saying that there is an important distinction there. However the argument for why it is not intrinsically wrong does serve as a counter argument to their position.

[Carlton Banks]

Their arguments are focused on the disadvantages of choosing an alternative client for the implementation of increasing the block size. It is true that they did not say it was intrinsically wrong, you are correct in saying that. However my arguments for why it is not intrinsically wrong can serve as counter arguments to such reasoning.

Also I never said that Bitfury does not want to increase the block size, they clearly do. This is pretty funny actually we are indeed falling into the same pattern of you accusing me of a straw man argument when that is not the case. Though granted they did not say it was intrinsically wrong and you are correct in saying that there is an important distinction there. However the argument for why it is not intrinsically wrong does serve as a counter argument to their position.

Really? An argument against one concept can usefully serve as an argument against a second unrelated concept? I'd like to see you follow your advice to others and flesh this out beyond simply asserting it.


Do you see the gargantuan irony in saying I accused of you of strawmanning, when I actually asked you if you had made repeated mistakes?

[VeritasSapere]

Their arguments are focused on the disadvantages of choosing an alternative client for the implementation of increasing the block size. It is true that they did not say it was intrinsically wrong, you are correct in saying that. However my arguments for why it is not intrinsically wrong can serve as counter arguments to such reasoning.

Also I never said that Bitfury does not want to increase the block size, they clearly do. This is pretty funny actually we are indeed falling into the same pattern of you accusing me of a straw man argument when that is not the case. Though granted they did not say it was intrinsically wrong and you are correct in saying that there is an important distinction there. However the argument for why it is not intrinsically wrong does serve as a counter argument to their position.

Really? An argument against one concept can usefully serve as an argument against a second unrelated concept? I'd like to see you follow your advice to others and flesh this out beyond simply asserting it.


Do you see the gargantuan irony in saying I accused of you of strawmanning, when I actually asked you if you had made repeated mistakes?

In some cases a single argument can be used as an argument for other concepts as well. I can flesh this out quite simply as well:

“Split between client software installed on full nodes could cause a negative impact on Bitcoin's image and decrease trust In the Bitcoin blockchain”
“Transition to Bitcoin XT could cause a fork of the blockchain: there is a concern that small differences between Bitcoin XT and Bitcoin Core could result in Bitcoin XT accepting some transactions that are considered invalid in Bitcoin Core”

Now since it is true that such criticisms would be true for any alternative client implementation, I can argue that:

The ability to hard fork in this way represents the check that we have against such power that a core development team could hold. If you think that we should never hard fork it is the equivalent of saying that the core developers have absolute power over the development of the Bitcoin protocol. This is part of what makes Bitcoin truly so decentralized and free. That is why it is not intrinsically wrong to fork away from the core development team.

Therefore it can be argued that the positives of having alternative clients can outweigh the negative consequences of adopting an alternative client because of these reasons.

You did accuse me of using a straw man argument and you where actually partially correct.

[Carlton Banks]

In some cases a single argument can be used as an argument for other concepts as well. I can flesh this out quite simply as well:

“Split between client software installed on full nodes could cause a negative impact on Bitcoin's image and decrease trust In the Bitcoin blockchain”
“Transition to Bitcoin XT could cause a fork of the blockchain: there is a concern that small differences between Bitcoin XT and Bitcoin Core could result in Bitcoin XT accepting some transactions that are considered invalid in Bitcoin Core”

Now since it is true that such criticisms would be true for any alternative client implementation, I can argue that:

The ability to hard fork in this way represents the check that we have against such power that a core development team could hold. If you think that we should never hard fork it is the equivalent of saying that the core developers have absolute power over the development of the Bitcoin protocol. This is part of what makes Bitcoin truly so decentralized and free. That is why it is not intrinsically wrong to fork away from the core development team.

Therefore it can be argued that the positives of having alternative clients can outweigh the negative consequences of adopting an alternative client because of these reasons.

Now I am going to accuse you of strawmanning, and it's bizarre: you are strawmanning your own statements as opposed to mine. What you present in the above post is not what you tried to assert originally.

In addition, the ability to fork the client can be both used and abused. If a group of developers want to fork the chain because they're unhappy with the direction development is taking, there does not mean that they are unquestionably acting in the interests of the users.

Do you see the gargantuan irony in saying I accused of you of strawmanning, when I actually asked you if you had made repeated mistakes?

You did accuse me of using a straw man argument and you where actually partially correct.

I literally did not, although it's obvious that I suspected it. Again,

Do

You

Not

See

The

Gargantuan

Irony

For

The

Second

Time?

[VeritasSapere]

“Now I am going to accuse you of strawmanning, and it's bizarre: you are strawmanning your own statements as opposed to mine. What you present in the above post is not what you tried to assert originally.” All I tried to assert originally is this:

That this white paper does not prove anything in terms of the question of whether it is intrinsically wrong to fork away from the Core developer team.

And that if Core does take to long to implement a block size increase within a reasonable amount of time, that Bitfury would most likely change their tune on this issue eventually anyway.

These are my originall assertions, I had also implied that Bitfury thinks that it is intrinsically wrong to fork away from the core developer team, which was a straw man argument which you successfully pointed out by saying “Not what they said. They said it damages confidence, not that it's intrinsically wrong.”

You are correct in saying that “What you present in the above post is not what you tried to assert originally.”. This is true but this is only because you asked me to make the argument when you said “I'd like to see you follow your advice to others and flesh this out beyond simply asserting it.”. That is why the argument came later because you asked me to flesh it out so to speak. I do not think it is possible to straw man myself in terms of it being a logical fallacy at least.

This is funny, we are not even talking about the blocksize anymore, this has become pure epistemology, which is good.

[hdbuck]

Bla bla bla ^^

Carlton you the zen master. Dont know how you manage but thx!

[Zarathustra]

“Now I am going to accuse you of strawmanning, and it's bizarre: you are strawmanning your own statements as opposed to mine. What you present in the above post is not what you tried to assert originally.” All I tried to assert originally is this:

That this white paper does not prove anything in terms of the question of whether it is intrinsically wrong to fork away from the Core developer team.

And that if Core does take to long to implement a block size increase within a reasonable amount of time, that Bitfury would most likely change their tune on this issue eventually anyway.

Yes.

"To me, it's only a matter of whether we get a big rise soon-ish because Core implements bigger blocks, or a gigantic rise later-ish because Bitcoin dev becomes decentralized away from Core."

Zangelbert Bingledack, Yesterday at 2:06 AM

http://bitco.in/forum/threads/bitcoin-is-awesome.17/#post-177
 

[brg444]

“Now I am going to accuse you of strawmanning, and it's bizarre: you are strawmanning your own statements as opposed to mine. What you present in the above post is not what you tried to assert originally.” All I tried to assert originally is this:

That this white paper does not prove anything in terms of the question of whether it is intrinsically wrong to fork away from the Core developer team.

And that if Core does take to long to implement a block size increase within a reasonable amount of time, that Bitfury would most likely change their tune on this issue eventually anyway.

Yes.

"To me, it's only a matter of whether we get a big rise soon-ish because Core implements bigger blocks, or a gigantic rise later-ish because Bitcoin dev becomes decentralized away from Core."

Zangelbert Bingledack, Yesterday at 2:06 AM

http://bitco.in/forum/threads/bitcoin-is-awesome.17/#post-177
 

Keep that bs over there. The concern trolling about Bitcoin development is nothing but XT fans looking for another fight to lose.