XT Fork is necessary , IMO

[Jacobit]

The news of XT FORK spamed the page , this made me a little boredom, It is impolite not to reciprocate., so be bored together  .

I believes that as a member of the decentralized community, we really do not need to be too limited.

Bitcoin, figuratively, like a tree, do you still have to let it bare to prop up the sky? Twig is inevitable, as long as it continues to thrive, so much why ah, the strongest branch always only one . Besides, both from an aesthetic point of view or from the perspective of natural selection, tree's branches are necessary.

 So, the XT Fork is not terrible, More forks will be better.

[LiteCoinGuy]

Quick ELI5:

Running XT at this time is equivalent with running Core. It's the same network, and the same Bitcoins. At some point in the future, if 75% mining majority is reached (but not before January 2016), the network will split whenever a miner creates a block larger than 1MB. This will not be accepted by Core unless they adopt a large blocks patch, but will be accepted by XT, and at this point there will effectively be two chains.

Running XT means that you will always be on the largest (75%+) chain, regardless of whether the fork actually happens or not. Running Core means that you will be left behind if a 75% majority is reached. Regardless of which version you run, coins will be safe (on both chains) as long as you acquired them prior to the fork, and for some time the chains will largely mirror each other.

[slaveforanunnak1]

This is what I see happening:



1. XT Is out everyone!! Herpa Derp! 75% lets jump on the Gav coin (peace be up on his name)
2. Two chains live on for a while, with core having much less hashing power. (potential for double spends, whatevs.. wait for 20 confirmations for expensive shit)
3. After a little while all the schmuck's who jumped on Shitcoin-xt start to see signs of even more centralization, black/white listing and other types of fuckary
4. Smart ones panic and sell, and dumb ones get stuck holding a bag of Shitcoin-xts   
5. True BTC gets the nodes/hashing power back
6. we all live on happily ever after without mike and gavin (peace be up on his name) and they can go hang out with magical tux.

[Possum577]

I think there's probably a better analogy to use. The fork that's going on isn't the same as branches on a tree, it's just a fork in the road. How does a potential fork impact phsyical bitcoins?

Dude, are you just copying and pasting your post in multiple threads?

This is what I see happening:

1. XT Is out everyone!! Herpa Derp! 75% lets jump on the Gav coin (peace be up on his name)
2. Two chains live on for a while, with core having much less hashing power. (potential for double spends, whatevs.. wait for 20 confirmations for expensive shit)
3. After a little while all the schmuck's who jumped on Shitcoin-xt start to see signs of even more centralization, black/white listing and other types of fuckary
4. Smart ones panic and sell, and dumb ones get stuck holding a bag of Shitcoin-xts   
5. True BTC gets the nodes/hashing power back
6. we all live on happily ever after without mike and gavin (peace be up on his name) and they can go hang out with magical tux.

[Amph]

the changes of XT are necessary not the name change itself, why they can't simply perform those changes inside Core, instead of changing its name for no reason?

it seems that some of the developers want to follow their own route and gain more authority.

[slaveforanunnak1]

the changes of XT are necessary not the name change itself, why they can't simply perform those changes inside Core, instead of changing its name for no reason?

it seems that some of the developers want to follow their own route and gain more authority.

bingo

[coinableS]

the changes of XT are necessary not the name change itself, why they can't simply perform those changes inside Core, instead of changing its name for no reason?

it seems that some of the developers want to follow their own route and gain more authority.

Some of the developers decided that their idea was better. When the other developers told them otherwise they decided to "take their ball and go home". Seems like to me that egos are getting in the way.

[Kprawn]

the changes of XT are necessary not the name change itself, why they can't simply perform those changes inside Core, instead of changing its name for no reason?

it seems that some of the developers want to follow their own route and gain more authority.

Some of the developers decided that their idea was better. When the other developers told them otherwise they decided to "take their ball and go home". Seems like to me that egos are getting in the way.

You hit it bang on the head... XT guys stepped away from Bitcoin to do their own thing, and think they still have the power they had, when they were still in charge. Wladimir is

not taking that, and refuse to budge. So Gavin/Mike team up... create XT and get some support to force changes they need for their agenda ---> Hard fork.

Massive ego's at play here.... Who suffers? ---> Bitcoiners. 

You cannot have your best developers playing for opposing teams, if your common goal should be to develop Bitcoin. There can only be one A-Team. 

[tadakaluri]

As recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.

[Mickeyb]

Changes are necessary and bigger blocks as well. Lets hope that everybody will just sit together and get to some sort of consensus that will be implemented to the core itself.

This would be the best possible outcome, the best also from the confidence point of view for the whole Bitcoin ecosystem.

[KurtB]

As recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.

That seems so much smarter than a brute increase of block size. At least it would increase the speed and the volume.
Ethereum has 12s block time.
- Yet, I would not support either at this point.

[Denker]

Changes are necessary and bigger blocks as well. Lets hope that everybody will just sit together and get to some sort of consensus that will be implemented to the core itself.

This would be the best possible outcome, the best also from the confidence point of view for the whole Bitcoin ecosystem.

