Topic: bitcoin "unlimited" seeks review - page 5. (Read 16106 times)

It is entirely obvious the MO of Unlimited.

1)  Create chaos.  By having all kinds of forks and "emergent" consensus, no one will know what to trust, and the network becomes useless and untrustworthy.

2)  Distract development on Bitcoin.  Any time spent having to refute this nonsense is time that could be spent on other tasks that are actually useful.

3)  Find new suckers.  The "Trump" effect.  Appeal to the lowest common denominator for those without critical thinking skills, develop a following, then use it as a fundraising attempt.  Just wait - they will be begging for money from their "government" as taxes and use it to fund themselves.

It's fairly obvious that this is an unworkable idea that will result in very bad things for anyone who uses it.  Give a warning for such users, and anyone stupid enough to follow these fools off a cliff without a parachute can suffer the consequences.

They do in fact have a track record. Various economic- and incentive-related decisions have been made in Bitcoin development over the past 6 years and it hasn't completely blown up yet. That includes both changes and decisions about what not to change.

I guess this conclusion depends in part on how big a failure you think the "blocksize debate" represents. From where I sit, the blockchain is still working, transactions are being processed, etc. I don't see a major failure even in that.

Both of these statements cannot be simultaneously true. Which one do you consider dominant?

I used to be an unqualified big blocker until I realized that big blocksize caps aren't necessarily any more "free market" than small blocksize caps. I was caught up with the "cap" thing, thinking low caps are market interventions. Well they are, but so are high caps. So the free market position must be elsewhere. The free market position to let the market decide the cap. See the image I posted above.

Now my position is that much bigger blocks are probably fine and the system will probably self-limit via mechanisms like orphaning, and that generally most of the small block arguments spring from a mistrust of markets... BUT that I shouldn't be the one to decide. I'd like to place my bet in a prediction market that, say, 50 MB would actually be fine right now, but if I were Core maintainer I definitely wouldn't want to put 50MB or even 10MB in the next release - for fear that I, a fallible human, could be wrong.

I wouldn't want anyone to have that power. I want the market to decide, and to do so unburdened by the interference of the hardcoded cap inserted by developers who - while absolutely excellent at what they do - have no track record as incentive designers, economic parameter setters, etc. And even if they did it wouldn't matter, the power would be too concentrated.

I'm for having Core be closer to a wallet, with any controversial consensus parameters left to the user. Users would not screw themselves over, just like a car driver doesn't turn on the emergency brake while cruising on the freeway. I know some people think they would, but as I keep saying, the inconvenience barrier isn't that high. It's plenty high enough to set a very strong Schelling point, though, which serves as a big market intervention. With multiple competing implementations to choose from, like XT, this intervention becomes weaker, but it is still highly suboptimal and in my opinion a security risk or at least a millstone slowing progress.


I think there is some interest in doing that. Generally I'm not that particular about what happens in any one implementation. If Core and XT would abdicate some power and give users leeway on consensus parameters that are controversial, that would be great. If BU is adopted, that would be fine, too. If someone forks BU and does something else with it, that would be cool as well. If btcd implements adjustable blocksize caps, I might use that.

From an adoption perspective, I think it likely that BU will try to incorporate whatever it can. I have even argued that opt-in RBF would be good to include, despite my disagreeing with it. My motto is,

"I find your settings despicable, sir, but I will defend to the death your right to set them."

I can't wait to see BU (fail to) deal with 16/32MB blocks trollishly construed so as to take hours or days to verify.  

BU doesn't need little old *me* to argue against it.  It's already been properly #R3KT by the socioeconomic majority, as expressed by the 99.9% of miners that support small blocks.

What you ridicule and denigrate as "1MB4EVA" is actually a beneficial outcome of Bitcoin's conservative/reactionary approach to preserving (at all costs) its fundamentally diffuse/diverse/defensible/resilient network.

1MB may change, should it prove to be an insurmountable impediment to growth or stubbornly problematic for maintaining status quo.

But "Z0MG I REALLY REALLY REALLY REALLY WANT TO!1!11!" isn't a good enough reason to pick some other magic number/algorithm, no matter how much you wish that constant to be changed Right Fucking Now.  Sorry, not tonight dear!

Must suck to be deep in the red on those BTC for which you paid $800.  

This is indeed a fundamental difference in viewpoints. I normally like this principle - https://en.wikipedia.org/wiki/Wisdom_of_the_crowd
but when determining complex code improvements I believe the WOTC tends to breakdown as it tends to work best when there is a definitive correct answer to a particular question (not within scaling decisions as there are complex tradeoffs and no single correct option) and social influence can make the WOTC extremely inaccurate.

I do think there are valid concerns being raised about governance, but I would warn you that direct democracy and groupthink can be very dangerous. Emergent consensus can decide upon a larger block because enough users demand it , but that doesn't mean it technically can work or scale efficiently. O(n2) is a real problem that so far only lightning network with larger blocksizes or treechains seem to adequately address.

I agree that having too few options is bad, but at the same time too many options is not optimal either. BU gives too many options for this, and there currently aren't just two options for the block size limit. There are several other BIPs out there with many different alternatives to this.

Part of the problem I have with BU is that I see it as a not-production-ready software. It doesn't having the proper testing (I couldn't find any), and it doesn't consider the all of the consequences. I think it should have been released when deployment options were available and some more options were there instead of just block size limit. There is much more than just the block size limit when it comes to deploying such a fork and not completely screwing up the network.

Everything controversial, yes, unless we want to vest inordinate power in whichever devs control the dominant implementation. That power concentration opens a major attack vector. I believe this hasn't been noticed before because there was never such a big controversy before. Who knows what the next big debate will be. Whatever it might be, realize that making the choices blockier (less granular) by trying to shoehorn people into one, two, or three possible implementations with bundled consensus parameters doesn't make the situation any better. The market will always choose the least bad option, but if there are only two options, say that offered by Core and that offered by XT, that's quite suboptimal and will lead to less satisfying results no matter what parameter we're talking about.

I think 60% is fine. Just kidding. Or am I? I say it doesn't matter what I think. The market will make the choice anyway. The only thing devs can do by locking the consensus parameters down in each implementation is force the market to make a less granular choice.

For example, if the market wants a 90% supermajority, and the options are Core at 98% and XT at 75%, maybe the market will be forced to go with 75%, which the market deems dangerously low but better than an impossible 98%, or it will be forced to go with 98%, causing a lot of unreasonable delay. 

Or maybe it's Core with 95% and a three-day grace period, and XT with 75% and a three-week grace period. Gotta choose the lesser of two evils, not a happy place to be.

When choices are not granular, consensus cannot find its optimum level. This is the kind of friction that can be removed by unbundling the consensus-parameter-setting service from the rest of the roles the devs play. The choices can even be among BIPs the devs offer, so it's not even anti-dev. If the market thinks devs know best, the market will go with a dev recommendation. If not, it will go with something else.


One doesn't have to pick sides. I respect all of the developers above and can have nuanced opinions and disagreements with individual aspects of their code contributions.