That is something else, perhaps from one of the research papers on future areas of interest.

Bitcoin Unlimited's main change at present is simply that, for better or worse, it makes it more convenient for miners and nodes to adjust the blocksize cap settings. This is done through a GUI menu, meaning users don't have to mod the Core code themselves like some do now. Planned improvements to BU include options that automatically mimic the blocksize settings of some Core BIPs, as well as blocksize proposals recommended by other luminaries.

The idea is that users would converge on a consensus Schelling point through various communication channels because of the overwhelming economic incentive to do so. The situation in a BU world would be no different than now except that there would be no reliance on Core (or XT) to determine from on high what the options are. BU rejects the idea that it is the job of Core (or XT, or BU) developers to govern policy on consensus or restrict the conveniently available policy options on blocksize.

BU supporters believe that to have it otherwise is the tail wagging the dog: the finding of market-favored consensus is not aided, but rather hindered, by attempts to spoonfeed consensus parameters to the users. (This is putting it gently. Having a controversial parameter set at a specific number by default would be spoonfeeding, not even having the option to change it is more like force-feeding.)

Widespread adoption of BU, or adoption of BU-like configurability of settings within Core/XT, would relegate developer-led BIPs on controversial changes to the status of mere recommendations. Proposals like 2-4-8 would be taken into consideration, but would have to compete in the market on their own without the artificial advantage of the current barrier of inconvenience and technical ability (users having to mod their code to deviate from Core settings).

BU does not support bigger blocks, nor smaller blocks; it is rather a tool for consensus on blocksize to emerge in a more natural, market-driven way - free of market intervention as it were.

Adam, if you are confident that, for instance, 2-4-8 scaling is the best option and would be supported by the market, I think you should either support BU or support a Core BIP to make the blocksize settings configurable within the Core client.

Right now the leaders of the dominant Bitcoin implementation are for a low blocksize cap, but imagine if the situation reverses and big blockists are in control, to the consternation of many in the community. I think you would not want them locking down the settings. You might say, "You folks are doing fine otherwise, but you are off on the blocksize cap. Why try to play central planner? Please leave it up to the market if you are so sure the market will like your huge blocks. People will follow your recommendations if they like them anyway, so what are you worried about?"

If I were Core maintainer, I would do the same. Perhaps I would set a higher default, but I would not take the option away from the user. To do so risks sudden consensus shocks due to friction effects, risks my position being undermined silently, and most of all assumes I know better than everyone else. I might set it at 10MB. But I may be wrong; I'd rather trust in the market, because none of us knows better than a million people all with skin in the game.

As for how communication to settle on a Schelling consensus happens, besides the usual out-of-band communication that happens now in the debate, there is also interest in adding a tool within BU to efficiently communicate information about blocksize settings across the network, thereby facilitating an emergent consensus.


