Re: bitcoin "unlimited" seeks review


Active Member
Aug 19, 2015
Quoting Adam Back:

"The proposers of bitcoin unlimited said they would like to get some review which seems reasonable, if others would like to help.

The proposal seems at first skim to be a copy of a few existing technologies from Bitcoin's roadmap and were first proposed by Greg Maxwell and others*: weak-blocks & network-compression/IBLT to reduce orphan risk, and flexcap (or a variant of it perhaps).

Perhaps they could start by explaining what it is & how it works. This might include unimplemented ideas, and a summary of what the code currently for download on the manifesto page does.

To review it will be clearer if you state your assumptions, and claimed benefits, and why you think those benefits hold. (Bear in mind if input assumptions are theoretical and known to not hold in practice, while that can be fine for theoretical results, it will be difficult to use the resulting conclusions in a real system). Particularly claimed compatibilities with Bitcoin and how the dynamic block-size game-theory is expected to work and remain secure with SPV mining, selfish-mining, block-withholding and fair (progress-free) mining could also use explaining.

I suggest the sensible thing is if there is something new or insightful, that Bitcoin consider adopting the technology and the BU proponents get behind that.

Maintaining a new coin is a rather complex undertaking and screwing up, as something like 40% of projects that have tried it have done, is very expensive of other peoples money.

To make progress on review it would be helpful to separate technical from political opinions.


* some citations seem to be notably missing, I trust this is unintentional."

Adam, you're quote above shows some misunderstanding so I'll try and explain below.

Bitcoin Unlimited is a very simple idea. As simple really as satoshi's much quoted if - then.

Blocks now, for example, are full at one mb. We have unanimous consensus that the limit should be increased to two mb. The question now proposed is not whether the limit should be increased, but how. Bitcoin Unlimited suggests that the limit be increased not in a centralised manner by having an ingrained limit in the protocol as that gives developers immense power as has been shown in 2015.

Bitcoin Unlimited instead proposes that node operators configure their own limit in a simple GUI menu. Currently, as there is unanimous agreement for a 2mb limit, the miners just sign their blocks with 2mb so communicating that they are willing to accept 2mb blocks. Once 90 or whatever % of them agree, then the miners can create the first 1.1 mb block and wala, we have a new limit.

Of course everyone else would likewise set their limit to 2mb because it is what we have all been waiting for and been discussing for so long. Now transactions increase, so at some point we, hopefully, get near the 2mb capacity. The miners again sign the blocks or communicate in some other way that they will accept up to 3mb blocks, the business nodes etc change their gui menu number form 2 to 3 and there we are, an increase without any more needing a hardfork, without needing a war, without unknowable projections, in line with technological capabilities etc.

In regards to selfish mining etc attacks, including the attack suggested by JackH and the attack suggested by Taek, people seem to assume that miners would all the sudden just make bigger blocks simply because they can - as if they never could. That would only work if 51% of them so decided and, as we know, if 51% of miners decide to fork off they can do so currently. That would give us a war however and, of course, as we all know, they ought to find it more profitable to not do such attack. etc. Basically, these attacks have nothing to do with BU because BU sets a limit just as hard as core's current 1mb, but in a decentralised manner as follows.

The miners are self interested economic actors and we can assume that 51% of them will be honest (if we don't make such assumption then bitcoin does not work). The miners therefore will set the limit to just above the blocksize transaction levels, as shown by our experience in the past six years with increasing the soft limit, pending any spam attacks of course, but as we saw from the spam attack during summer 2015, the miners are very good at identifying and filtering out such transactions, thus would not be stupid to just increase the size, hence BU provides a defence to the criticisms made against automatic algorithmic change.

Now if there is a rogue miner, then the same thing would happen under BU as under a centralised protocol limit. Once miners have communicated they will accept blocks up to 2mb, and the economy so agrees and we all agree, then the 2mb limit is the consensus limit. If some rogue miner creates a 3mb block etc, then they get forked off, if some guy creates 2k nodes accepting a limit of 200mb no one cares, because the consensus is at 2mb. Once demand for transactions picks up, consensus can be increased to 3mb as the miners and the economy sees fit. Once demand picks up it can go to 4mb etc.

It is a very simple solution in my view to the blocksize question. It makes the limit dynamic - as in it can more easily be changed than a protocol hardfork - and fixed at the same time - as in we have a way to reach consensus and anyone who deviates from it shoots himself in the foot. More over, it is a freemarket approach and more importantly than that, it is an approach that allows decision making to be made "locally", by the individuals affected on the ground, rather than a centralized committee.

Right now for example we have core stating 1mb or bust - well there is unanimous agreement that approach is wrong and the limit has to increase to at least 2mb because businesses right now are hurting. On the other hand we have another centralized approach, BIP101, which suggests 8mb to start with, then doubling. The problem with this approach, as has been stated by many, including yourself I believe Adam Back, is that we can not project the future. We do not know what limit we need next year, let alone in 4 or 10 years. We further have the proposal of 2-4-8, but again we have no idea if 8 is too high or too low in 4 years. We have no idea what will happen this year, let alone in 4 years. All three approaches highlight the well known problem that brought us to bitcoin in the first place - centralised decision making.

BU returns bitcoin to its roots by decentralising decision making in a way that is 100% safe and secure as well as fully game theory compatible so allowing for an equilibrium blocksize limit.

I invite you, and everyone else, to find holes and tear the above apart, always in the spirit of reaching a solution and if no holes can be found, then lets end this thing and have a reunited celebration party.
Last edited: