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

[VeritasSapere]

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

I agree that it might not be enough of an increase, which is why a dynamic block size or a greater increase would be better. However I would consider both options far better then just keeping the one megabyte block size in place, which I know you do not advocate. That however I see as the greatest threat even if it is a result of disagreement of how and when to increase the blocksize.

So I am personally happy to compromise so that we can reach consensus sooner. You already know that I disagree with considering XT to be a coup, so lets not go over that again we have both made our arguments already.

Although you're representing my views almost accurately (which is a strange experience, don't expect too much effort from me before I regret replying to you), you're still not getting it quite right.

Remember how differently this could have happened; Gavin Andresen used to be the lead developer for Bitcoin Core. He voluntarily handed control over to Wladimir van der Laan to work at the Bitcoin Foundation. If that didn't happen, the entire course of the block limit contention might have played out quite differently. I can imagine various plausible scenarios where I would have backed a fork away from Andresen's control of the Core client, especially when you bear in mind how ill-considered his approach to the scaling issue retrospectively.

So, the main reason to either support or reject a blockchain fork proposal can be made for good reasons. Your reasoning suggests that no-one could ever be so callous as to propose a fork in order to screw with the design philosophy, but that's totally naive. Hearn represents the incumbent banking system in every way except admission; every proposal of his (including his philosophising about 8 nodes running the whole network etc) pushes centralisation while cheerfully inviting the audience to believe that 8 nodes is as decentralised as is needed. What would you expect an erstwhile coup progenitor to do, announce it unspun in advance?

I am glad that you can see that it could have been the other way around and that Core does not have any type of "authoritative" or "official" status in this regard. Anyone can propose a fork that could seriously screw with the design philosophy and this is not wrong or a coup of Bitcoin. Whether that fork is adopted or not is up to people and that is a part of the design philosophy of Bitcoin.

That is why it would not be wrong to propose a fork increasing the supply of Bitcoin for instance, whether you can get people to support it is a different matter all together. The only conceivable way to carry out a coup of Bitcoin would be to somehow circumvent the consensus mechanism itself by somehow going against the 51% of miners, I am not sure if this is even possible. It could also be considered a coup if force is used to coerce miners and full node operators. However this is not what XT is proposing to do.

It still stands that if one of these five Core developers becomes unreasonable and refuses any change to the block size whatsoever and no compromise can be reached then the only way to increase the block size would be to fork away from the Core development team. This reliance on these five people at the very least should be considered a hypothetical problem that could happen one day if it has not already happened.

I was not even talking about XT, however this stuff that you are saying is completely inaccurate and I do not understand while you feel the need to even say such things. To support BIP101 is just to support bigger blocks not the incumbent banking system, and 8 nodes running the whole network, this is just hyperbole and conjecture. You are being unnecessarily polarizing. I would support a 12.5% increase per year or a dynamic block size instead in the intrest of compromise and consensus after all.

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

[brg444]

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

So what is the plan?

What level of wild bitcoin adoption do you expect?

You do realize that "wild" metric implies "wild" block size increase as well? Where does that get us?

[hdbuck]

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

So what is the plan?

What level of wild bitcoin adoption do you expect?

You do realize that "wild" metric implies "wild" block size increase as well? Where does that get us?

Its not about "level of adoption" (there is no healthy drive besides the "hide secure y'all wealth" thing), but rather about the "late-comers" pump of litecoin & co that ensues..

[erik777]

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.

"In mathematics, a conjecture is a conclusion or proposition based on incomplete information, but for which no proof has been found.[1][2] Conjectures such as the Riemann hypothesis (still a conjecture) or Fermat's Last Theorem (now proven, while has been called, Fermat's conjecture) have shaped much of mathematical history as new areas of mathematics are developed in order to solve them." (wikipedia)

How on earth do you apply the term "conjecture" to discussion about future possibilities? 

As for the benevolent dictator's past proposals, definitely not conjecture. E.g.,

https://bitcointalk.org/index.php?topic=333824.0

[erik777]

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

I agree that it might not be enough of an increase, which is why a dynamic block size or a greater increase would be better. However I would consider both options far better then just keeping the one megabyte block size in place, which I know you do not advocate. That however I see as the greatest threat even if it is a result of disagreement of how and when to increase the blocksize.

So I am personally happy to compromise so that we can reach consensus sooner. You already know that I disagree with considering XT to be a coup, so lets not go over that again we have both made our arguments already.

Although you're representing my views almost accurately (which is a strange experience, don't expect too much effort from me before I regret replying to you), you're still not getting it quite right.

Remember how differently this could have happened; Gavin Andresen used to be the lead developer for Bitcoin Core. He voluntarily handed control over to Wladimir van der Laan to work at the Bitcoin Foundation. If that didn't happen, the entire course of the block limit contention might have played out quite differently. I can imagine various plausible scenarios where I would have backed a fork away from Andresen's control of the Core client, especially when you bear in mind how ill-considered his approach to the scaling issue retrospectively.

So, the main reason to either support or reject a blockchain fork proposal can be made for good reasons. Your reasoning suggests that no-one could ever be so callous as to propose a fork in order to screw with the design philosophy, but that's totally naive. Hearn represents the incumbent banking system in every way except admission; every proposal of his (including his philosophising about 8 nodes running the whole network etc) pushes centralisation while cheerfully inviting the audience to believe that 8 nodes is as decentralised as is needed. What would you expect an erstwhile coup progenitor to do, announce it unspun in advance?

I thought I heard all of his bad ideas, but 8 nodes is a new one.  Do you have a link to this proposal so I can add it to my collection?

[VeritasSapere]

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

"In mathematics, a conjecture is a conclusion or proposition based on incomplete information, but for which no proof has been found.[1][2] Conjectures such as the Riemann hypothesis (still a conjecture) or Fermat's Last Theorem (now proven, while has been called, Fermat's conjecture) have shaped much of mathematical history as new areas of mathematics are developed in order to solve them." (wikipedia)

How on earth do you apply the term "conjecture" to discussion about future possibilities?  

As for the benevolent dictator's past proposals, definitely not conjecture. E.g.,

https://bitcointalk.org/index.php?topic=333824.0

Let me explain it to you simply. Within Bitcoin XT today only the blocksize increase itself is fundamental to the protocol, and you can just run a BIP101 only version of XT or Core. These things that you are claiming here are completely counter factual and inaccurate. Therefore it is accurate to refer to your statements as conjecture because you have no proof backing up your statements.

1> Bitcoin becomes centralized (the protocol) via trusted nodes.

This has not been proposed for XT and has not been implemented in the code.

2> Bitcoin uses checkpoints to prevent another hostile takeover like its own.

The use of checkpoints has not been proposed for XT and has not been implemented in the code.

3> Bitcoin replaces anonymity with identity requirements (passports).

This has not been proposed for XT and has not been implemented in the code.

4> Bitcoin loses fungibility in favor of tainted coins, red lists, black lists, and white lists.

This has not been proposed for XT and has not been implemented in the code.

5> Due to #1-4, it would be hard to use any other implementation.

Because #1-4 are not true it will not make it hard to just run another implementation of Bitcoin.

I have studied political philosophy so I am well aware of how to predict and recognize tyranny, having 75% of the miners to agree with a fork in advance is not a tyranny by any stretch of the definition. Also to be the benevolent dictator of your implementation of Bitcoin is not wrong, and is not the same as being the benevolent dictator of Bitcoin. This is a very important distinction, I do hope that you can come to understand this difference. In the case of Bitcoin the code is all that really matters, so attacking the person has no relevance. What matters is what is in the code now, and none of the things you have mentioned are in the code now, it is completely counter factual. I am also aware of where you are getting this information from and you are quoting Mike Hearn out of context from a time before BIP101 was even implemented in XT and they where discussing hypothetical worst case scenarios. It does not even matter if Mike Hearn believes these things, since if he did try to implement these features like you claim he will, then people can simply just not use his implementation of Bitcoin and use another instead, it is that simple.

[brg444]

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

"In mathematics, a conjecture is a conclusion or proposition based on incomplete information, but for which no proof has been found.[1][2] Conjectures such as the Riemann hypothesis (still a conjecture) or Fermat's Last Theorem (now proven, while has been called, Fermat's conjecture) have shaped much of mathematical history as new areas of mathematics are developed in order to solve them." (wikipedia)

How on earth do you apply the term "conjecture" to discussion about future possibilities?  

As for the benevolent dictator's past proposals, definitely not conjecture. E.g.,

https://bitcointalk.org/index.php?topic=333824.0

Let me explain it to you simply. Within Bitcoin XT today only the blocksize increase itself is fundamental to the protocol, and you can just run a BIP101 only version of XT or Core. These things that you are claiming here are completely counter factual and inaccurate. Therefore it is accurate to refer to your statements as conjecture because you have no proof backing up your statements.

