ToominCoin aka "Bitcoin_Classic" #R3KT

[Sir Lagsalot]

Your position is that a HF by the Classic team is preferable to a SF by the Core team, is it not?

I think this is a oversimplification of my position, my preferred implementation is actually Bitcoin Unlimited, which is still compatible with any of the changes within Classic though.

Bitcoin Unlimited is an even smashier trainwreck than XT or Classic by any metric which matters; node count, adoption, user or developer support. This is not some Disney movie where supporting the plucky underdog leads to some heartwarming ending. Bitcoin is a crucible in which bad ideas are quickly revealed and rejected. By supporting demonstrably failed ideas, you become a hindrance and timewaster. Present fresh alternative ideas if you're so determined to play devil's advocate.

One doesn't even need to get into the various technical reasons why this is a foolish position, the risk-reward alone makes it an obvious call. In the worst case of SegWit leading to unexpected problems, those who upgraded can simply roll back. There's no rolling back the damage from a contentious HF, that would be a long and painful process in which altcoins are liable to overtake Bitcoin. This is why certain altcoins are invested in promoting just such an occurence.

I am certain that if we do not scale Bitcoin directly altcoins and chain forks of Bitcoin will overtake it. It is simple economics really, Bitcoin needs to be able to compete.

So only a hardfork can save us from inevitable doom, comparative risks and rewards be damned? And you base this assertion on nothing but your own certainty? Misguided zealotry.

If you can't acknowledge the simple reality that Classic has failed due it being a less credible, useful and valuable plan than Bitcoin's roadmap, there seems little point in further engagement.

I do not think classic has failed, it is about the freedom of choice, and the Core node count is steadily dwindling I would call that progress.

Well if falling node counts are what you call progress, then no wonder you support datacentre-only gigablox. By this measure, XT and Unlimited are leading the field, down to about 100 and 54 nodes respectively.

The market has spoken unequivocally and you're only wasting your time by arguing with it and people in this thread.

People that think discussion is a waste of time are often not right, considering they are not allowing their beliefs to be tested, and are not contributing to the market place of ideas.

Endless and increasingly heated talk gets us nowhere. Miners and developers have reached consensus on the way forward and the market clearly approves. What you might think of this situation is of little interest to anyone else.

If you're so convinced Bitcoin is on the wrong path, then like I say, present a better alternative. If it's truly better, it will be adopted.

A better alternative already exists, Satoshi Nakamoto already had a solution to scaling, which is to increase the blocksize. Even back then Satoshi had its critics to this method of scaling to which he replied.

https://bitcointalk.org/index.php?topic=532.msg6306#msg6306

I believe Lauda already requested that you stop quoting Satoshi out of context and I would echo this. Nothing said there supports your position, in fact you just shot yourself in the foot. Satoshi correctly predicted that mining would go to big server farms (albeit with ASIC hardware) but with advancements like SegWit, pruning and sidechains on the horizon, there's still space for validating nodes between light wallet users and miners. But more germane is Satoshi's envisioned solution for fast microtransactions, which he [ DO NOT POST SESC LINKS ]links[/url] to:

"I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less."

Surely Satoshi would be happy with the faster, cheaper, safer and more decentalised version of this, ie. the Lightning Network. His quote demonstrates that it was known since at least 2010 that, rather than blocksize increases, additional layers were the best solution to processing many small, quick transactions.

[1714515038]

1714515038

[1714515038]

1714515038

[BlindMayorBitcorn]

I don't know when exactly we all turned into a bunch of paranoid loons. But it isn't helping.

That's one of the tactics used by whoever is doing this. I've made a thread about a good article.

I read the article and it seemed to prove my point. Now everybody thinks everybody else is a sock pushing an agenda.

alpaca sock puppets as far as the eye can see.

Behold! Here sits your inside-man. Insidious, flip-flopping, a poison to the community. Shun him. Notice the lean and hungry look, the squinty eyes, the cheap shirt. Learn the signs. Such men are dangerous.

[YarkoL]

Well if falling node counts are what you call progress, then no wonder you support datacentre-only gigablox. By this measure, XT and Unlimited are leading the field, down to about 100 and 54 nodes respectively.

