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

[erik777]

The decision making processes should be based on where the miners point their hashing power and what code people choose to run. This is the level at which consensus should be achieved. To think that important decisions should be made by a Core development team is tantamount to centralization of power.

There is a very big difference between being a benevolent dictator of your own implementation of Bitcoin and actually being the dictator of Bitcoin. This is a very important distinction. It is not wrong to be in charge of your own implementation of Bitcoin when people are free to choice whatever client they want. Having multiple implementations of Bitcoin is good for decentralization and freedom.

Agreed.  One group of developers should not be considered a permanent authority on what Bitcoin is or should be.  I don't see how anyone could possibly be advocating for such a thing, but sadly it seems increasingly common at the moment.  Disparate factions are emerging here and no one is any closer to agreeing on anything.  If anything, the gap appears to be widening.  We're not working towards a solution, we're working towards a split.  I honestly don't see this ending amicably.  


Points to remember:

• If you want to use an open source coin, that means anyone can modify that code and submit their own version under another name.
• Such actions are not an attack on the system and actually prevent the possibility of a single group having permanent control over development.
• Successfully forking with an alternative client does not give those developers any special power or diktat to enforce future changes on the network.
• Assuming that Core developers are the only permanent authority on what Bitcoin "is" or "should be" is an extremely dangerous mindset.
• Consensus is not a group of developers agreeing, because the people securing the network make the decisions, not the developers.

Oxymorons to avoid:

• "Bitcoin is great because it's decentralised, but only the core devs can be trusted to write code"
• "Bitcoin is great because it's open source, but releasing a client to propose a fork means you're a dictator"
• "Bitcoin is great because it's permissionless, but you can't use it to buy a cup of coffee"
• "Bitcoin is great because only the economic majority can decide the rules of the network, but only when I personally agree with them, otherwise I'll dismiss it as an altcoin like a petulant child"

nice summary - concise, rational, accurate

Really?  The problem is overgeneralising on abstracts, instead of the realistic truth that Hearn has for years proposed ideas that are a risk to Bitcoin.  What pro-XT posters have proven is how easy it is for people to believe in a person and his fork who is so potentially destructive to Bitcoin. 

The problem with idealism in abstracts is it doesn't predict tyrants.  I'd bet if XT garnered 75% of nodes, you'd see the one of two possible scenarios:

Scenario #1

1> Bitcoin becomes centralized (the protocol) via trusted nodes.
2> Bitcoin uses checkpoints to prevent another hostile takeover like its own.
3> Bitcoin replaces anonymity with identity requirements (passports).
4> Bitcoin loses fungibility in favor of tainted coins, red lists, black lists, and white lists. 
5> Due to #1-4, it would be hard to use any other implementation.

Scenario #2

Bitcoin self-destructs in the process of scenario #1 being rejected by the masses.

The "benevolent dictator" will become a billionaire in scenario #1.  He has so much to gain in scenario #1, scenario #2 is worth the risk to him.

[VeritasSapere]

Really?  The problem is overgeneralising on abstracts, instead of the realistic truth that Hearn has for years proposed ideas that are a risk to Bitcoin.  What pro-XT posters have proven is how easy it is for people to believe in a person and his fork who is so potentially destructive to Bitcoin.  

The problem with idealism in abstracts is it doesn't predict tyrants.  I'd bet if XT garnered 75% of nodes, you'd see the one of two possible scenarios:

Scenario #1

1> Bitcoin becomes centralized (the protocol) via trusted nodes.
2> Bitcoin uses checkpoints to prevent another hostile takeover like its own.
3> Bitcoin replaces anonymity with identity requirements (passports).
4> Bitcoin loses fungibility in favor of tainted coins, red lists, black lists, and white lists.  
5> Due to #1-4, it would be hard to use any other implementation.

Scenario #2

Bitcoin self-destructs in the process of scenario #1 being rejected by the masses.

The "benevolent dictator" will become a billionaire in scenario #1.  He has so much to gain in scenario #1, scenario #2 is worth the risk to him.

There is nothing backing up what you are saying here, this is just conjecture.

[VeritasSapere]