1> Bitcoin becomes centralized (the protocol) via trusted nodes.

This has not been proposed for XT and has not been implemented in the code.

2> Bitcoin uses checkpoints to prevent another hostile takeover like its own.

The use of checkpoints has not been proposed for XT and has not been implemented in the code.

3> Bitcoin replaces anonymity with identity requirements (passports).

This has not been proposed for XT and has not been implemented in the code.

4> Bitcoin loses fungibility in favor of tainted coins, red lists, black lists, and white lists.

This has not been proposed for XT and has not been implemented in the code.

5> Due to #1-4, it would be hard to use any other implementation.

Because #1-4 are not true it will not make it hard to just run another implementation of Bitcoin.

I have studied political philosophy so I am well aware of how to predict and recognize tyranny, having 75% of the miners to agree with a fork in advance is not a tyranny by any stretch of the definition. Also to be the benevolent dictator of your implementation of Bitcoin is not wrong, and is not the same as being the benevolent dictator of Bitcoin. This is a very important distinction, I do hope that you can come to understand this difference. In the case of Bitcoin the code is all that really matters, so attacking the person has no relevance. What matters is what is in the code now, and none of the things you have mentioned are in the code now, it is completely counter factual. I am also aware of where you are getting this information from and you are quoting Mike Hearn out of context from a time before BIP101 was even implemented in XT and they where discussing hypothetical worst case scenarios. It does not even matter if Mike Hearn believes these things, since if he did try to implement these features like you claim he will, then people can simply just not use his implementation of Bitcoin and use another instead, it is that simple.

Really? Did your teacher somehow forget to teach you Hayek?

I suggest you read Hayek's Road to Serfdom.

Totalitarianism under the urge to follow a "strong" leader by steering the sheeps against a "common enemy" is not giving choice to the market.

[VeritasSapere]

I suggest you read Hayek's Road to Serfdom.

Totalitarianism under the urge to follow a "strong" leader by steering the sheeps against a "common enemy" is not giving choice to the market.

Having the requirement in place that 75% of the miners have to agree with this change first is in fact giving the choice to the market, considering that the miners would most likely not implement such a change without the economic majority also being on board as well. Hayek also defined totalitarianism as the desire to organise the whole of society and attain a definite social goal, this is also certainly not the case with XT.

[erik777]

I suggest you read Hayek's Road to Serfdom.

Totalitarianism under the urge to follow a "strong" leader by steering the sheeps against a "common enemy" is not giving choice to the market.

Having the requirement in place that 75% of the miners have to agree with this change first is in fact giving the choice to the market, considering that the miners would most likely not implement such a change without the economic majority also being on board as well. Hayek also defined totalitarianism as the desire to organise the whole of society and attain a definite social goal, this is also certainly not the case with XT.

You completely and conveniently ignore what I'm saying.  This is a POSSIBLE PATH that could come about IN THE FUTURE.  So, saying that it isn't in XT today doesn't counter anything.  You are arguing with yourself.  Here, I'll agree with you...  "what could become the future is not true in the present."

What is factual is the relationship between these possibilities and the XT creator's past proposals.  In other words, it is based on what the "benevolent dictator" could do if he had enough control over Bitcoin clients and miner code. 

The question isn't whether you have free choice today to not install XT.  If you didn't, I wouldn't spend my time typing this.  It is whether you can lose that free choice by trusting future releases of XT loaded with its patches (e.g., blacklisting) and other protocol changes.

As a crude comparison, since you are hooked on the tyranny concept, Hitler didn't start out his political campaign with a proposal to exterminate people.  He started it with proposals the people wanted to hear... to restore Germany to its former glory and prosperity.  Those who trusted him in the beginning began a journey that years later seemed regrettably unstoppable until Germany lost the war.  Tyrants can be very benevolent and seemingly benign in the beginning.  In 1933, Germany had a choice. 

[knight22]

I suggest you read Hayek's Road to Serfdom.

Totalitarianism under the urge to follow a "strong" leader by steering the sheeps against a "common enemy" is not giving choice to the market.

Having the requirement in place that 75% of the miners have to agree with this change first is in fact giving the choice to the market, considering that the miners would most likely not implement such a change without the economic majority also being on board as well. Hayek also defined totalitarianism as the desire to organise the whole of society and attain a definite social goal, this is also certainly not the case with XT.