You conveniently forget all 1054 "ToominCoin-aka-"Bitcoin_Classic"-#R3KT" nodes

XT is history, but BU is about to have a new release with Xtreme Thinblocks and
broadcast block acceptance settings.
We'll probably see an update in the metrics then.

[Lauda]

First of all because of the complexity of Segwit agreement will be difficult to find, in principle I do actually like SegWit I would like to see it implemented.
-snip-

It don't see the problem here. Opting to implement it via a SF or HF is just preference, and the Core developers do not like HF's (for various reasons). I think that Segwit is receiving adequate testing. It is not as complex as you think.

Whether you agree with it or not the big blockist consider the current situation to be hurting adoption and dire if there is a sudden spike in transaction volume, keep in mind that some small blocksist want the blocks to be full in general and the big blockists consider this to be undesirable, try and appreciate the other sides perspective that way it will be more likely that we will be able to reach a good compromise.

But you can't push a HF like Classic proposes, those rules make it controversial. Even Garzik suggests a 3 to 6 month minimum grace period. Even if everyone was on-board with it by April, that would mean it would get deployed sometime in Q3. Segwit would already given us more breathing room by then.

Segwit also just does not achieve enough of a throughput to be a satisfactory compromise, considering there is also much disagreement over how much of a throughput benefit Segwit will give has also been debated, since it also relies on the speed of adoption of those transaction types. This is just another example why a blocksize increase to two megabytes is a much simpler solution that everyone can agree with and be happy with for now.

But it does. The main difference that Segwit does not provide instantly a capacity increase, it grows over time. If the users/services really wanted it they'd adopt it as soon as possible.

However for now we can at least both agree that two megabytes is possible, it is something that both sides can agree with. Which means we can continue without a split. This is important, I do not think it is worth endangering this possible peace because of the preference of deploying segwit first by the small blockist camp.

See this is where the understanding is wrong. You think 2 MB block size limit would be a compromise, but it is not. Anything higher is currently deemed as unsafe, even 2 MB blocks would be if there was not that workaround by Gavin (for Classic).

Specifically cost and I would argue censorship resistance and decentralization, however I know you would disagree on these last two points, which we can with this narrative of both visions existing together.

With cost I can agree (albeit many tend to be hyperbolic when it comes to actual number), but I disagree with the other two.

I think adoption is important for increasing the node count which relates back to the blocksize, I realize this is a push and pull relationship but this is how I perceive it and why I think increasing the blocksize is what is best for decentralization.

Again, let's leave it at 'we don't have the data to prove this'.

May I dare say it we are actually having a more civil discussion here.

It does seem like it.

[hdbuck]

In a way I agree with him. So, if devs and big companies in the space can decide to change the core code won't that be the same as central banks control over currency?

No. They can't force their code to the participants of the network. It also has to have great support from the miners who obviously won't risk changes without consensus. This is not really comparable to 'control over a currency'.

That's akin to saying the US government and Fed can't force the dollar on the citizens. It is true, US citizens can trade in whatever they want. However, that doesn't mitigate the fact that the dollar is centrally controlled by the US government and Fed.

Similarly, bitcoin is controlled by a small group of Chinese miners and core devs, as the recent meeting where a complete fork of the blockchain was determined clearly shows. A small group of people centrally control the entire thing.

The fact that bitcoin is centrally controlled is actually a good thing for bitcoin. There exists a group that can determine what changes to make going forward. If a hard limit on the number of bitcoins isn't workable because it doesn't make enough for the miners, the cap could be lifted. If mining inflation is too low, it could be increased, etc. Any changes to the spec that needs to be made can be made, regardless of user consensus.

The fact that the vast majority of mining power is comprised of Chinese companies and the fact that China's government is completely corrupt is not a good thing. Tomorrow, each of those Chinese bitcoin miners could disappear and a state controlled operator could silently appear in their place. It happens all the time.

People are being overly concerned and paranoid about "too many" chinese mining operations. In 5-10 years concentrated mining in china will be a distant memory, another interesting quirk from bitcoin's mining development history like the video gamers and their GPUS of 2011.

Chinese miners are to become increasingly obsolete, especially with the halvings and the pursue of more efficient chips.

Right inb4 16nm Bitfury.

