...

[canth]

So the real issue is only whose boots are to be licked, Adam's or Mike's?

correct

^^-- LIKE

JorgeStolfi, if you read the thread topic, the goal is to not run software that does blacklisting, or more specifically, introduces centralized trust, which is a systemic risk and counter to the principles of Bitcoin.  What differentiates Bitcoin from everything that came before it is that it is a TRUSTLESS SYSTEM.

I think most people support larger blocks overall, but don't support the additional logic being thrown into XT.  It looks like Mike has turned block size into a red herring for other agenda, permitting him to take over bitcoin code and introduce other "features" that run counter to the trustless network that Bitcoin was designed to be.  

Bingo. Unfortunately, the diehard XT supporters in here won't address legitimate critiques, whether of XT or BIP 101. They'd rather continue to act as if anyone who doesn't support XT is a "Blockstream shill" and continue shouting while knocking over straw men. That way, it's pretty easy to force the discussion onto the next page and gloss over thoughtful posts.

Every time I've brought up how the third party compilation of IP addresses is centralized and trust-adding, the standard response (in the unlikely event that an XT supporter actually responds to the argument) is that "oh, anyone running a node can disable that feature." That's not good enough. Nodes don't need a centralized, trusted list to tell them when someone is attacking them from a certain IP address. That's laughable.

Why would anyone want to introduce trust, when the objective can be achieved without it?

What does this have to do with BIP 101?

That's very cute. The point I was responding to and the general subject of discussion here (see thread title) is XT. I'm not sure why you are implying that my comments are out of place.

BIP101 and XT are separate issues. I oppose both, although I do support some mechanism for increasing block size limit, generally. IF BIP101 is going to happen (doubtful), we as a community need to discourage the use of XT, as its default implementation (which the vast majority of nodes will use) contains trust-adding features, and unnecessarily so.

That's the issue - you have your "legitimate critiques" that "diehard XT supporters won't address" which seems to primarily be the Tor IP address list. Fine, so BIP 101 and only-bigblocks code allows you to run that without any anti-ddos protection and the supposed IP address centralization.

People have choices about what to run and are welcome to choose Core or only-bigblocks or some other BIP variation and yet you still want to bash away at XT. Do you have anything to add to the conversation or is it just 'blah, blah, centralization, IP addresses, trust, omg, Hearn, CIA'?

[1714037926]

1714037926

[canth]

I'll never climb the "leadership hierarchy" if I try that.

Yeah, someone might call you a dictator for giving people a choice.

Right now, just a dictator of a tiny island with nuclear missiles pointed at the Bitcoin network.  But, if XT succeeds, he could become dictator of the Bitcoin protocol.  

Riiight. Wouldn't this only happen if, oh, the majority of people running XT nodes thought you were dead wrong? How exactly can a fork of bitcoin create a dictatorship? If the users didn't like the code, it would be re-forked and users would run right back to Core or another version.

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

[marky89]

I don't understand what's so hard.

1. You like 1 MB blocksize limit and think there's no need to raise it anytime soon.
Solution: Install Bitcoin Core

2. You want blocksize limit to be increased (BIP 101), but disagree with additions made to Bitcoin XT
Solution: Install Core codebase + BIP 101. You don't even have to compile it yourself, there's precompiled binaries available.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/

3. You want blocksize limit to be increased and think other additions in Bitcoin XT are cool.
Solution: Install Bitcoin XT

4. You want blocksize limit to be increased and think other additions in Bitcoin XT are cool, except the evil TOR node dropping DDOS protection.
Solution: Raise discussion with Bitcoin XT devs for that part of code to be removed/disabled by default or be a sport and compile the code yourself without the offending code and put the binaries available for others to download.

5. You're not happy with 1MB blocksize limit and BIP 101 sounds like a stupid idea.
Solution: A.) Wait patiently and someone might make BIP XXX fork that you like better. B) Code something that pleases you and publish your own BIP.  

This is decentralization.

Sure. There is also nothing wrong with debating the merits of any of the options -- particularly when there are so many people that are conflating support of BIP 101 with support of XT (ie. there are two options: XT, which means big blocks OR the 1MB status quo). In reality, there are many options, including BIPs that have already been proposed.

