Topic: ToominCoin aka "Bitcoin_Classic" #R3KT - page 86. (Read 157137 times)

The technology is amazing I agree, it solves many older political problems I entirely agree, like tyranny of the majority for instance, maybe not under your conception of Bitcoin but certainly under my conception. This problem however regarding consensus lies within human nature, culture and free will. These things are not changed by Bitcoin, which means they are also not problems/dynamics that are solved by Bitcoin.

I do agree on this conception of consensus, that it is how Bitcoin works, However with my conception of Bitcoin, when an issue becomes contentious, consensus in the literal meaning is lost, if no compromise is found this is expressed through a split and or a loss of confidence precipitating in an exodus to alternative cryptocurrencies. I embrace this governance mechanism as an expression of freedom and the right to our own self determination.

heh, exactly


edit: altho not that consensus is not being achieved right before your eyes and every new block, just good luck indeed changing it.. ^^

Yeah, lots of luck with that achieving true consensus among millions of people.

In the history of the world this has never been achieved, if true consensus was possible amongst large groups of people, politics would cease to be real subject of study. Obviously such a position is completely unrealistic.

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.

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

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

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.

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.

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.

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) ?

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.

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/

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

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.

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.

Uh? No.

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

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 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.

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.

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

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.

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.

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

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/

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.

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.

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.

Why would they have something against a soft fork?

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.

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.

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.

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.

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 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.

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.

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.

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.

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

Right inb4 16nm Bitfury.

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.

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.

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.

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).

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

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

It does seem like it.