The game theory is the same as that arising in the choice of Core vs. XT vs. whatever (or among the BIPs by the miners and other stakeholders; if we look at the game theoretic considerations applying to the Core dev consensus process I'm sure you realize that problem is intractable). Miners and nodes have all the same choices now, except there is some additional friction introduced by Core's locking down of the blocksize settings, forcing miners and nodes to mod the Core code if they want to change them.

The question ought to be turned around: what are the game-theoretic considerations involved in having a monolithic reference client causing complicated issues of inertia, authority, and potential power grabs on top of the cleaner game theory? If tractability of a game theory analysis is the goal, surely BU is at least no more complicated than the situation under Core in the event of a hard fork.


Ah. This is good. What I believe you are not noticing is that "manual human coordination" need not be top-down. Coordination can emerge, and it can be just as solid as any. Are you familiar with situations where it does? That would save a lot of ink.

I'd say what almost everyone actually trusts is that various experts and people with a lot of money on the line have vetted the code.

Not only is OP reverse-jinxing 2016 (which is good), there's actually mechanism behind that magical hex/charm:

Investors put millions of dollars into Bitcoin every single day. Investors looking to maximize their returns in the Bitcoin space have several options:

• buy BTC
• buy mining equipment
• buy stake in a startup (venture capital)

For two straight years, those daily millions have been flowing into mining and venture capital, not the price. If mining is topping out (likely) and venture capital is topping out (apparent), where do those millions flow? I'll give you one guess

My response from there:

My first impression is that your points are based on a misapprehension of how consensus on blocksize is intended to be reached in BU. I think you have seen N (the oversized-block acceptance depth) as the mechanism for reaching consensus,* when it's really more of a failsafe for miners who don't keep abreast of the situation on the network as well as they should if they want maximum profits.

Miners who are paying attention should have their cap set substantially above the normal maximum blocksize as seen on the network; I see N as a bit of a "gimme" to small block advocates who want to make some sacrifices to discourage large blocks, as N allows them to be a little bit riskier about it (they can safely set their max acceptance size M a bit lower) while still tracking consensus in most situations. However, I think you may have misinterpreted the point of this: N wasn't really necessary for BU to work. The original idea was to have blocksize be unlimited, then user-selectable blocksize was added as a concession to small block advocates who worry about big block attacks, and N was largely a way to make life a little easier for those small block advocates (BU engineers please correct me if I'm wrong).


Such a long-running duel assumes something near a 50/50 split of hash power between the chains, or else they would resolve more quickly, correct? It seems the situation with Core is the same if Core were to try to upgrade to 2MB blocks when miner support was near a 50/50 split on the issue. I know, they won't do this, instead waiting for "overwhelming consensus" like 95% or something, thus avoiding the terrible 50/50 outcome.

However, here I think you are seeing the illusion that the tail is wagging the dog. You apparently view Core's policy of waiting for 95% consensus as the means by which a 50/50 split is avoided, as if miners are all a bunch of robots. Since miners are aren't robots but in fact people who are dead-set on maximizing their profits, they certainly would not mine or build on an over-limit block (blocksize > L) unless they believed that would be a profitable choice. That would only be a profitable choice if it were unlikely to result in their block being orphaned.

If a miner is rational, which is the governing assumption of Bitcoin in the first place, this profit/loss calculation will of course take into account the very same 95% that Core is looking for, except the miner is free from that market intervention** and can choose his own threshold percentage while also balancing it with whatever other factors he deems relevant to the profit/loss calculation in his own individual situation - with his own unique power costs and connectivity and the transaction fees in the mempool at the time - to dynamically determine the point at which he himself has an expected positive return on mining a bigger block.

The first miner to mine a bigger block can be assumed to have performed such a calculation as a profit-maximizing agent, and then others may follow suit by raising their limits. Why would miners be monitoring the network that closely? Perhaps they aren't now, but they will have to in the future if they want to stay profitable, because their competitors will. They will do so when blockspace becomes limited enough and fees become high enough that their expected return on mining a block with some extra juicy fees overshadows the orphan probability based on various factors, including the XX% miner signaling.

Centrally planning the switchover at 95% is economically suboptimal and unnecessary. The Core devs imagine that without their paternalistic setting of that 95% threshold, miners would be unable to make the calculation for themselves - even though they are privy to the very same information, and in real time at that! And again, Core devs cannot know the profit/loss calculations that apply to each miner's individual situation. This is akin to Soviet-style price fixing and falls afoul of the Economic Calculation problem as explained by Ludwig von Mises, or the problems with the use of knowledge in society as explained by F.A. Hayek: no central planner can know all the individual valuations and tradeoffs each person in the economy will want to make.

The one-size-fits-all approach destroys the whole idea of the division of labor, the mainspring of human progress for the past 6000 years. Core's one-size-fits-all decrees are NOT where consensus comes from; consensus comes from miners not being idiots.*** The miners are the dog and the devs are the tail. Just like governments, they do something like require seatbelts in cars right as the auto industry is putting in seatbelts on its own and imagine that they - the wise overseers - are the source of auto safety. The tail imagines it wags the dog.