[VeritasSapere]

First of all because of the complexity of Segwit agreement will be difficult to find, in principle I do actually like SegWit I would like to see it implemented.
-snip-

It don't see the problem here. Opting to implement it via a SF or HF is just preference, and the Core developers do not like HF's (for various reasons). I think that Segwit is receiving adequate testing. It is not as complex as you think.

The big block camp do not like SF for various reasons maybe it is a preference that should be considered when attempting to build consensus.

Whether you agree with it or not the big blockist consider the current situation to be hurting adoption and dire if there is a sudden spike in transaction volume, keep in mind that some small blocksist want the blocks to be full in general and the big blockists consider this to be undesirable, try and appreciate the other sides perspective that way it will be more likely that we will be able to reach a good compromise.

But you can't push a HF like Classic proposes, those rules make it controversial. Even Garzik suggests a 3 to 6 month minimum grace period. Even if everyone was on-board with it by April, that would mean it would get deployed sometime in Q3. Segwit would already given us more breathing room by then.

Then what Core should do is announce a HF increase in 3 months from now today, that would resolve the situation, I suppose both options are contentious now, both the segwit SF and the blocksize increase HF. I have always said that consensus in the true meaning of the word is impossible, which is why sometimes the only way forward could be contentiousness, the question has to be asked which choice is maybe less contentious. Everything considered I would argue that HF blocksize increase is less contentous if carried out by Core, something at least both sides can agree with, unlike segwit.

However for now we can at least both agree that two megabytes is possible, it is something that both sides can agree with. Which means we can continue without a split. This is important, I do not think it is worth endangering this possible peace because of the preference of deploying segwit first by the small blockist camp.

See this is where the understanding is wrong. You think 2 MB block size limit would be a compromise, but it is not. Anything higher is currently deemed as unsafe, even 2 MB blocks would be if there was not that workaround by Gavin (for Classic).

This is where we disagree obviously, I even think eight megabyte blocks are safe. It is a compromise in the true meaning of the word because we are both on the edge of what we both consider to be acceptable.

Specifically cost and I would argue censorship resistance and decentralization, however I know you would disagree on these last two points, which we can with this narrative of both visions existing together.

With cost I can agree (albeit many tend to be hyperbolic when it comes to actual number), but I disagree with the other two.

I figured you would have, but that is alright. With the narrative I have constructed here these two opposing visions of Bitcoin can still live side by side for a while longer.

I think adoption is important for increasing the node count which relates back to the blocksize, I realize this is a push and pull relationship but this is how I perceive it and why I think increasing the blocksize is what is best for decentralization.

Again, let's leave it at 'we don't have the data to prove this'.

Agreed, just explaining my position so that you can understand where I am coming from, by understanding the other side we will more likely be able to reach compromise.

May I dare say it we are actually having a more civil discussion here.

It does seem like it.

Finding common ground, agreeing on some basic principles. With my last post I was trying to give you a insight into the big blockist mentality, a split is not good for either side, however if Core or its supporters are unable to compromise then I suspect a split might become inevitable. I have shown a way here that both visions can live side by side for a while longer hopefully until time shows us what the superior path really is.

[Lauda]

The big block camp do not like SF for various reasons maybe it is a preference that should be considered when attempting to build consensus.

Why would they have something against a soft fork?

]Then what Core should do is announce a HF increase in 3 months from now today, that would resolve the situation, I suppose both options are contentious now, both the segwit SF and the blocksize increase HF. I have always said that consensus in the true meaning of the word is impossible, which is why sometimes the only way forward could be contentiousness, the question has to be asked which choice is maybe less contentious. Everything considered I would argue that HF blocksize increase is less contentous if carried out by Core, something at least both sides can agree with, unlike segwit.

This is not exactly how the process goes. Even if we had a ready proposal and implementation right now you'd have to wait for the miners to activate it and then the grace period would start. Even if we started this process right now and picked a small grace period (3 months), it would still not be activated before the halving.

This is where we disagree obviously, I even think eight megabyte blocks are safe.