So the real issue is only whose boots are to be licked, Adam's or Mike's?

correct

^^-- LIKE

JorgeStolfi, if you read the thread topic, the goal is to not run software that does blacklisting, or more specifically, introduces centralized trust, which is a systemic risk and counter to the principles of Bitcoin.  What differentiates Bitcoin from everything that came before it is that it is a TRUSTLESS SYSTEM.

I think most people support larger blocks overall, but don't support the additional logic being thrown into XT.  It looks like Mike has turned block size into a red herring for other agenda, permitting him to take over bitcoin code and introduce other "features" that run counter to the trustless network that Bitcoin was designed to be.  

Bingo. Unfortunately, the diehard XT supporters in here won't address legitimate critiques, whether of XT or BIP 101. They'd rather continue to act as if anyone who doesn't support XT is a "Blockstream shill" and continue shouting while knocking over straw men. That way, it's pretty easy to force the discussion onto the next page and gloss over thoughtful posts.

Every time I've brought up how the third party compilation of IP addresses is centralized and trust-adding, the standard response (in the unlikely event that an XT supporter actually responds to the argument) is that "oh, anyone running a node can disable that feature." That's not good enough. Nodes don't need a centralized, trusted list to tell them when someone is attacking them from a certain IP address. That's laughable.

Why would anyone want to introduce trust, when the objective can be achieved without it?

What does this have to do with BIP 101?

That's very cute. The point I was responding to and the general subject of discussion here (see thread title) is XT. I'm not sure why you are implying that my comments are out of place.

BIP101 and XT are separate issues. I oppose both, although I do support some mechanism for increasing block size limit, generally. IF BIP101 is going to happen (doubtful), we as a community need to discourage the use of XT, as its default implementation (which the vast majority of nodes will use) contains trust-adding features, and unnecessarily so.

That's the issue - you have your "legitimate critiques" that "diehard XT supporters won't address" which seems to primarily be the Tor IP address list. Fine, so BIP 101 and only-bigblocks code allows you to run that without any anti-ddos protection and the supposed IP address centralization.

People have choices about what to run and are welcome to choose Core or only-bigblocks or some other BIP variation and yet you still want to bash away at XT. Do you have anything to add to the conversation or is it just 'blah, blah, centralization, IP addresses, trust, omg, Hearn, CIA'?

Excuse me? I've written quite a bit about why BIP 101 is reckless and there are more responsible solutions, and why painting the situation as "optional = okay" is problematic. This sort of baseless vitriol is insulting. And why can't you address the argument, rather than set up straw men like "omg, Hearn, CIA" which are irrelevant to anything I have said? This is what people mean by populism -- ignoring academic, technical and political arguments out of loyalty to their cause. Keep up the good work ad hominem.

And why wouldn't you prefer to take the decentralized, trustless route (which is 100% doable) rather than simply assuming that it is innocent and supporting XT regardless of any features that it supports (and will presumably support in the future)? This just reeks of blind trust.

[erik777]

I'll never climb the "leadership hierarchy" if I try that.

Yeah, someone might call you a dictator for giving people a choice.

Right now, just a dictator of a tiny island with nuclear missiles pointed at the Bitcoin network.  But, if XT succeeds, he could become dictator of the Bitcoin protocol.  

Riiight. Wouldn't this only happen if, oh, the majority of people running XT nodes thought you were dead wrong? How exactly can a fork of bitcoin create a dictatorship? If the users didn't like the code, it would be re-forked and users would run right back to Core or another version.

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is more about if they switch their code to XT from Core, and let's say that Core loses its momentum.  It wouldn't be so easy to switch back.  Everyone talk as if a single client is what matters.  It is the network as a whole.  Control the clients, you control the network.  

If you consider his bias towards centralization, and his new development model where he can do whatever he wants unopposed in XT, if XT had a critical mass of installs, he could change the network in a way that would make it very hard to leave.  Perhaps leaving could end up putting your node on an untrusted ban list.  