You completely and conveniently ignore what I'm saying.  This is a POSSIBLE PATH that could come about IN THE FUTURE.  So, saying that it isn't in XT today doesn't counter anything.  You are arguing with yourself.  Here, I'll agree with you...  "what could become the future is not true in the present."

What is factual is the relationship between these possibilities and the XT creator's past proposals.  In other words, it is based on what the "benevolent dictator" could do if he had enough control over Bitcoin clients and miner code. 

The question isn't whether you have free choice today to not install XT.  If you didn't, I wouldn't spend my time typing this.  It is whether you can lose that free choice by trusting future releases of XT loaded with its patches (e.g., blacklisting) and other protocol changes.

As a crude comparison, since you are hooked on the tyranny concept, Hitler didn't start out his political campaign with a proposal to exterminate people.  He started it with proposals the people wanted to hear... to restore Germany to its former glory and prosperity.  Those who trusted him in the beginning began a journey that years later seemed regrettably unstoppable until Germany lost the war.  Tyrants can be very benevolent and seemingly benign in the beginning.  In 1933, Germany had a choice. 

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Hitler political campaign was not an open source project... Or are you are saying that bitcoin can be controlled with the same kind of propaganda tactics?

[Peter R]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

[knight22]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

There real question is, how the free market will succeed at getting what it wants if Core devs are standing on its way?

I think a possible scenario could be an aggressive fork by major economic players leading the way and hoping for the best...

[Peter R]

There real question is, how the free market will succeed at getting what it wants if Core devs are standing on its way?

I think a possible scenario could be an aggressive fork by major economic players leading the way and hoping for the best...

It will be fascinating to watch the process unfold.  I'm not sure exactly how it will happen, but somehow the market will find a way to get bigger blocks.  

[Carlton Banks]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

Peter, your economic analysis is flawed, as it simply wishes away the external costs that the market may choose to impose on the users running their own node. The scaling solution needs to take account of this, and your proposed solutions as well as your analysis does not. Stop promoting faulty ideas (economic and technical alike).  

[knight22]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

Peter, your economic analysis is flawed, as it simply wishes away the external costs that the market may choose to impose on the users running their own node. The scaling solution needs to take account of this, and your proposed solutions as well as your analysis does not. Stop promoting faulty ideas (economic and technical alike).  

What Peter propose makes a lot of sense economically as the market will want that deadweight loss regardless of the nodes but I get your point that it does not take security into consideration.

Are you suggesting the anti spam measure should take into consideration the number of nodes in the network? It might make sense to make a rule that enforce the market to have a minimum number of nodes in order to let the blocksize grow. The market will have an economic incentive to have a minimum amount of nodes in order to get that deadweight loss.
However, what's the minimum of node should realistically be enough to consider bitcoin secure enough? How much blocksize growth should it let if the conditions are met? How do you get the balance between the acceptable amount of deadweight loss VS the acceptable amount of nodes?

[brg444]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

Peter, your economic analysis is flawed, as it simply wishes away the external costs that the market may choose to impose on the users running their own node. The scaling solution needs to take account of this, and your proposed solutions as well as your analysis does not. Stop promoting faulty ideas (economic and technical alike).  

What Peter propose makes a lot of sense economically as the market will want that dead loss regardless of the nodes but I get your point that it does not take security in consideration.

Are you suggesting the anti spam measure should take into consideration the number of nodes in the network? It might make sense to make a rule that enforce the market to have a minimum number of nodes in order to let the blocksize grow. The market will have an economic incentive to have a minimum amount of nodes in order to get that dead loss.
However, what's the minimum of node should realistically be enough to consider bitcoin secure enough? How much blocksize growth should it let if the conditions are met? How do you get the balance between the acceptable amount of dead loss VS the acceptable amount of nodes?

The number of nodes is irrelevant.

The block size limit should be a measure of the cost of the option to create a full node

http://www.truthcoin.info/blog/measuring-decentralization

[knight22]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

Peter, your economic analysis is flawed, as it simply wishes away the external costs that the market may choose to impose on the users running their own node. The scaling solution needs to take account of this, and your proposed solutions as well as your analysis does not. Stop promoting faulty ideas (economic and technical alike).  

What Peter propose makes a lot of sense economically as the market will want that dead loss regardless of the nodes but I get your point that it does not take security in consideration.

