Time to consider this again.

Ask not why the price rises.

Ask instead why the heck it was so low for so many years.

It's only going to get worse until you get back in.

Nice to see you fellows, too! Yes, it has been a hard winter of hodling these past years. This time we have built a careful base, we are up on pretty much all timescales, the stars are well-aligned, and the old 2013 movement patterns are repeating, including one I call the "battering ram." You can maybe figure out what that one is.

Here's a log chart, since it can never be posted enough. We have at least an order of magnitude of catching up to do!

We have a date with history, gentlemen.

Can't call OpenBazaar a failure when they haven't enabled TOR yet. For better or worse, commerce for normal (non-contraband) items is going to be one of Bitcoin's last major uses as it goes mainstream, not one of its first.

See: https://www.reddit.com/r/Bitcoin/comments/37m00z/problem_when_i_spend_bitcoin_in_the_real_world_i/crnum1a

$1000? Pshaw. Have you no ambition? If I thought Bitcoin would only go to $1000 this year I'd not even bother with it as an investment.

Key point, though it is hard to get people to see the intended interpretation of this.

Ledger > Protocol

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.

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

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.


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.

Yeah, software upgrade as far as I know. These are planned. Dev just started recently. Don't know how long it will take. Probably the supermajority requirements will be as in the original BIPs, with option for the user to customize them as well. Depends on what the devs do, or what people who fork BU do.*

*Note that, unlike Core or XT, it doesn't really matter (as far as consensus parameters) whether you run BU or a fork of it. This is an implication of the unbundling of consensus-parameter-setting from the rest of the code. So any questions you might be asking about the specific BU project with Andrew Stone as lead dev should probably be reconceived a bit:

Instead of asking BU what it will do, ask what anyone that does something similar could do. The genie is kind of out of the bottle. With the unbundling concept, anyone could offer blocksize-related BIP-mimicry of any kind in any configuration. It's just a matter of dev time and inclination. Dave Collins of the btcd implementation mentioned adding BU-style blocksize cap configurability, for example (on the other forum).

I'm probably not the right person to ask. Other people on that forum should know.


Note that nodes already are empowered with decisions on the consensus parameters, it's just that there is a lot of friction in them doing so because of the inconvenience barrier and the strong Schelling point that artificially sets up. (See my post above in reply to Smooth. I would say the current approach makes it far more political, and BU attempts to eliminate such aspects.)


Interesting idea. Bitcoin has a lot up its sleeve for the future, and DAO+oracles could do amazing things to market efficiency. I think a prediction market would be ideal. Once a decentralized prediction market is up and running and gets liquidity, this will probably be the way the blocksize cap is decided in the future.  

This whole debate has made be extremely optimistic about Bitcoin's future, as I see the ferocity with which people will defend and debate until the right answer has been reached even on a fairly esoteric point to most lay people. This is the power of an economic system powered people with skin in the game. How much have all of us learned, no matter what side of the debate you are on, in this past year? Bitcoin drives us to be better, smarter, wiser, less biased, less emotional, less narrowly focused on our own domains of expertise.


Yeah. By "small" I just mean like single-digit MB sizes for the next few years. I don't mean just permanent 1MB supporters.


No, any limit can be set. I assume testing1567 was referring to something about how someone said the acceptance depth thing was supposed to work.

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.

Note to small block adherents: Despite the name, Bitcoin Unlimited is not a "big blocks" implementation. It's simply an implementation that doesn't include a locked-down blocksize as part of the package. It lets the user set it. It could be 500kB if you like.

It's an accident of history that BU is being developed by big block supporters. It could have been developed by small block supporters for the exact same reason: to avoid the dominant Bitcoin implementation from doing something you consider foolish.

As I said in my first post, 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.

Bitcoin Unlimited is just as much a small blocks implementation, guarding against the possibility of, say, Mike Hearn taking over Core, as against, say, LukeJr. Bitcoin Unlimited is simply against central planning of the blocksize. Instead, blocksize consensus would emerge from each user making their own decisions, signaling, coordination, debate, flag days, expert recommendations, etc. It prevents against centralization of developers in one implementation; again, today it's small block adherents in Core, but what if it became big block adherents? It might start to sound like a pretty good idea to let the market decide.



Under BU, all our arguments about blocksize become merely academic. We would be trying to predict what the market would decide, rather than vying over control of the One Ring of Power - the official/reference implementation of Bitcoin. Much rancor could be dispensed with. The market would do its thing and probably maximize value, and Bitcoin would continue, unable to be controlled by anyone. Just the way we like it.

Actually, I did mention this to you on page 3. It's been a fast discussion and we forget things, so no worries.

I didn't realize you were asking about those other features, as you didn't mention them explicitly that I noticed. I just thought you were misunderstanding something about my explanation. That might explain the confusion.

I don't have a lot of thoughts on the acceptance depth aspect. It seems it would work, but it is experimental. It can be turned off, and I have recommended that it be turned off by default and marked as an experimental feature. I don't consider it necessary for the BU concept of letting users determine the blocksize limit, which I consider the main attraction of BU, so for me it's kind of <shrug>.