To be sure, this is big picture and a long-shot.  But, given the proposals of Mike over the years, and his new status as king of all XT commits, and XT's clear plans to dominate the network, it is not beyond imagination to see how, even in the bitcoin world, we have to counter dictators BEFORE they rise to power. Is this really any different than 1000s of years of history, except this is now in a new virtual world that most end-users do not want to begin to understand?  There isn't a whole of of accuracy from the mass media reporting on the detailed concerns of this fork.

[brg444]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

[canth]

That's the issue - you have your "legitimate critiques" that "diehard XT supporters won't address" which seems to primarily be the Tor IP address list. Fine, so BIP 101 and only-bigblocks code allows you to run that without any anti-ddos protection and the supposed IP address centralization.

People have choices about what to run and are welcome to choose Core or only-bigblocks or some other BIP variation and yet you still want to bash away at XT. Do you have anything to add to the conversation or is it just 'blah, blah, centralization, IP addresses, trust, omg, Hearn, CIA'?

Excuse me? I've written quite a bit about why BIP 101 is reckless and there are more responsible solutions, and why painting the situation as "optional = okay" is problematic. This sort of baseless vitriol is insulting. And why can't you address the argument, rather than set up straw men like "omg, Hearn, CIA" which are irrelevant to anything I have said? This is what people mean by populism -- ignoring academic, technical and political arguments out of loyalty to their cause. Keep up good work ad hominem.

And why wouldn't you prefer to take the decentralized, trustless route (which is 100% doable) rather than simply assuming that it is innocent and supporting XT regardless of any features that it supports (and will presumably support in the future)? This just reeks of blind trust.
[/quote]

Vitriol is never good for the bitcoin community - apologies for any frustrations that I have with what I view are poor arguments.

I support XT primarily because I strongly believe that having a single bitcoin client is bad for the community - it implies that we have one small group of developers that lead without much of any check on their decisions. Yes, if the core team did something egregiously bad for the community, it would get rejected. However, any features that the community is interested in but aren't approved by essentially all 5 committers will have no chance to get tested.

I read the XT manifesto and for the most part, I think that it breathes some fresh air into a group of devs that is hostile toward not just ideas but individuals who try to contribute but don't have enough patience to deal with the personal attacks. To paraphrase Peter Todd from a recent meetup - "I would like to be working on tree chains, but the likelihood of that getting adopted is very low so instead I chose to work on something less controversial - checklocktimeverify." While this is fine, it does mean that a lot of developers that could be working in significant improvements may be sitting on the sidelines or choosing only the lowest hanging fruit since spending their time on anything that will get shot down is a waste of their time.

Regarding the IP addresses, I think it's a red herring. It's just not that important to me and you would be hard pressed to come up with a plausible scenario that will affect users. Regarding "blind trust" - this is also a terrible argument. This is FOSS. Everyone can review the code or rely on a trusted community member to review the code before running it. I never have to upgrade XT or Core if I don't want to. How is XT blind trust when Core is something else?

[canth]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

[brg444]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

[canth]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

[VirosaGITS]

Indeed, if a near consensus ever happen and we "jump" to a new fork, by the time that happen, i am pretty sure Core and most wallet will have already prepared their wallet version for the new fork.

[JorgeStolfi]

If you modify the code and recompile it, then try to run it. Are you sure it will work? Because usually when you change the code, it cause a fork.

Not at all.  

First, if you are not a miner, you can do any mess in the code that you want, and the worst that can happen is that you are unable to move your coins, or you send them to Neverland, or you reveal your keys to hackers and they steal your coins.  No matter what you do, there will be no fork.

If you were a miner, you would probably know what you are doing because your company's revenue depends on it.  But even if you change the code in an incompatible way, there will not be a permanent fork.  

First, if your program accepts transactions that are invalid according to the official version, that bug will matter only if some client issues such a transaction.  That is rather unlikely, because clients usually want their transactions to be executed, so they usually try to generate only valid ones.  Even if that happens, and you include that transaction in a block,  that block will be rejected by all other miners.  So you would indeed fork the blockchain, but no one will accept your new branch and it will be orphaned right away.  