We can't 'agree to disagree' when facts are involved. Some example problems: It is a fact that at 2 MB a transaction can be constructed that would take too long to validate; propagation delay at larger sizes, orphans. Classic only works because Gavin applied a workaround (limitation that prevents the problem). This is not a solution(!). Segwit proves a 'solution' to this problem and scales down the validation time (making it linear IIRC). If you would just accept this as a reasonable person (because these are undeniable facts), then we might gain a lot more common ground.

Finding common ground, agreeing on some basic principles. With my last post I was trying to give you a insight into the big blockist mentality, a split is not good for either side, however if Core or its supporters are unable to compromise then I suspect a split might become inevitable. I have shown a way here that both visions can live side by side for a while longer hopefully until time shows us what the superior path really is.

This is one of the main reasons for which I'm against Classic. 75% is not consensus regardless of theories (and comparisons to old systems), it is a split. If 25% of the users leave the current system (at once) due to 'no compromise', it is also network split (per definition). I definitely agree that this should be avoided.

[VeritasSapere]

The big block camp do not like SF for various reasons maybe it is a preference that should be considered when attempting to build consensus.

Why would they have something against a soft fork?

I have explained this before, I think hard forks are preferable because they give people more freedom of choice. With a hard fork you can choose to stay behind, what you see as a disadvantage of a hard fork I actually see as an advantage. Hard forks are an important governance mechanism which ensure the continued freedom of the protocol. Hard forks should be hard and I do not think making the same changes with a soft fork is better, exactly because it does not give people that choice.

Hard forks are a voting mechanic in Bitcoin, carrieng out a soft fork essentially in part bypasses this vote. Consensus should be tested. Soft forks can also be used to change the blocksize and increase the supply of Bitcoin. It is something I think we should be wary of and not to be taken lightly. You could say I have political reosons to support a hard fork instead. I also believe the code would be cleaner with a hard fork while keeping it more easy to create alternative implementations as well. I could do an extensive wright up about this, I really have a lot to say on this subject, however instead here is a reddit page that expresses this sentiment well:

https://www.reddit.com/r/btc/comments/40arwh/you_should_realise_that_anything_can_be_changed/

Soft forks quash the minority voice. Hard forks allow it to persist.

Then what Core should do is announce a HF increase in 3 months from now today, that would resolve the situation, I suppose both options are contentious now, both the segwit SF and the blocksize increase HF. I have always said that consensus in the true meaning of the word is impossible, which is why sometimes the only way forward could be contentiousness, the question has to be asked which choice is maybe less contentious. Everything considered I would argue that HF blocksize increase is less contentous if carried out by Core, something at least both sides can agree with, unlike segwit.

This is not exactly how the process goes. Even if we had a ready proposal and implementation right now you'd have to wait for the miners to activate it and then the grace period would start. Even if we started this process right now and picked a small grace period (3 months), it would still not be activated before the halving.

Well what can I say we are in this position now because of the stalling of Core, we have run out of time for a timely blocksize increase, I think a two week grace period is fine myself, though in the spirit of compromise we could just make it a one and half month grace period? If we have a huge spike in transaction volume a rushed blocksize increase might even become necessary, we have been pushing for a blocksize increase for a long time now, so you can not say that we did not warn you.

This is where we disagree obviously, I even think eight megabyte blocks are safe.

We can't 'agree to disagree' when facts are involved. Some example problems: It is a fact that at 2 MB a transaction can be constructed that would take too long to validate; propagation delay at larger sizes, orphans. Classic only works because Gavin applied a workaround (limitation that prevents the problem). This is not a solution(!). Segwit proves a 'solution' to this problem and scales down the validation time (making it linear IIRC). If you would just accept this as a reasonable person (because these are undeniable facts), then we might gain a lot more common ground.

One of the nice things here is that we do not need to agree on eight megabytes, if we can just agree on two megabytes then we have compromise for now, that is what matters, I consider that fairly reasonable.

Finding common ground, agreeing on some basic principles. With my last post I was trying to give you a insight into the big blockist mentality, a split is not good for either side, however if Core or its supporters are unable to compromise then I suspect a split might become inevitable. I have shown a way here that both visions can live side by side for a while longer hopefully until time shows us what the superior path really is.

This is one of the main reasons for which I'm against Classic. 75% is not consensus regardless of theories (and comparisons to old systems), it is a split. If 25% of the users leave the current system (at once) due to 'no compromise', it is also network split (per definition). I definitely agree that this should be avoided.