The only revisionism going on there is pretending that XT was never a deadly serious (ie overambitious) attempt at an actual governance coup, which was willing to risk catastrophic consensus failure in order to achieve narrow process and technical changes of strictly limited value.

You are, by retroactively reframing XT as merely some kind of magical motivational poster, desperately trying to avoid the stinging cognitive dissonance of its inglorious defeat.

Team Gavin said things and acted as if XT would destroy Core with a bang, but what happened is XT died with only the faintest of whimpers.

And so, having crushed the enemies of Core, we now enjoy the lamentations of their women.  

Just because you keep repeating this, it does not make it true. I have refuted many times now why XT is not the equivalent of a government coup, unless a government coup can be defined as needing 75% consensus.

"Government" and "governance" do look really similar written down, but it's funny how the meaning changes so much when you substitute one for the other  

Troll harder VertiasSapere, you're too consistently getting information wrong that construes the argument in dismissal of an invisible enemy: people who don't want scaling up. It's so openly transparent now that it's totally pathetic

Its a typo, seriously?

two identical typos in the same sentence, seriously?    

You are correct, I did make a spelling mistake.

[DooMAD]

The decision making processes should be based on where the miners point their hashing power and what code people choose to run. This is the level at which consensus should be achieved. To think that important decisions should be made by a Core development team is tantamount to centralization of power.

There is a very big difference between being a benevolent dictator of your own implementation of Bitcoin and actually being the dictator of Bitcoin. This is a very important distinction. It is not wrong to be in charge of your own implementation of Bitcoin when people are free to choice whatever client they want. Having multiple implementations of Bitcoin is good for decentralization and freedom.

Agreed.  One group of developers should not be considered a permanent authority on what Bitcoin is or should be.  I don't see how anyone could possibly be advocating for such a thing, but sadly it seems increasingly common at the moment.  Disparate factions are emerging here and no one is any closer to agreeing on anything.  If anything, the gap appears to be widening.  We're not working towards a solution, we're working towards a split.  I honestly don't see this ending amicably.  


Points to remember:

• If you want to use an open source coin, that means anyone can modify that code and submit their own version under another name.
• Such actions are not an attack on the system and actually prevent the possibility of a single group having permanent control over development.
• Successfully forking with an alternative client does not give those developers any special power or diktat to enforce future changes on the network.
• Assuming that Core developers are the only permanent authority on what Bitcoin "is" or "should be" is an extremely dangerous mindset.
• Consensus is not a group of developers agreeing, because the people securing the network make the decisions, not the developers.

Oxymorons to avoid:

• "Bitcoin is great because it's decentralised, but only the core devs can be trusted to write code"
• "Bitcoin is great because it's open source, but releasing a client to propose a fork means you're a dictator"
• "Bitcoin is great because it's permissionless, but you can't use it to buy a cup of coffee"
• "Bitcoin is great because only the economic majority can decide the rules of the network, but only when I personally agree with them, otherwise I'll dismiss it as an altcoin like a petulant child"

XT was rejected. Get over it, we'll be scaling up without BIP101 or XT. Go away.

There's nothing to "get over".  The points I've outlined above apply in all instances.  They aren't specific to XT.  Stop trying to portray every single comment on the forum as "XT vs Core" and making out like anyone who thinks we need a larger blocksize is some sort of XT fanatic who wants 800GB blocks tomorrow.  We're not all extremists.  Calm the shit down already.

My preference is leaning more towards a dynamic limit:

Anyway, since some are determined to deflect away from technical proposals and throw silly memes around, we'll drag the topic back to one of merit.

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.  One possible route is to take the best elements of BIP100 and BIP106.  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

Code:

Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to: 
    raise blocksize limit by 12.5%, 
    lower blocksize limit by 12.5%, 
    or remain at current blocksize limit.  

This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:

If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize +12.5% 

Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize -12.5%

Else
    Network votes for keeping the same MaxBlockSize

The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105).  If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks.  Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.