Ditto if your software may create blocks from valid transactions that are invalid to the official version, for their size or something in the header.  Any such block will be a trivial fork that is orphaned right away.

Finally, if your program rejects transactions or blocks that the official version accepts,  you will be in trouble if and when some other miner mines such a block.  Then the chain will indeed fork.  You will reject the main branch of the chain, that starts with that block, and you will try to mine only on a side branch that contains ony blocks that you approve.  However, you will be the only miner working on that branch; so it will grow very slowly, and everybody, again, will ignore it.  No one will accept the coins that you mine.  Therefore, as soon as you notice that you are no longer in the flock, you will quickly get smart, fix your code, and join the others mining on the main branch.

[brg444]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

I object! By the way I have no "concern about XT": https://bitcointalk.org/index.php?topic=1162684.0

Your interpretation of "how things should be" is a very common misunderstanding of the consensus fragility of the Bitcoin. Allow me to quote myself here:

You absolutely don't understand or are being willingly misleading about this "centralization" issue. There is quite simply no other choice but for us to support a centralized (read unique) consensus code. That's pretty much the only way Bitcoin works. It happens that the core developers have historically been the one trusted with maintaining this code and updating it. Several implementations have been built around this consensus code. Most of them have little support for very valid reason: their implementation is generally considered less tested and therefore potentially less secure than core implementation. Now should we blame core for attracting the most competent developers in the space? Would it be rational to ask of them to each start dividing their work between different implementations just for the sake of "decentralization"?

The centralization issue you refer to is nothing more than a lack of man power. That is, only a scarce amount of people are reliable and technically able enough to handle the highly fragile development of Bitcoin. It is no wonder the guys currently leading core are some of the world's most advanced experts in their own field. This expertise cannot be easily replaced or dismissed "because decentralization". 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.

[canth]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

I object! By the way I have no "concern about XT": https://bitcointalk.org/index.php?topic=1162684.0

Your interpretation of "how things should be" is a very common misunderstanding of the consensus fragility of the Bitcoin. Allow me to quote myself here:

You absolutely don't understand or are being willingly misleading about this "centralization" issue. There is quite simply no other choice but for us to support a centralized (read unique) consensus code. That's pretty much the only way Bitcoin works. It happens that the core developers have historically been the one trusted with maintaining this code and updating it. Several implementations have been built around this consensus code. Most of them have little support for very valid reason: their implementation is generally considered less tested and therefore potentially less secure than core implementation. Now should we blame core for attracting the most competent developers in the space? Would it be rational to ask of them to each start dividing their work between different implementations just for the sake of "decentralization"?

The centralization issue you refer to is nothing more than a lack of man power. That is, only a scarce amount of people are reliable and technically able enough to handle the highly fragile development of Bitcoin. It is no wonder the guys currently leading core are some of the world's most advanced experts in their own field. This expertise cannot be easily replaced or dismissed "because decentralization". 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.

We're going to have to agree to disagree. I'm not going to try the "you're too stupid to understand" argument which you seem to fall back on - we just fundamentally disagree on what are acceptable levels of consensus or fragility.

[brg444]

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?

I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

I object! By the way I have no "concern about XT": https://bitcointalk.org/index.php?topic=1162684.0

Your interpretation of "how things should be" is a very common misunderstanding of the consensus fragility of the Bitcoin. Allow me to quote myself here:

You absolutely don't understand or are being willingly misleading about this "centralization" issue. There is quite simply no other choice but for us to support a centralized (read unique) consensus code. That's pretty much the only way Bitcoin works. It happens that the core developers have historically been the one trusted with maintaining this code and updating it. Several implementations have been built around this consensus code. Most of them have little support for very valid reason: their implementation is generally considered less tested and therefore potentially less secure than core implementation. Now should we blame core for attracting the most competent developers in the space? Would it be rational to ask of them to each start dividing their work between different implementations just for the sake of "decentralization"?

The centralization issue you refer to is nothing more than a lack of man power. That is, only a scarce amount of people are reliable and technically able enough to handle the highly fragile development of Bitcoin. It is no wonder the guys currently leading core are some of the world's most advanced experts in their own field. This expertise cannot be easily replaced or dismissed "because decentralization". 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.

