bitcoin "unlimited" seeks review

[Zangelbert Bingledack]

I personally believe XT's (and as suggested here BU) 75% threshold to be dangerously low as well. A 95% supermajority with a minimum 2 week grace period and alerts sent should be the default for hardforks.

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.

And small block adherents, imagine the reverse, if it were Mike and Gavin were running Core and Pieter, Wlad, and Maxwell had broken off and started their own implementation, with maybe Jeff going between. And people were sticking with Core and its giant block plan, heading for catastrophe. You might notice the market friction then.

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.

So do I. They all have great talents to contribute, and it pains me to see them have to be involved in a kind of power struggle because of the fact that they are being relied upon not just to recommend consensus parameters from among controversial choices, but to attempt to force them on users or at least spoonfeed them to users because they believe that they need to do so in order to generate consensus. I think some of them are unaware, or have not considered the fact that consensus can be emergent. I don't even think Gavin has fully internalized this, even though he did agree to the idea three years ago.

[1713399779]

1713399779

[1713399779]

1713399779

[1713399779]

1713399779

[1713399779]

1713399779

[smooth]

"We would be trying to predict what the market would decide, "

@Zangelbert Bingledack, I'm somewhat sympathetic to your cause but I don't really see how the market mechanism operates here, outside of a very broad definition of "market" which encompasses politics. Node voting doesn't work at all. Without that you are still reduced to politics and whoever shouts the loudest in trying to convince miners what block size they should use.

Well that's how it is anyway, and even now the market does decide. My point is that there's market friction in the inconvenience barrier of users not being able to set the blocksize cap themselves. That gives artificial solidity to the Schelling point set by Core (as well as the one set by XT). If Core is doing the correct thing, it shouldn't mind putting it to the market test more fully, by taking its finger off the scale.

How much is Core's finger really on the scale here? Well, for example, how many reasons are there to mistrust Mike Hearn? Some would say a lot. That means, as things stand now, even if you want BIP101, you can't really have it if you have a problem with Mike, because XT isn't an option for you. And because other people feel that way, you're further limited. The way Core (and XT) does it now makes it a power struggle, a popularity contest, and a package deal. Maybe Core could stall for a long time before people would finally give up and go with Mike. That's a lot of friction in the market.

And small block adherents, imagine the reverse, if it were Mike and Gavin were running Core and Pieter, Wlad, and Maxwell had broken off and started their own implementation, with maybe Jeff going between. And people were sticking with Core and its giant block plan, heading for catastrophe. You might notice the market friction then.

BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code. It also of course makes for a lot more choices. If 1MB is too small and 8MB too big, what recourse is there? Roll your own and try to popularize it? Very hard. But propose 4MB and try to get people to agree? More doable. Or what if, like some Chinese miners were saying, 8MB is fine but the scaling to 8GB is ridiculous. What do you do? You have two options, and they are bundled up tightly with all the other aspects of the code and why you choose Core or XT. That's again a lot of market friction.

I'm not disagreeing with you necessarily about a users setting the parameters on their own nodes, but I don't see how this market mechanism works, nor do I see how you have "eliminated" a power struggle.

People will still struggle to influence the miners and users over what block size is being used. Developers will be under influence (internal and external) over what defaults to set (or are you going to remove defaults altogether and require end users to choose every possible parameter?).

Whatever the merits of the idea, I don't see how you have made these decisions into significantly more of a market process. As we have agreed, users could always modify the code or choose what code to use, so the market already existed. The politics will certainly still exist, and perhaps become even more intense (and potentially, expensive, which brings its own issues) with respect to trying to convince users and miners (and possibly developers, as to defaults).

Remove the hard code size limit? Okay, sure, maybe a good idea, maybe not. But beyond that you seem to be overselling the idea by a wide margin.

[Zangelbert Bingledack]

BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code.

Why should this be removed from the code and made user configurable? It is consensus critical since it can create hard forks, so why should it be removed?

It gives choices you say, so does that mean that we should make everything else that is consensus critical and make that user configurable? Should we remove the block reward schedule? Should we change the difficulty retargeting schedule?

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.

[achow101]

BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code.

Why should this be removed from the code and made user configurable? It is consensus critical since it can create hard forks, so why should it be removed?

It gives choices you say, so does that mean that we should make everything else that is consensus critical and make that user configurable? Should we remove the block reward schedule? Should we change the difficulty retargeting schedule?

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

[BitUsher]

Sorry but if you really think bitcoins success lies in the fact that a simple change can only be made by a developer then the system is completely doomed. Good thing emergent consensus does not work like this, anywhere in nature.

I think some of them are unaware, or have not considered the fact that consensus can be emergent. I don't even think Gavin has fully internalized this, even though he did agree to the idea three years ago.

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.