Everyone can see the decree and the effect, but few can see that the same thing - or probably something far less clunky - would have happened without the decree. If a miner has a positive expected return on an oversize block, he will mine it even if it does end up orphaned. Other miners can see this and adjust accordingly, especially once they start getting outcompeted by accepting fewer fees that they could be. Miners stay in consensus because they are econo-rational, not because of developer nannyism.

I would therefore expect blocksize to creep up very conservatively, and barring miner agreement on a flag-day upgrade - which is always a possibility even with BU except they can do without messing around with the Core devs - this will only happen when there are enough fees to warrant the orphan risk, as well as a high percentage of miners signalling support for a bigger blocksize. It would probably move up in some kind of Schelling-point increments like 2MB.

*unless you think BU is good and your point is simply that BU shouldn't have the "excessive block depth." That may indeed be and I would have to think about your scenarios more.

**which is, after all, nothing more than the inconvenience of adjusting that 95% threshold in the Core code oneself or finding someone to do to it for you.

***Some might say that miners really are idiots, but this violates the basic assumption of Bitcoin, that miners are economically rational. Sure, some miners now might not have to be very smart about their operations, but in the future this will have to change. Right now being dumb in some ways as a miner doesn't make you economically irrational, but in the future where forking and emergent coordination must occur, it will. Miners that refuse to monitor the network and make prudent profit/loss calculations will be outcompeted by those who do.

By "implementing" I assume you mean suggesting. Or do I have this wrong and he is able to force downloads?

Of course. Still with there being multiple choices it sounds like by "dictator" here we really mean "suggester."

I've heard Mike mention "benevolent dictator" of his own implementation, but I thought that was in the context of having multiple implementation options for the Bitcoin community to choose from.

If there are two different consensuses among "the nodes," then there are effectively two separate sets of nodes now, so which set of nodes would you be referring to by saying "the nodes"?

I'm not sure what "taking power" has to do with this. Are you talking about someone taking commit control of one of the implementations? (Wlad/Mike)

If I had to guess, I would say Core will up the limit early next year, probably modestly, in response to demand. If they stall too long, they risk losing some control over development.

Food for thought... Why Meni Rosenfeld doesn't fear contentious hard forks:

http://fieryspinningsword.com/2015/08/25/how-i-learned-to-stop-worrying-and-love-the-fork/

"Hard forks require broad consensus" is a common sentiment among the Core developers and the wider community. I want to get a sense of whether this is justified more by fairness/image considerations or more by perceptions that contentious hard forks are technically unworkable.

*For example, Adam Back said on reddit recently, "the network can not reach consensus with multiple competing incompatible consensus algorithms vying for control."

brg444,

Why would the market care yet? No one is complaining about high fees yet. No adoption is being hindered. Yet. The market is patient as long as it can be, and prefers the conservatism of sticking with Core until Core shows itself to be definitely unwilling to meet market demands. This may or may not happen, depending on what Core decides to do with the blocksize in the coming months. I'm guessing Core will increase the blocksize fairly soon, but if they don't. POW.

With the quote, I have no idea what it's getting at. Who are the "needers" and who are the "creators and owners" - needers, creators, and owners of what?

It's really very simple: investors can support whatever fork they like, and there will go the hashing power and eventually the development. Investors hold the keys to the castle. Always have, always will. It doesn't matter if they don't create or own anything. All that matters is they can move the price of CoreBTC or XTBTC when the time comes.

Yes, basically miners serve as a proxy for investors (in fact miners are a kind of investor as well, but investors pushing up the price incentivize miners to mine). Since investors are who control Bitcoin, miners are also part of "who control Bitcoin" both by proxy and directly. If we cannot trust the market of investors or we cannot trust the market of miners, we cannot trust Bitcoin.