I suppose I do not believe in consensus in the literal meaning of the word, my expertise is actually in political philosophy more specifically so I like to think that I know what I am talking about when it comes to this subject at least. I would argue that a split is better then the tyranny of the twenty five percent. Personally I consider this a graceful solution that both solves the problem of tyranny of the majority and minority. I do not see any other way to get around this problem. The only way that I see us avoiding a split at this point is if either Core or its supporters are willing to compromise with a two megabyte blocksize increase first. If you think it is worth splitting Bitcoin over this disagreement then continue the course, though you should realize that compromise with the other side is possible in the way that I have described it.

[bargainbin]

"And so begins the twelfth year of my idiotic war. The pain of it! The stupidity!"--Brainyquote.com

[Lauda]

Soft forks can also be used to change the blocksize and increase the supply of Bitcoin.

I'd like to see evidence of this. I'm not finding the evidence in the link though.

I think a two week grace period is fine myself, though in the spirit of compromise we could just make it a one and half month grace period?

Personal opinions are not really relevant here. There was an emergency hard fork in 2013 and that caused losses. What makes you think that such a short period would not? One month and a half is not a compromise. From what I understood the people in Core are in favor of 6 to 12 months, Garzik is recommending 3 to 6 months. The only one here who wants something shorter is Gavin (he even refused to listen to the miners). Three months could be seen a a big compromise.

One of the nice things here is that we do not need to agree on eight megabytes, if we can just agree on two megabytes then we have compromise for now, that is what matters, I consider that fairly reasonable.

Actually it matters a lot. It matters if you are willing to accept the facts that are presented on the table. If you aren't, then I'm wasting time. I've commented on 2 MB block size limit in the past. If Segwit was not behind the corner, and the validation problem was fixed properly then I would be in favor of a 2 MB block size limit.

[VeritasSapere]

Soft forks can also be used to change the blocksize and increase the supply of Bitcoin.

I'd like to see evidence of this. I'm not finding the evidence in the link though.

I am not a programmer as you know, but it is simple really, nodes that follow the old rules will simply just not be able to participate fully anymore just like they do under a segwit SF. This can not happen for an increase in the supply of Bitcoin because of the game theory involved, however I pointed this out just to illustrate and make a point.

I think a two week grace period is fine myself, though in the spirit of compromise we could just make it a one and half month grace period?

Personal opinions are not really relevant here. There was an emergency hard fork in 2013 and that caused losses. What makes you think that such a short period would not? One month and a half is not a compromise. From what I understood the people in Core are in favor of 6 to 12 months, Garzik is recommending 3 to 6 months. The only one here who wants something shorter is Gavin (he even refused to listen to the miners). Three months could be seen a a big compromise.

I said two weeks, you said three months, then I said one month and half, that is a compromise, if it is not then you do not know what a compromise is.

One of the nice things here is that we do not need to agree on eight megabytes, if we can just agree on two megabytes then we have compromise for now, that is what matters, I consider that fairly reasonable.

Actually it matters a lot. It matters if you are willing to accept the facts that are presented on the table. If you aren't, then I'm wasting time. I've commented on 2 MB block size limit in the past. If Segwit was not behind the corner, and the validation problem was fixed properly then I would be in favor of a 2 MB block size limit.

I have to agree with everything you say, and if I do not then it is a waste of time? That is not the case at all, the whole point of this narrative that I am constructing here is that we can disagree on certain points yet we can still cooperate through compromise. We can disagree on the viability of eight megabytes that is fine, however if we can agree on a two megabyte compromise then that is all that really matters, in practical terms.

[brg444]

Chinese miners are to become increasingly obsolete, especially with the halvings and the pursue of more efficient chips.

Right inb4 16nm Bitfury.

Uh? No.

I usually agree with you but silicon fabs & subsidized electricity are not moving out of China anytime soon...

[Lauda]

This can not happen for an increase in the supply of Bitcoin because of the game theory involved, however I pointed this out just to illustrate and make a point.

A lot of things can be changed via a SF, but I don't think the supply is one of them.

I said two weeks, you said three months, then I said one month and half, that is a compromise, if it is not then you do not know what a compromise is.