[iCEBREAKER]

the social contract (SHA256 PoW, 10 minute solution target, 21e6 emission, 1MB max block, pay-for-priority) cannot change one iota without alienating a dominant plurality of the socioeconomic majority's critical mass.

If indeed it is true that 1MB4EVA is part of Bitcoin's social contract, and indeed anything changed in the social contract will alienate the dominant plurality of the socioeconomic majority's critical mass, then you can go back to sleep, as BU presents no risk to you.

But your being here, expending effort in arguing against BU, is an indication that you are afraid that your assertions are incorrect.

If the economic majority does not agree to some new limit, then any fork based upon that limit will die. It requires an economic majority to sustain any fork.

I can only speak for myself, but I do agree with you that there are certain attributes that I feel are sacrosanct -- without which I would divest.

However, I do not agree that 1MB4EVA is even remotely part of these fundamental principles. Further, it seems you've lost that battle even amongst the majority of those that oppose a simple maxblocksize increase at this point in time.

Must suck. Sorry.

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.  

[Zangelbert Bingledack]

Interesting. Do you have a general sense of what block sizes are most BU supporters comfortable with? How about yourself?

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.

Will BU be rolling in the long list of other scaling changes core is going to be rolling out, including SegWit/SepSig?  (Seems to be some confusion on the issue here-- https://bitco.in/forum/threads/what-is-bus-stance-on-segwit.665/) , perhaps this is all premature as you still need to vote in officers and finish updated your github as I see multiple issues there with a quick glance(many old notes and links from pre-fork).

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

[jbreher]

the social contract (SHA256 PoW, 10 minute solution target, 21e6 emission, 1MB max block, pay-for-priority) cannot change one iota without alienating a dominant plurality of the socioeconomic majority's critical mass.

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

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

[smooth]

inserted by developers who excellent at what they do have no track record as incentive designers, economic parameter setters, etc.

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.

[alp]

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.

[Zangelbert Bingledack]

inserted by developers who excellent at what they do have no track record as incentive designers, economic parameter setters, etc.

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.

I think the blocksize is the biggest controversial economic aspect they have touched (kind of easy to change something when it's not controversial), but - see my edit - I don't think it would be good to vest power even in someone who did have a good track record on that.

I do think we will be fine whatever happens with blocksize, and are fine now, but that adoption could be set back quite a ways if too much friction is introduced and circuitous paths are taken, so I think it's worth pointing out some existing burdens on weighing on the market discovery process.

[iCEBREAKER]

the social contract (SHA256 PoW, 10 minute solution target, 21e6 emission, 1MB max block, pay-for-priority) cannot change one iota without alienating a dominant plurality of the socioeconomic majority's critical mass.

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

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

The statements are not equivalent; the former (obviously) does not consider the exigency analyzed in the latter.

Sorry to have confused you, I should have been more clear for the sake of easily disoriented Trump-voters.  

[Zangelbert Bingledack]

Note to all since I've been answering a lot of questions: I'm not a spokesman for BU. I'm just someone with a keen interest in the project, and more than that, the overall concept and approach. My views are mine alone. For more details on what others involved in the project think, you'll probably have to go to other forums because many who are close to the project feel - with some justification but wrongly in this case I think - that they will be censored here.

I notice Adam posted on the other subreddit, so if you're not averse to asking questions there you may get some answers that I myself cannot provide. Really the developers should be answering a lot of the specific questions (on reddit: /u/thezerg1 /u/awemany and sickpig (not sure of sickpig's reddit name)). My responses here are mostly about the general idea of user-adjustable blocksize settings, which I see as the major idea of the project - note that many others probably do not agree.

[johnyj]

Just wonder, if every week there are 100 new solutions, who has the time to review? Shouldn't the new solution based on current major user feedback instead of wishful thinking? Need a spam filter for new solutions  

[solex]

How Bitcoin Unlimited works

Please review these examples of emergence first:
http://www.pbs.org/wgbh/nova/sciencenow/3410/03-ever-nf.html

Assume a BU majority network.
Consensus occurs on the max block size over the whole Bitcoin network from low-level rules used by thousands of individual nodes. There is no voting.

With Core and XT everyone needs the same maximum for block size. BU is different in that only the whole network possesses the attribute of a dynamic block limit, while each individual node has an approximation, or even a limit which is a lot smaller or larger. It doesn't matter, except that nodes with a too-small limit will frequently have the latest blocks "on probation" waiting for them to reach an acceptance depth. A node which sees a block which is excessive (over its limit) will not relay or process it until it is buried under enough confirmations. BU nodes always track the chain tip with the most PoW.