We're going to have to agree to disagree. I'm not going to try the "you're too stupid to understand" argument which you seem to fall back on - we just fundamentally disagree on what are acceptable levels of consensus or fragility.

Ok 

What if I told you there are already multiple software clients available to all users?

Have a look here: https://getaddr.bitnodes.io/nodes/

I can count nearly a hundred different software versions/implementation of the Bitcoin consensus code being run. Now what is it exactly you are complaining about?

[VirosaGITS]

If you modify the code and recompile it, then try to run it. Are you sure it will work? Because usually when you change the code, it cause a fork.

Not at all.  

First, if you are not a miner, you can do any mess in the code that you want, and the worst that can happen is that you are unable to move your coins, or you send them to Neverland, or you reveal your keys to hackers and they steal your coins.  No matter what you do, there will be no fork.

If you were a miner, you would probably know what you are doing because your company's revenue depends on it.  But even if you change the code in an incompatible way, there will not be a permanent fork.  

First, if your program accepts transactions that are invalid according to the official version, that bug will matter only if some client issues such a transaction.  That is rather unlikely, because clients usually want their transactions to be executed, so they usually try to generate only valid ones.  Even if that happens, and you include that transaction in a block,  that block will be rejected by all other miners.  So you would indeed fork the blockchain, but no one will accept your new branch and it will be orphaned right away.  

Ditto if your software may create blocks from valid transactions that are invalid to the official version, for their size or something in the header.  Any such block will be a trivial fork that is orphaned right away.

Finally, if your program rejects transactions or blocks that the official version accepts,  you will be in trouble if and when some other miner mines such a block.  Then the chain will indeed fork.  You will reject the main branch of the chain, that starts with that block, and you will try to mine only on a side branch that contains ony blocks that you approve.  However, you will be the only miner working on that branch; so it will grow very slowly, and everybody, again, will ignore it.  No one will accept the coins that you mine.  Therefore, as soon as you notice that you are no longer in the flock, you will quickly get smart, fix your code, and join the others mining on the main branch.

Well... kinda. You will "try" to fork but the proper way to describe it is. "Your transaction will be invalid." With no weight behind your blocks, you would have created a fork but it would not really exist. This would be basically making an alt coin then slamming it at the BTC chain. It would do absolutely nothing in effect.

[RoadStress]

The amount of newbies in this thread is hilarious!

[VirosaGITS]

The amount of newbies in this thread is hilarious!

The amount of people in this thread that contribute absolutely nothing is hilarious!

[iCEBREAKER]

Yes, the only "XT" blocks mined thus far are actually from a FakeXT node.  Slush must be a gambler!  

So much for canth's pompous "I for one don't believe" opinion.

Apparently, nobody (especially Slush) cares what canth does or does not believe.  

Oh boo hoo, let's all cry about slush's "deceitful indication of larger block support" (which was "a likely scenario" after all).  

By fake, I mean advertising accepting BIP101 blocks but in fact rejecting them, which Slush it not doing. Anyone that runs NotXT might as well be running NotBIP101 on core since it's the exact same deceitful practice. It doesn't help demonstrate support for alternative BIPs; it might help fracture the network in January. I know you're not dumb enough to have ignored the game theory - anyone that runs NotXT is gambling with everyone's money without any upside.

Slush isn't running XT or NotXT.  Slush's present nodes will in fact reject >1MB blocks.  Slush is spoofing, as has already been explained here:

https://www.reddit.com/r/bitcoinxt/comments/3id0rf/slush_gets_another_bip_101_371472/cufg7bg

How am I ignoring the game theory?  I already explained why/how NotXT exacerbates the risk for defections to XT, by minimizing its chances of success.  And OrganOfCorti mathed the hell out of that, leaving no doubt those brave enough to accept XTcoins are going to have a bad time.   

[RoadStress]

Well the same way you get satoshis right now. You either mine yourself or find someone that can provide you with them.

Yeah, that seems quite easy. Why didn't I think of that? [/sarcasm]

Don't worry. There will be a market for those satoshies for sure.