Is that not reasonable?

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  If you had simply argued to curtail it to a more reserved increase, without all the doubling and such, it really wouldn't have been the massive drama you've helped turn it into.  But it doesn't matter, what's done is done.  Now we need to move on.  The manner in which we move on is the more important issue, though.  There are people on this forum who are capable of providing constructive criticism and speaking reasonably, discussing amendments to proposals to try and find an optimal solution.  There are others on this forum who simply attack, dismiss, mock and spread misinformation because they can't accept that people see blocksize as an issue.  Please strive to be one of the former, we have more than enough of the latter at the moment.  We really don't need any more.  I'm sure whatever happens, the usual suspects will still be throwing their silly "#rekt" memes around and mocking every single discussion because they have nothing of value whatsoever to contribute, but the rest of us will carry on with more reasoned debate.

[sAt0sHiFanClub]

This thread has gone full retard. Constructive discussion has grinded to a halt. You guys are all like one another, Special Olympics.

I think if you read the thread title, the OP was setting the retard bar pretty low from the off.

Anyone who tries to argue logically with that mentality is the one who is retarded. 

This thread was intended as a trollfest - dont spoil it for everyone.

[RoadTrain]

This thread has gone full retard. Constructive discussion has grinded to a halt. You guys are all like one another, Special Olympics.

I think if you read the thread title, the OP was setting the retard bar pretty low from the off.

Anyone who tries to argue logically with that mentality is the one who is retarded. 

This thread was intended as a trollfest - dont spoil it for everyone.

Don't pretend you're any better, though. This thread does contain a fair amount of discussion, in addition to trolling.

[sAt0sHiFanClub]

This thread has gone full retard. Constructive discussion has grinded to a halt. You guys are all like one another, Special Olympics.

I think if you read the thread title, the OP was setting the retard bar pretty low from the off.

Anyone who tries to argue logically with that mentality is the one who is retarded. 

This thread was intended as a trollfest - dont spoil it for everyone.

Don't pretend you're any better, though. This thread does contain a fair amount of discussion, in addition to trolling.

I dont pretend anything. Make a decent point and I will try and respond in kind. Troll, and I will troll you back.

[jonald_fyookball]

This thread has gone full retard. Constructive discussion has grinded to a halt. You guys are all like one another, Special Olympics.

I think if you read the thread title, the OP was setting the retard bar pretty low from the off.

Anyone who tries to argue logically with that mentality is the one who is retarded. 

This thread was intended as a trollfest - dont spoil it for everyone.

Don't pretend you're any better, though. This thread does contain a fair amount of discussion, in addition to trolling.

I dont pretend anything. Make a decent point and I will try and respond in kind. Troll, and I will troll you back.

exactly.  I've argued sensibly dozens of pages ago.  at this point it's time to expose the extremists for the faggots they really insist on being.

[brg444]

This thread has gone full retard. Constructive discussion has grinded to a halt. You guys are all like one another, Special Olympics.

I think if you read the thread title, the OP was setting the retard bar pretty low from the off.

Anyone who tries to argue logically with that mentality is the one who is retarded.  

This thread was intended as a trollfest - dont spoil it for everyone.

Don't pretend you're any better, though. This thread does contain a fair amount of discussion, in addition to trolling.

I dont pretend anything. Make a decent point and I will try and respond in kind. Troll, and I will troll you back.

exactly.  I've argued sensibly dozens of pages ago.  at this point it's time to expose the extremists for the faggots they really insist on being.

 

LambChop can at least pretend to some intelligence. You're just a noob and have been exposed as so on several occasions

[jonald_fyookball]

whatever you say.

I've made points that no one refuted here.
https://bitcointalk.org/index.php?topic=1162684.msg12357822#msg12357822
https://bitcointalk.org/index.php?topic=1162684.msg12361309#msg12361309
https://bitcointalk.org/index.php?topic=1162684.msg12362678#msg12362678

I've also actually written Bitcoin related code.  

none of your rhetoric impresses me.  you might want to improve it:

http://freedomfeens.com/bs/

[Carlton Banks]

Oxymorons to avoid:

• "Bitcoin is great because it's decentralised, but only the core devs can be trusted to write code"
• "Bitcoin is great because it's open source, but releasing a client to propose a fork means you're a dictator"
• "Bitcoin is great because it's permissionless, but you can't use it to buy a cup of coffee"
• "Bitcoin is great because only the economic majority can decide the rules of the network, but only when I personally agree with them, otherwise I'll dismiss it as an altcoin like a petulant child"

XT was rejected. Get over it, we'll be scaling up without BIP101 or XT. Go away.

There's nothing to "get over".  The points I've outlined above apply in all instances.  They aren't specific to XT.  Stop trying to portray every single comment on the forum as "XT vs Core" and making out like anyone who thinks we need a larger blocksize is some sort of XT fanatic who wants 800GB blocks tomorrow.  We're not all extremists.  Calm the shit down already.

Nonsense. The points above are themselves intended as a sleight against those that defended the present Core devs and their direction (and indecision), and in a addition you're using exactly the same strategy that:

a) You're accusing me of
b) That every single BIP101 shill (there must be dozens now) has employed since the start of this garbage

Exaggerating or caracicaturing the position of those who defended Core wildly. No one has been arguing for points 1, 2, or 3, and so none of them apply. Point 4 never happened; it's a fantasy.

In reality, the economic majority, as well as as every other part of the ecosystem apart from a handful of corporate funded bitcoin businesses, rejected your fantasy version of the "economic majority can decide the rules of the network" (because they were the actual economic majority) that "dismiss it as an altcoin like a petulant child". That's the extremity. That's the same BS distortion that actual unlimited blocksize fanatics have been exhibiting.

My preference is leaning more towards a dynamic limit:

Anyway, since some are determined to deflect away from technical proposals and throw silly memes around, we'll drag the topic back to one of merit.

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.  One possible route is to take the best elements of BIP100 and BIP106.  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

Code:

Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to: 
    raise blocksize limit by 12.5%, 
    lower blocksize limit by 12.5%, 
    or remain at current blocksize limit.  

This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:

If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize +12.5% 

Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize -12.5%

Else
    Network votes for keeping the same MaxBlockSize

The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105).  If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks.  Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.

Is that not reasonable?

No time to read it now, but yeah, welcome to 1 month ago with your "My preference is leaning more towards a dynamic limit"  

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  

Again (actual real life head shake), who's the extremist?

Never said it, or anything like it. Total exaggeration of my actual position.

[jonald_fyookball]

Not sure what forum you're looking at Carlton.

People absolutely have been arguing those "oxymoron" points. 
Obviously not stated in such stark contradictory sentences,
but the implications are there.

 

[DooMAD]

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  

Again (actual real life head shake), who's the extremist?

Never said it, or anything like it. Total exaggeration of my actual position.

Fine, I'm embellishing, but your position was still that you disagree with it, ergo it cannot be.  With a few tweaks and a less aggressive increase, this discussion could have been resolved by now.

No time to read it now, but yeah, welcome to 1 month ago with your "My preference is leaning more towards a dynamic limit"  

If you think I've only caught on to the idea of a dynamic blocksize just now, then apparently you're still too busy blindly labeling me a militant XT supporter to recognise that people aren't just looking at one possible solution.  

Hell, if you were really paying close attention, you might notice I made the post immediately after your post in upal's thread (pre-BIP-number-allocation at the time).  Cheers for the slightly late welcome anyway, though, you sarcastic prick.  

So if we're quite finished exchanging pleasantries, let's move on.  You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

[Carlton Banks]

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  

Again (actual real life head shake), who's the extremist?

Never said it, or anything like it. Total exaggeration of my actual position.

Fine, I'm embellishing, but your position was still that you disagree with it, ergo it cannot be.  With a few tweaks and a less aggressive increase, this discussion could have been resolved by now.

So.... you completely invented my position for your own purposes, and somehow your point still stands? What?

So if we're quite finished exchanging pleasantries, let's move on.  You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