This should be no surprise, really, as Satoshi originally spoke of users voting with their CPU power (now read: hashing power) to choose which fork they like. Bitcoin was always an emergent phenomenon of the market, not a planned phenomenon of certain developers.

It's easy to confuse this, because certain economic parameters in Bitcoin were planned by Satoshi...but it was not the dev Satoshi who made them part of the World Wide Ledger. It was the market. The market just happened to like his parameters. The market has not expressed an opinion on blocksize because it has never had a chance nor a reason to.

Forks give it the chance, and full blocks will soon give it the reason. Combine the two and



or maybe nothing. We will see. I happen to think the market will choose a substantial increase.

The "Gold collapsing. Bitcoin UP." folks migrated to the bitco.in forum.

Of course it is. Competing implementations is the only way to make it a market choice. In some years we will wonder why this was ever not obvious.

You can't force a fork.

https://www.reddit.com/r/Bitcoin/comments/3h01p2/how_is_the_bitcoin_community_supposed_to_build/

*poof* Top thread on the front page one moment, a few minutes later gone.

The subreddit has set a policy where not only is talking about alternative implementations banned, but apparently so is talking about the ban itself.

This reeks of desperation.

No, it won't. Desires are something humans have for evolutionary reasons. An AI is just a bunch of code. It can rewrite itself, but it can no more develop desires when it it loaded into a computer than it could if it were written down in book form. It will never "want" anything unless someone programs it to simulate such behavior, though as Cryddit points out there is a literal genie effect to worry about, where in attempting to execute an instruction it could wreak havoc on the real world.

That's why I say box it. By "box it" I mean never give it the ability to affect the real world other than by providing information. It will affect its own world, where it can learn mathematical properties and reason out things based on given physical constraints (3D shapes cannot pass through each other; given these shapes, what can be built?). To the extent it can remake the outside world in its sandbox, it can potentially provide us with a lot of useful information without being able to directly affect anything. It can probably tell people how to make a dangerous device very easily, or how to override their own conscious and go postal. So limiting its communication ability might also be good. Maybe at first only allow it to answer yes/no questions, with yes and no.

You will say, "No, it's supremely intelligent and will find a way out of the box. It will outsmart us and figure out how to affect the real world." (Eliezer Yudkowsky's argument.) But this is akin to a category error. It assumes that faster processing power equates with God-like abilities, or even the ability to do the logically impossible. Can an AI tell you what the sum of Firlup + Waglesnorth is? Not if it doesn't know what you mean by those terms. Similarly, it is functionally impossible to for an AI to even conceptualize the fact that it is, from our perspectives, in a box. An impossible thought is not thinkable even for a super-intelligence. We cannot conceptualize an infinite set, and neither can any AI. (In case this seems untrue, Eliezer also believes infinite sets are nonsense, to his credit. Whatever your position on infinite sets, if we for now accept that the notion is nonsense, an AI would not be any better at conceptualizing infinite sets, only better at noticing the meaninglessness of the term.)

You will say, "No, Nick Bostrom's simulation argument demonstrates how humans can reason about our own world being a simulation, where we are effectively in a box, as it were." But it doesn't. Bostrom's argument is merely a confusion based on equivocation. An AI would see this, as many people have. For example, scroll down to Thabiguy's comments here. It is clear that there is no way to even conceptualize the notion of "we are living in a simulation" coherently. If you think you can visualize this, try drawing it. It's just high-falutin wordplay. If the notion is not even coherent, there is no way the further notion that "an AI would figure out it is living in a simulation" is coherent either. Hence it is of no concern.

AI != God. And heck, even a god could not do the semantically impossible like prove that 2+2=5, though it may be able to convince humans that it has done so.

With the right controls, AI can be boxed. Still, as I mentioned, the danger of the operator equipped with AI-furnished knowledge is a serious one.

Nice. This could be modified into a good reddit self-post that should generate a lot of thought.