Are you suggesting the anti spam measure should take into consideration the number of nodes in the network? It might make sense to make a rule that enforce the market to have a minimum number of nodes in order to let the blocksize grow. The market will have an economic incentive to have a minimum amount of nodes in order to get that dead loss.
However, what's the minimum of node should realistically be enough to consider bitcoin secure enough? How much blocksize growth should it let if the conditions are met? How do you get the balance between the acceptable amount of dead loss VS the acceptable amount of nodes?

The number of nodes is irrelevant.

The block size limit should be a measure of the cost of the option to create a full node

Cost is relative. It might be cheap for you but not for me. I also don't think it would be possible to enforce it into the protocol.

[brg444]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

Peter, your economic analysis is flawed, as it simply wishes away the external costs that the market may choose to impose on the users running their own node. The scaling solution needs to take account of this, and your proposed solutions as well as your analysis does not. Stop promoting faulty ideas (economic and technical alike).  

What Peter propose makes a lot of sense economically as the market will want that dead loss regardless of the nodes but I get your point that it does not take security in consideration.

Are you suggesting the anti spam measure should take into consideration the number of nodes in the network? It might make sense to make a rule that enforce the market to have a minimum number of nodes in order to let the blocksize grow. The market will have an economic incentive to have a minimum amount of nodes in order to get that dead loss.
However, what's the minimum of node should realistically be enough to consider bitcoin secure enough? How much blocksize growth should it let if the conditions are met? How do you get the balance between the acceptable amount of dead loss VS the acceptable amount of nodes?

The number of nodes is irrelevant.

The block size limit should be a measure of the cost of the option to create a full node

Cost is relative. It might be cheap for you but not for me. I also don't think it would be possible to enforce it into the protocol.

"Nigga what?"

Cost is cost. Let's call it a price if you fancy it doesn't matter.

Of course it is possible. Satoshi did it for the monetary supply, the block interval and the space in blocks. All of these are enforced today by what of the Nakamoto consensus protocol. None of these rules will change unless the economic majority agrees to it.

[Peter R]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

Peter, your economic analysis is flawed, as it simply wishes away the external costs that the market may choose to impose on the users running their own node. The scaling solution needs to take account of this, and your proposed solutions as well as your analysis does not. Stop promoting faulty ideas (economic and technical alike).  

I'm not asking what scaling solution is best.  I'm asking the question: if the market wants to be at Q* but the production quota forces it to be at Qmax, who exactly will enforce the quota (especially over the long term as forking pressure builds)?  

Normally, the answer is "the government" (or some powerful organization).  But something like Bitcoin is governed by the market itself, is it not?  How can the market enforce a quota that the market itself does not want?  Well, I don't think it can.    

There's a subtlety here: is the "thing" that will enforce the quota necessarily the same "thing" that wants to break the quota?  The answer is not completely clear to me...

[knight22]

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

Peter, your economic analysis is flawed, as it simply wishes away the external costs that the market may choose to impose on the users running their own node. The scaling solution needs to take account of this, and your proposed solutions as well as your analysis does not. Stop promoting faulty ideas (economic and technical alike).  

What Peter propose makes a lot of sense economically as the market will want that dead loss regardless of the nodes but I get your point that it does not take security in consideration.

Are you suggesting the anti spam measure should take into consideration the number of nodes in the network? It might make sense to make a rule that enforce the market to have a minimum number of nodes in order to let the blocksize grow. The market will have an economic incentive to have a minimum amount of nodes in order to get that dead loss.
However, what's the minimum of node should realistically be enough to consider bitcoin secure enough? How much blocksize growth should it let if the conditions are met? How do you get the balance between the acceptable amount of dead loss VS the acceptable amount of nodes?

The number of nodes is irrelevant.

The block size limit should be a measure of the cost of the option to create a full node

Cost is relative. It might be cheap for you but not for me. I also don't think it would be possible to enforce it into the protocol.

"Nigga what?"

Cost is cost. Let's call it a price if you fancy it doesn't matter.

Of course it is possible. Satoshi did it for the monetary supply, the block interval and the space in blocks. All of these are enforced today by what of the Nakamoto consensus protocol. None of these rules will change unless the economic majority agrees to it.

You are mistaken, cost is relative to A LOT of factors. Just a cost (number) is irrelevant. What matters is the purchasing power of those numbers which I see no way for the protocol to evaluate. The same reason why Satoshi choose a fixed supply because it can't be adjusted to the demand.

Both are external factors the protocol can't evaluate. Secondly, are you also suggesting the protocol should be dependent of governments  fiat?