100% agree.

[Carlton Banks]

As recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.

That seems so much smarter than a brute increase of block size. At least it would increase the speed and the volume.
Ethereum has 12s block time.
- Yet, I would not support either at this point.

Satoshi chose the 10 minute block interval as another careful, conservative limit. Sergio is an incredibly accomplished computer scientist, he would not suggest this change if he wasn't confident that Satoshi's concerns can be mitigated.

I'm not sure how much this helps though; it's two broad issues rolled into one, so it has the potential to just create a whole new set of arguments. However, if 95% of people agreed to do this tomorrow, and the technical aspects were convincing to me, I'd get on board.

[coinableS]

As recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.

Under this model would we still have reward halvings every 210,000 blocks? If so, the coin distribution phase will be doubled where the last coin will be mined in ~50 years instead of ~100 years which could be very bad. We would have to reduce the rewards in half as well if blocks were found every 5 minutes.  To me that sounds much more drastic than lifting the blocksize.
There's also those miners that are not validating previous blocks because it takes 10 seconds away where they could be hashing. If we reduced the blocktime to 5 minutes, that will take an even larger percentage out of their hashing times where we can almost guarantee miners won't be validating newly found blocks.

[Lauda]

Under this model would we still have reward halvings every 210,000 blocks? If so, the coin distribution phase will be doubled where the last coin will be mined in ~50 years instead of ~100 years which could be very bad. We would have to reduce the rewards in half as well if blocks were found every 5 minutes.  To me that sounds much more drastic than lifting the blocksize.
There's also those miners that are not validating previous blocks because it takes 10 seconds away where they could be hashing. If we reduced the blocktime to 5 minutes, that will take an even larger percentage out of their hashing times where we can almost guarantee miners won't be validating newly found blocks.

While I am unaware of the exact thing that he has proposed, this is not drastic at all. Just to explain this to your; simplified: halve the block times to 5 minutes, and decrease the coin generation by half = problem solved and we are back on the ~100 years track. Note: I'm not saying that I support such a proposal.
XT is not necessary, stop spreading wrong information. There is no urgency to increase the block size limit. It needs to happen eventually, but not without proper testing and consensus.
To elaborate further why XT is dangerous and risky (technical part):

bug fix:
If "relay the first observed double spend" were generally accepted as a bug with a clean fix available, it'd be fixed in Core; superficial searching says it got reverted as problematic and contentious but I don't know the whole story, nor do I have an opinion on the change.
two minor things:
One is for Hearn's Lighthouse project, and also got merged, found buggy, and reverted. Without those eyeballs, would the lack of testing have been addressed and the bug in getutxos have been spotted before it was widely rolled out?
The other is adding back the bitnodes seed node that was removed for behaving in fishy ways, and adding a seed run by Mike

Is XT basically going to be every patch Mike Hearn ever had refused by NACKs in Core? Where does that road take you as a user of XT?

Simplified:

• Automatic blacklisting controlled by the Tor project (AFAIK without their consent).
• Buggy block size validation.
• Lighthouse slave support.
• Incomplete/buggy double spend detection.

[balu2]

The quickest solution is if the community could start expressing the real consensus which is: "go home, Gavin and Mike"

[tadakaluri]

What about this?

Bigger blocks would take longer to propagate to other miners when first found. A longer propagation time should lead to a higher orphan rate, as more miners would be mining on older blocks, while newer blocks are still finding their way through the network.

[Za1n]

As recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.

Under this model would we still have reward halvings every 210,000 blocks? If so, the coin distribution phase will be doubled where the last coin will be mined in ~50 years instead of ~100 years which could be very bad. We would have to reduce the rewards in half as well if blocks were found every 5 minutes.  To me that sounds much more drastic than lifting the blocksize.
There's also those miners that are not validating previous blocks because it takes 10 seconds away where they could be hashing. If we reduced the blocktime to 5 minutes, that will take an even larger percentage out of their hashing times where we can almost guarantee miners won't be validating newly found blocks.

These were also my thoughts when reading about Sergio's proposal. I think your last point about the miners not validating previous blocks nails the reason this proposal would be a bad idea square on the head. To me everyone seems to be ignoring this problem in that even with an increase in blocksize, what is the incentive to miners to fill up a block, as if they are worried in doing so they could end up with an orphan. I believe this is the worry of Chinese miners as they already have borderline network connectivity problems.

[jonald_fyookball]

As recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.

I don't see how this is an improvement on Jeff's 2mb proposal
as this will be equivalent to the same blockchain growth.
(2 MB every ten min = 1 MB every 5 min).  Also requires
a hardfork just the same.

@Lauda:  Gavin has done extensive testing already.
And we will be getting many full blocks in about a year.
Don't you see the core devs are stonewalling because
of their interests in Blockstream? 

[bassclef]

The quickest solution is if the community could start expressing the real consensus which is: "go home, Gavin and Mike"

If the nodes and miners don't start jumping on board, that is exactly what will happen regardless how loudly one can make his argument.