No. I didn't not say three months. I was using that as an example basing on what Garzik said. Actually, I'm uncertain of 6 months being adequate. I'd have to spend more time thinking about it.

I have to agree with everything you say, and if I do not then it is a waste of time? That is not the case at all, the whole point of this narrative that I am constructing here is that we can disagree on certain points yet we can still cooperate through compromise. We can disagree on the viability of eight megabytes that is fine, however if we can agree on a two megabyte compromise then that is all that really matters, in practical terms.

Not at all. Validation time is quadratic. This is a fact and thus proves my first point; propagation delay and orphans become worse with more data. This is also a fact (as they certainly do not get better). We can't "agree to disagree" on facts. Either it is A or it is B, it can't be both. These things are not in a superposition. If you are unable to agree with facts (!= my opinions), then I am indeed wasting my time here.

[VeritasSapere]

I have to agree with everything you say, and if I do not then it is a waste of time? That is not the case at all, the whole point of this narrative that I am constructing here is that we can disagree on certain points yet we can still cooperate through compromise. We can disagree on the viability of eight megabytes that is fine, however if we can agree on a two megabyte compromise then that is all that really matters, in practical terms.

Not at all. Validation time is quadratic. This is a fact and thus proves my first point; propagation delay and orphans become worse with more data. This is also a fact (as they certainly do not get better). We can't "agree to disagree" on facts. Either it is A or it is B, it can't be both. These things are not in a superposition. If you are unable to agree with facts (!= my opinions), then I am indeed wasting my time here.

I do not think you get my point, it does not matter what we both believe or think, as long as we can both simply just agree to a two megabyte blocksize increase.

In regards to propagation times you might want to look at the Bitcoin Unlimited Xthin blocks proposal, which actually solves the problem of propagation times at least with the blocksizes that we are talking about, Xthin blocks actually have the potential to speed up block propagation up to one hundred times compared to today, which for all intents and purpose does solve this problem of block propagation. I think it should be implemented in all of the clients once it is finished, if the other clients do not implement it there will be serous advantages to the miners using Bitcoin Unlimited instead, since it increases block propagation far more then the relay network ever did, in a decentralized manner even.

https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/

[Lauda]

I do not think you get my point, it does not matter what we both believe or think, as long as we can both simply just agree to a two megabyte blocksize increase.

That's something like: Me telling you to look at a painting (which is black) and you telling me that it is white. Then you proceed to tell me that it does not matter as long as we agree that it is grey Do you or do you not agree with the presented problems:
1) Validation time quadratic = already problematic at 2 MB block size limit
2) Propagation delay worse at bigger sizes
3) Orphan rate higher at bigger sizes (due to lack of infrastructural improvements) ?

In regards to propagation times you might want to look at the Bitcoin Unlimited Xthin blocks proposal..

Seems to me like another stolen idea here. However, I'll look into it once I have time. I doubt that someone would use it to mine without 3rd party approval. Regardless, it is not finished yet.

[VeritasSapere]

I do not think you get my point, it does not matter what we both believe or think, as long as we can both simply just agree to a two megabyte blocksize increase.

That's something like: Me telling you to look at a painting (which is black) and you telling me that it is white. Then you proceed to tell me that it does not matter as long as we agree that it is grey Do you or do you not agree with the presented problems:
1) Validation time quadratic = already problematic at 2 MB block size limit
2) Propagation delay worse at bigger sizes
3) Orphan rate higher at bigger sizes (due to lack of infrastructural improvements) ?

Do you want to find compromise or not? It really is quite simple, before you said that two megabytes is safe and fine, either it is, or it is not. I am saying that we can all simply just agree to a two megabyte blocksize regardless of what else either one of us believes, as long as we think that two megabytes is safe and doable. This would provide a solution to the current impasse since it would be a solution that both sides can be happy with for now. The other alternative is that a split occurs, because I can tell you now that the present Core road map is completely untenable for the big blocks camp.

[Lauda]

