How does BU work?

[achow101]

I have been researching this (as I do with most Bitcoin related proposals) and I want to know how exactly this works. Unfortunately it appears that I can't find any specific technical details about this (I might just be looking in the wrong place). Can someone please point me in the right place to look for specific technical details about how BU works?

Also, has anything been done towards implementing stuff? Meaning if people were to run BU in its current state would it actually change anything.

 

[solex]

Welcome @achow101

When you ask "how BU works?" I am thinking that you want a high-level answer, and the best way to get a handle on that is to look at examples of emergence like the ones here:

http://www.pbs.org/wgbh/nova/sciencenow/3410/03-ever-nf.html

"It's not magic," the physicist Doyne Farmer once said about the phenomenon known as emergence, "but it feels like magic." Creatures, cities, and storms self-organize, with low-level rules giving rise to higher-level sophistication. Entirely new properties and behaviors "emerge," with no one directing and no one able to foresee the new characteristics from knowledge of the constituents alone. The whole is truly greater than the sum of its parts.

BU gives the full nodes of the whole Bitcoin network a mechanism (low-level rules) to express an emergent solution as to what the block limit should be at any moment in time. The prevailing average block size will still be somewhat smaller. If it becomes too small or too large, resulting in instability, then many users will alter their personal setting accordingly and it will find a new optimum.

Right now, BU is not on enough nodes for it to express a block limit solution. Ideally the non-mining node count should be >75% before its mining hash power percentage passes 50%. Soon after that the network will quietly allow blocks up to a specific size (which no-one will know) except that miners will test the unknown limit and find an approximation of it to use.

 

[achow101]

No, I am looking for technical, low level details of the exact protocol and the protocol messages to determine the block size limit. I want to know the algorithms and the rules that BU nodes follow in determining the block size limit. I assume I could look in the source code for this, but that is a pain in the ass.

 

[Zangelbert Bingledack]

@achow101

That's up to the user, since blocksize limit for generation and acceptance are both user-adjustable via a GUI menu. There is also a setting that lets you accept a block larger than your maximum accepted blocksize if it gets a certain number of blocks deep in the chain, and the user can set that number, too.

Determining the most profitable algorithms and rules for how they will choose their blocksize parameters then becomes the job of the miner or node operator, or alternatively they can set their parameters to mimic Core, XT, or recommendations from their favorite expert.

 

[achow101]

So basically all it does is allow the user to configure their own block size limit to produce and accept. And as a backup it will accept a larger size than configured so that the user stays on the network.

So this allows the user to be compliant (or not) with whatever block size proposal they want, either increase or decrease.

Is this all that BU is supposed to do? Let the user decide their own block size limits?

What happens if a malicious miner decides to create super massive blocks (so as to DoS nodes with verifying and relaying those blocks) and is able to produce them such that it creates a forked chain that is the default (4 right) blocks deep for acceptance by BU nodes? Would these nodes accept that chain if it was longer than any other? Would that chain be accepted if it was shorter?

 

[solex]

This is the elegance of BU. The limit arises from all nodes functioning together in a network and blocks larger than what the whole network determines is "big enough" get orphaned, so super massive blocks can't succeed. It will be a stable limit, increasing slowly. BU follows the chain with most PoW.

 

[achow101]

So what stops a miner (who happens to be lucky and is probably malicious) from killing the network by producing enough super massive blocks (which DoS the network) so that it surpasses the block depth thing so most BU nodes accept that chain as the "true" chain? I see that extra block depth parameter as another attack vector.

 

[solex]

Because BU non-mining nodes won't propagate blocks over the limit. So the malicious miner can't get his block accepted.

From theZerg:

It works like this: You can specify a value that we call an "excessive block", and an "accept anyway depth".

Let's say your excessive block size is 2MB, and your accept depth is 5.

Now, if a 3MB block comes in, your BU client will not relay it and your wallet's balances will not be updated relative to it -- basically the block is kind of on "probation" because it is so large. So BU will continue to track the longest chain that does not include this block.

But its still watching this block's chain. And IF that chain is built on beyond your "accept depth" (so in our example, 5 more blocks are added to the chain), then the block is removed from "probation" and the chain it is part of can now be the longest chain. In english "If enough other miners think that this block is OK, then I will let it be part of my chain analysis"

So in practice BU "follows the longest chain, no matter what." But in theory, if you set your "excessive" size to 1MB and your "accept depth" to something like 10000000 blocks you'd replicate Bitcoin Core's behavior for many years, except that internally BU would be tracking the large block chain not completely rejecting it.

 

[achow101]

nvm, there's a flaw in my argument. By the time the nodes are able to validate the blocks in the super massive block chain that was longer, the other blockchain would probably have overtaken it.

 

[theZerg]

@achow101 you can read a formal treatment of the flaw in your argument here:
http://www.bitcoinunlimited.info/1txn Read "Effect on Block Size"
Basically I use a game-theory analysis to derive the rational (profit maximizing) miner's actions in the case of large blocks and derive an equation and some plots that show how large miners should make blocks based on some network metrics...

Right now, BU is pretty light on code but very heavy on theory -- this makes sense because we have discovered that an unconstrained network will naturally find equilibrium points.

But I feel that as the new year goes by, we may be adding some cool features to optimise certain aspects of the bitcoin network that have been ignored to date. See Peter R's subchain work.

 

[laurentmt]

> If it [the block size] becomes too small or too large, resulting in instability, then many users will alter their personal setting accordingly and it will find a new optimum.

> Because BU non-mining nodes won't propagate blocks over the limit. So the malicious miner can't get his block accepted.