A miner producing a block larger than emergent network consensus gets its block orphaned. As individual node owners update their settings after upgrading or getting new hardware, bandwidth etc, then the network consensus slowly changes, usually upwards although the exact value at any one time is an irrational number and unknowable.

Individual node settings:

• Excessive block limit (default 16MB)
• Acceptance depth, i.e. confirmations (default 4)

[brg444]

inserted by developers who excellent at what they do have no track record as incentive designers, economic parameter setters, etc.

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.

I think the blocksize is the biggest controversial economic aspect they have touched (kind of easy to change something when it's not controversial), but - see my edit - I don't think it would be good to vest power even in someone who did have a good track record on that.

I do think we will be fine whatever happens with blocksize, and are fine now, but that adoption could be set back quite a ways if too much friction is introduced and circuitous paths are taken, so I think it's worth pointing out some existing burdens on weighing on the market discovery process.

I mean... for how long are you going to dodge the very simple fact that BU is NOT a market driven solution but one that leaves EVERYTHING up to the miners?

It's painfully obvious to anyone paying attention yet you (and others to which I've raised the point) continue to swerve around the issue.

[smooth]

It doesn't matter, except that nodes with a too-small limit will frequently have the latest blocks "on probation" waiting for them to reach an acceptance depth. A node which sees a block which is excessive (over its limit) will not relay or process it until it is buried under enough confirmations. BU nodes always track the chain tip with the most PoW.

So it sounds like you are using non-relaying by end user nodes as a form of soft pressure to discourage miners from creating blocks larger than node limits.

How do you deal with the fact that miners will often want to have direct connections with other miners (due to the natural incentive to reduce "orphans"), making relay through end user nodes irrelevant?

Setting aside the previous, have you done simulations or mathematical models to characterize how relaying will behave in practice given some distribution of nodes putting a block "on probation" while other nodes process and relay it?

Can you characterize the cost of creating nodes that deliberately relay larger blocks than most of the end user nodes in an attempt to influence the orphan pressure on miners?

Without doing any simulations or models, it intuitively seems to me that even a small number of such permissive nodes (either malicious or otherwise) can quickly relay blocks to nearly the entire portion of the network willing to process them, though operators of such nodes will incur bandwidth costs.

A miner producing a block larger than emergent network consensus gets its block orphaned.

Only if the block does not reach other miners.

[Zarathustra]

inserted by developers who excellent at what they do have no track record as incentive designers, economic parameter setters, etc.

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.

I think the blocksize is the biggest controversial economic aspect they have touched (kind of easy to change something when it's not controversial), but - see my edit - I don't think it would be good to vest power even in someone who did have a good track record on that.

I do think we will be fine whatever happens with blocksize, and are fine now, but that adoption could be set back quite a ways if too much friction is introduced and circuitous paths are taken, so I think it's worth pointing out some existing burdens on weighing on the market discovery process.

I mean... for how long are you going to dodge the very simple fact that BU is NOT a market driven solution but one that leaves EVERYTHING up to the miners?

It's painfully obvious to anyone paying attention yet you (and others to which I've raised the point) continue to swerve around the issue.

As long as you can't understand a swarm and autopoiesis, you will never understand. You will always believe in authority.

[Zarathustra]

If you want info about Bitcoin Unlimited you should check out their forum (https://bitco.in/forum/forums/bitcoin-unlimited.15/). Most of their discussions is there, including technical and not.

The idea was to have some technical focussed constructive discourse and this is a more neutral forum and also where more Bitcoin experts hang out.

Adam

Surely this is a joke?  The only reason the other forum was created was because Bitcointalk was becoming known in the Bitcoin community as North Korea.  

Very nice to see Dr. Backamoto drolly trolling the F*CK out of the Gavinistas, albeit in his studiously academic Sword of Logic idiom!  


Here's all the info you need to know about Unlimiturd: you may have any block size you want, so long as it's <16MB.  

Only when Hearn's Redditard Army is unified around a common theme can the next stage of his puppet masters' Manufacturing Dissent strategem be enacted....

Too bad for them sunlight is the best disinfectant, and this thread is the functional equivalent of a coronal mass ejection right onto the Coinbase Pointy-headed CEO, Bitcoin Judas, Frap.doc, and Peter R's stupid faces!  

Very nice to see what kind of 'Bitcoiners' with what kind of language on what kind of 'communication' channels are trying to back Mr. Back.
Very nice to see that such Monero-Trolls indeed believe they help to keep Bitcoin on core's track to cripple Bitcoin.

[Zarathustra]

Here are two posts from testing1567 on reddit (says he doesnt have a bitcointalk account):

Here are two posts from the BU lead developer.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-226#post-8419
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-226#post-8444