Find someone willing to code it (you won't)

[brg444]

It should be clear by now that even considering some kind of flexible cap scheme is implemented, it will also come with a solid hard cap it cannot surpass before a certain length of time.

[Carlton Banks]

It should be clear by now that even considering some kind of flexible cap scheme is implemented, it will also come with a solid hard cap it cannot surpass before a certain length of time.

That's an interesting line of reasoning, what's the basis for it? Do you mean "hard cap for a given level of infrastructural capabilities" or an actual, "absolute-for-all-time" hard cap? Shouldn't the maximum limit be a function of the demands on the network for space in blocks?

[brg444]

It should be clear by now that even considering some kind of flexible cap scheme is implemented, it will also come with a solid hard cap it cannot surpass before a certain length of time.

That's an interesting line of reasoning, what's the basis for it? Do you mean "hard cap for a given level of infrastructural capabilities" or an actual, "absolute-for-all-time" hard cap? Shouldn't the maximum limit be a function of the demands on the network for space in blocks?

Absolutely not.

Unless I misunderstand this would effectively amount to leaving the transactional capacity up to "the free market" while ignoring the externalization of cost to the node.

The maximum limit should be a function of "the cost of the option to create a full node" : http://www.truthcoin.info/blog/measuring-decentralization/

[DooMAD]

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  

Again (actual real life head shake), who's the extremist?

Never said it, or anything like it. Total exaggeration of my actual position.

Fine, I'm embellishing, but your position was still that you disagree with it, ergo it cannot be.  With a few tweaks and a less aggressive increase, this discussion could have been resolved by now.

So.... you completely invented my position for your own purposes, and somehow your point still stands? What?

Thought it was clear.  Rather than working with the community to try to improve the proposal, you joined in with the group hellbent on burying it.  Not constructive.

So if we're quite finished exchanging pleasantries, let's move on.  You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

Find someone willing to code it (you won't)

Also not what I'd call constructive.  Maybe some actual feedback would get us somewhere?  Which parts need work?  What potential pitfalls might arise?  You know, something helpful maybe.  Genuine discussion about the pros and cons.

Or should I read your reply as "it's so perfect that I want to see it implemented right away"?    

Yeah, okay, I'm guessing it's not that.

Fact is, I'm not a coder or an engineer, so it seems prudent for me to make sure it's at least theoretically sound before I try to get it built. 

[brg444]

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  

Again (actual real life head shake), who's the extremist?

Never said it, or anything like it. Total exaggeration of my actual position.

Fine, I'm embellishing, but your position was still that you disagree with it, ergo it cannot be.  With a few tweaks and a less aggressive increase, this discussion could have been resolved by now.

So.... you completely invented my position for your own purposes, and somehow your point still stands? What?

Thought it was clear.  Rather than working with the community to try to improve the proposal, you joined in with the group hellbent on burying it.  Not constructive.

So if we're quite finished exchanging pleasantries, let's move on.  You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

Find someone willing to code it (you won't)

Also not what I'd call constructive.  Maybe some actual feedback would get us somewhere?  Which parts need work?  What potential pitfalls might arise?  You know, something helpful maybe.  Genuine discussion about the pros and cons.

Or should I read your reply as "it's so perfect that I want to see it implemented right away"?    

Yeah, okay, I'm guessing it's not that.

Fact is, I'm not a coder or an engineer, so it seems prudent for me to make sure it's at least theoretically sound before I try to get it built.  

Here is my constructive comment: unless a hard cap limiting the increase over a certain period of time is coupled to this proposal, any such scheme is utterly broken and can be trivially gamed by miners intent on controlling the blocksize.

Any such proposition is not viable given that it provides no consideration for the externalization of the cost to the nodes and our focus on keeping Bitcoin decentralized.

[DooMAD]

Here is my constructive comment: unless a hard cap limiting the increase over a certain period of time is coupled to this proposal, any such scheme is utterly broken and can be trivially gamed by miners intent on controlling the blocksize.

Any such proposition is not viable given that it provides no consideration for the externalization of the cost to the nodes and our focus on keeping Bitcoin decentralized.

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  I've even stated that the 12.5% part is open to negotiation, but it is a hard cap.  It means precisely that the blocksize can't increase (or decrease) by more than that amount over a period of time.  The period of time in question is also negotiable.  This gives you everything you're asking for, we just need to decide what the limit should be and over how long a timeframe.