Do you want to find compromise or not? It really is quite simple, before you said that two megabytes is safe and fine, either it is, or it is not. I am saying that we can all simply just agree to a two megabyte blocksize regardless of what else either one of us believes, as long as we think that two megabytes is safe and doable. This would provide a solution to the current impasse since it would be a solution that both sides can be happy with for now. The other alternative is that a split occurs, because I can tell you now that the present Core road map is completely untenable for the big blocks camp.

What are you trying to do here? Make me admit to a 2 MB compromise but leave the false statements at 'it doesn't matter what either one of us believes'? That I'm not willing to do. I'm not willing to reach an end to the discussion when some of your beliefs are very wrong (e.g. 8 MB blocks are viable right now). How about you start addressing those 3 points? Once we're past that then we will see.

[VeritasSapere]

Do you want to find compromise or not? It really is quite simple, before you said that two megabytes is safe and fine, either it is, or it is not. I am saying that we can all simply just agree to a two megabyte blocksize regardless of what else either one of us believes, as long as we think that two megabytes is safe and doable. This would provide a solution to the current impasse since it would be a solution that both sides can be happy with for now. The other alternative is that a split occurs, because I can tell you now that the present Core road map is completely untenable for the big blocks camp.

What are you trying to do here? Make me admit to a 2 MB compromise but leave the false statements at 'it doesn't matter what either one of us believes'? That I'm not willing to do. I'm not willing to reach an end to the discussion when some of your beliefs are very wrong (e.g. 8 MB blocks are viable right now). How about you start addressing those 3 points? Once we're past that then we will see.

You still do not get it, we can disagree on these three points that is fine, I have already discussed these points ad nauseam so you should already know what my position is on these three points since we have even discussed this together previously on different threads.

I am really starting to think that you do not know what a compromise means. Again it does not matter if I think eight megabytes blocks are viable and you do not, it does not matter for this compromise. All that matters is that we both can simply agree to a two megabyte blocksize limit. You know find common ground, instead of focusing on what divides us.

The point of my peaceful cooperative narrative is that we recognize that we have opposing even contradictory visions for the future of Bitcoin. But that both visions can actually still live side by side within the same cryptocurrency, hopefully for long enough so that time can actually prove to both camps what the best solution really is. Considering my comments on preserving the low cost of layer one being critical for the continued viability of the big blockist vision, is why an agreement to a simple bump up to two megabytes is so crucially important for the big blockists, it is absolutely critical for any meaningful type of compromise.

[hdbuck]

Do you want to find compromise or not? It really is quite simple, before you said that two megabytes is safe and fine, either it is, or it is not. I am saying that we can all simply just agree to a two megabyte blocksize regardless of what else either one of us believes, as long as we think that two megabytes is safe and doable. This would provide a solution to the current impasse since it would be a solution that both sides can be happy with for now. The other alternative is that a split occurs, because I can tell you now that the present Core road map is completely untenable for the big blocks camp.

What are you trying to do here? Make me admit to a 2 MB compromise but leave the false statements at 'it doesn't matter what either one of us believes'? That I'm not willing to do. I'm not willing to reach an end to the discussion when some of your beliefs are very wrong (e.g. 8 MB blocks are viable right now). How about you start addressing those 3 points? Once we're past that then we will see.

You still do not get it, we can disagree on these three points that is fine, I have already discussed these points ad nauseam so you should already know what my position is on these three points since we have even discussed this together previously on different threads.

I am really starting to think that you do not know what a compromise means. Again it does not matter if I think eight megabytes blocks are viable and you do not, it does not matter for this compromise. All that matters is that we both can simply agree to a two megabyte blocksize limit. You know find common ground, instead of focusing on what divides us.

meh bitcoin is not a compromise, sry but it is a consensus.

we are not dealing rugs here, so no, you wont 'compromise' bitcoin.

[Lauda]

I am really starting to think that you do not know what a compromise means. Again it does not matter if I think eight megabytes blocks are viable and you do not, it does not matter for this compromise. All that matters is that we both can simply agree to a two megabyte blocksize limit. You know find common ground, instead of focusing on what divides us.

Well I've had enough of this talk. You can't persuade me to compromise in this way. This is not how my mind works and attempts are futile. Good luck though, it will work on a lot of people (especially on /r/btc). I remain in support of Segwit for now (it should be released within 2 months anyways).
I suggest not answering to this post since I already suspect what the answer is going to look like.