Estimates of people who own some bitcoin range from 3'000'000 (Coinbase, BCI claims) to 300'000 (me).  The latter is my estimate of how many people own at least 1 BTC; together, those users own 99% of all bitcoins in existence.  

So, how many bitcoiners do you think know enough about the bitcoin protocol to understand how they can get get their transactions executed in one chain only; and know how to do that without messing up their wallet file; and can obtain a few satoshis that were mined after the fork; and are interested in handling split coins; and can find buyers who can also do all of that; and are dumb enough to buy coins that may die in a few days?

Those that have coins in Coinbase or other third-party wallets will execute their transfers on the fork that the third-party will choose. They will not have the option to taint their coins to make a transfer on the other fork because they will not be able to do it using a third-party wallet.

Also if a hard fork occurs you can be damn sure that there will be announcements everywhere and also the third-party wallet provider will let their users know about the hard-fork and what to do. It sounds logic to me to do that. You make it sound like the sky will fall, when in reality it will not fall. Take a xanax and chill.

Yes, I have observed already that, for the fanatic bitcoiner, *every* detail of bitcoin is a feature; and *everything* that happens is "how the system works".  

Sorry, but it is a bug that the coins on each branch may or may not be moved independently, with most clients being unable ot understand or control what is happening.

Hackery is what you propose to do: move coins independently on the two branches by tainting them with coinbase coins, and sell the version you think will die to anyone fool enough to buy them, or to anyone naive enough to not understand what he is buying.   The 100 block delay was probably meant to discourage that kind of hackery after forks -- soft, hard, or accidental.

It is your opinion and you are free to have one. But don't act surprised if people laugh at your opinions when it comes to Bitcoin knowledge.

Correct.  More precisely, any UTXOs that were created before the fork exist and can be used on both branches.  If you try to move them without tainting, they will be moved on both branches, to UTXOs that are still untainted.  Once you get hold of some satoshis that were mined on one branch (either one), you can first move all your old UTXOs on that branch to new UTXOs, with tainted transactions, and then you can move again the same old UTXOs to still other UTXOs with untainted transactions, that will be executed only on the other branch (because on the first one those outputs are already spent).  

Finally we agree on something.

[canth]

Yes, the only "XT" blocks mined thus far are actually from a FakeXT node.  Slush must be a gambler!  

So much for canth's pompous "I for one don't believe" opinion.

Apparently, nobody (especially Slush) cares what canth does or does not believe.  

Oh boo hoo, let's all cry about slush's "deceitful indication of larger block support" (which was "a likely scenario" after all).  

By fake, I mean advertising accepting BIP101 blocks but in fact rejecting them, which Slush it not doing. Anyone that runs NotXT might as well be running NotBIP101 on core since it's the exact same deceitful practice. It doesn't help demonstrate support for alternative BIPs; it might help fracture the network in January. I know you're not dumb enough to have ignored the game theory - anyone that runs NotXT is gambling with everyone's money without any upside.

Slush isn't running XT or NotXT.  Slush's present nodes will in fact reject >1MB blocks.  Slush is spoofing, as has already been explained here:

https://www.reddit.com/r/bitcoinxt/comments/3id0rf/slush_gets_another_bip_101_371472/cufg7bg

How am I ignoring the game theory?  I already explained why/how NotXT exacerbates the risk for defections to XT, by minimizing its chances of success.  And OrganOfCorti mathed the hell out of that, leaving no doubt those brave enough to accept XTcoins are going to have a bad time.  

What is it that you don't get? Slush is indicating support for >1MB blocks via XT/BIP101. Since no version of XT or only-bigblocks or Core will accept >1MB blocks prior to January 2016 then it doesn't matter that he hasn't updated to XT or BIP 101 mining prior to then. Is your point that the NotXTers will move to BIP101 or XT in January 2016? That seems to not quite be in the spirit of NotXT.

I read the OrganOfCorti comments - he used numbers ranging between 0.16 and 0.21 of fake voters. That's fine - if it's a small number of fakers then it doesn't matter. The more the fake votes increase, the better the chance for 'premature activation'. Go ahead...run NotXT - gamble away, but you sure can't take the moral high ground.