If too large blocks are not propagated, how is it possible that all users know a fork is occuring ?

My understanding is that when a fork occurs, BU requires that users modify their settings to converge towards a new equilibrium.
Any estimate of the delay before the network reaches the new consensus ?
Does it mean that a full node operator is supposed to monitor the consensus 24/7/365 ?

 

[swinny89]

With regard to the block size, changes seem to be very slow, as a huge populations transactions are fairly consistent. That being said, people will configure their software to be as safe as possible, and that includes being future oriented. If transaction volume is at a particular level, it only makes sense to put your limit at a level that is safely future focused. Also, I think it is probable that there will be only a few recommended configurations that most people will follow. Those who go far beyond the generally accepted will be raising their own risk (sort of, as they aren't really at risk of loosing coins, even if they accidentally fork).

 

[Zangelbert Bingledack]

And keep in mind that whatever the answer to a given question here, Core must answer the same question - except they have to do it in a centralized fashion that is somewhat slow (upgrade time versus just changing a setting time to have a new release be vette by the community, which can take months, and just the download and synching time, which is usually measured in days). BU can mimic Core's answer, but it can also do something else.

 

[solex]

@laurentmt
Perhaps I shouldn't have mentioned instability. I was thinking of the early period after transition to a BU majority network where the limit might be too low like the current 1MB problem or too high and nuisance blocks are happening. Instead, it is likely that an emergent limit will be very sensible and it will creep up slowly as a net effect of individual users changing their settings, infrequently.

Forks shouldn't occur more often what what the network sees today. However, there will be a minority of nodes who consider the latest block(s) too large, and have not updated their UTXO set and are a few blocks behind. Wallet software should make this clear to the user (though, personally, I have not seen what messages appear yet). Users will not have to monitor the limit unless their node is constantly behind, and they should consider a larger setting.

@swinny89
Agreed. There will eventually be websites and sharing of limit info between nodes to help users get a reasonable setting consistent with the majority.

 

[achow101]

And keep in mind that whatever the answer to a given question here, Core must answer the same question - except they have to do it in a centralized fashion that is slow (time to have a new release be vette by the community, which can take months, and just the download and synching time, which is usually measured in days). BU can mimic Core's answer, but it can also do something else.

I beg to differ. It is a good thing that it is slow, something that can cause forks such as the block size limit should be carefully checked and slowly rolled out to prevent disastrous forks.

Also, downloading and syncing anything related to the whole blockchain (including BU) will take days. But upgrading to new software doesn't since it doesn't need to sync the whole blockchain again. Or are you suggesting that BU somehow magically makes it possible to sync the entire 50+ Gb blockchain in significantly less time?

 

[Zangelbert Bingledack]

@achow101

But upgrading to new software doesn't since it doesn't need to sync the whole blockchain again.

Yes, I did not know that. I stand corrected. Still, changing a setting is much faster than upgrading to a new client.

It is a good thing that it is slow, something that can cause forks such as the block size limit should be carefully checked and slowly rolled out to prevent disastrous forks.

In this case there is nothing to check codewise, and in terms of protocol consensus this situation is no different than Core: miners are free to change their settings to mimic whatever Core decides - including any cautionary time period they want to include.

 

[laurentmt]

> Users will not have to monitor the limit unless their node is constantly behind, and they should consider a larger setting.
This is the point I don't get. How does a node know that it's "left behind" if all valid blocks (without any consideration to their sizes) aren't forwarded by others nodes ? In order to know that another branch exists, you need the blocks from this alternate branch.

An additional question: Does BU come with the objective of always converging to a single chain or is it considered that several competing chains are an acceptable outcome ?
For example, I could imagine the case of 2 long-living chains (e.g. 1MB & 8MB) each one having its dedicated mining pools and economic actors.

 

[solex]

> How does a node know that it's "left behind" if all valid blocks (without any consideration to their sizes) aren't forwarded by others nodes

A node can only get "left behind" if it has a limit which is too low. It will be receiving all valid blocks from the majority of nodes which have a larger limit and are smoothly following the longest chain. So it will know that it is not up to date. Let's say that its limit is 2MB and has an acceptance depth of 4, but the average block size is 2.1MB and the network is observing a limit of 5.7MB. Every now and again there is a sequence of 4 blocks <=2MB and the 2MB limited node will "catch up" and be active on the longest chain. However, a newly mined block >2MB will put it behind again (and it won't process or relay blocks for a while).

BU defaults have the mining size smaller than what the node will accept.

> I could imagine the case of 2 long-living chains (e.g. 1MB & 8MB) each one having its dedicated mining pools and economic actors.

I can't. The Bitcoin node network does not exist in a vacuum. There is economic consensus which is exogenous to it. Bitcoin exchanges will only support newly mined coins from one fork. Miners will only mine a fork which pays best market price. Likely the 1MB fork will quickly stall permanently as it will soon have ridiculous difficulty, and less fee-income as the 8MB blocks will have more tx.

Gavin mentioned once that when the block reward halved from 50 to 25 BTC in November 2012 some miners tried to keep mining a fork with a 50 BTC reward. This was such a failure that few people even noticed.

 

[Peter R]

"Gavin mentioned once that when the block reward halved from 50 to 25 BTC in November 2012 some miners tried to keep mining a fork with a 50 BTC reward. This was such a failure that few people even noticed." -- @solex

This is the first I've heard of this. Do you have a link or more info? Paging @Gavin Andresen too

 

[solex]

@Peter R
Even Gavin learned about this after the fact. I will look for his mention of it.