How does BU work?

[laurentmt]

> A node can only get "left behind" if it has a limit which is too low.

Agreed. A higher limit can only exist if it's supported by a larger part of the hashpower.

> It will be receiving all valid blocks from the majority of nodes which have a larger limit and are smoothly following the longest chain.

It works if the node isn't "disconnected" from the big chain (i.e. all its neighbors enforce a low limit). I guess that having the majority of nodes following the choice made by the majority of the hashpower would help here. Is there a way in B.U. to check the limit enforced by the neighbors ?

> The Bitcoin node network does not exist in a vacuum. There is economic consensus which is exogenous to it.

Agreed but are we sure the economic consensus must be unique ? With the features offered by BU, what would prevent a "split" in 2 sustainable chains like:
- a "small blocks" chain enforced by chinese miners and followed by chinese exchanges and "small blockists",
- a "big blocks" chain enforced by western miners and followed by western exchanges and "big blockists".

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

I guess the proposition made by this fork was very hardcore for a large part of the community.

 

[solex]

@laurentmt
Fair points. I still doubt that concurrent small/big block ecosystems is a stable situation, because fungibility of the currency is broken for new issuance.

> It works if the node isn't "disconnected" from the big chain (i.e. all its neighbors enforce a low limit). I guess that having the majority of nodes following the choice made by the majority of the hashpower would help here. Is there a way in B.U. to check the limit enforced by the neighbors ?

Not yet. We should expect later development of messages for nodes to exchange their current limit and help with transparency.

The problem of an "average-limit" node surrounded by "low-limit" nodes which are not sending the latest blocks made me think. If we assume no environmental cause for clustering of limit settings, and, for example, 20% of all nodes having a "low-limit", and at least 8 active connections for a relaying node, then is the probability that an "average-limit" node is not aware of the fork with most PoW being very low, about 0.2^8 ?

 

[Peter R]

Is there a way in B.U. to check the limit enforced by the neighbors ?

Not yet. The only changes we've made are those specified in BUIP-001.

What I would love to do is add a new P2P message so that nodes could poll other nodes for their block size limit settings. I'd also love to have miners mining with BU write their settings into the coinbase TX.

 

[theZerg]

Originally BU wanted to touch as little as possible to encourage adoption. I think the different so scary fears haven't materialized and core+101 exists. So I think its about time we opened discussion about these possibilities.

 

[laurentmt]

@solex

> Fair points. I still doubt that concurrent small/big block ecosystems is a stable situation, because fungibility of the currency is broken for new issuance.

Indeed, that would mean that we have 2 different currencies which are not fungible. Nodes would receive a lot of invalid transactions and it may seem like a weird situation considering the 2 currencies use the same p2p network but it's not a "blocking" problem since the only chain which matters is the one you use.

But if you don't mind, allow me to continue with this thought experiment.

Let's say that we have these 2 concurrent chains:
- the 1Mb chain has 45% of hashpower and is used as digital gold for settlements
- the 8Mb chain has 55% of hashpower and is used for payments

The 8Mb chain meets some success with a growing number of transactions.
Since all transactions flood the same network, it's obviously too many transactions for the 1Mb chain & the mempool of its nodes. Therefore, the 1Mb chain drops transactions with lower fees (payments) and only keep transactions with higher fees (settlements). All transactions are validated by the 8Mb chain.

Now, let's imagine that for some reason (mining pool deciding to switch to the 1Mb chain, attack against bitcoin, ...) the hashpower for the 1Mb chain increases and becomes higher than the 8Mb chain.

After a while, nodes following the 8Mb chain switch to the 1Mb chain which is the longest chain. If they can't get more hashpower, the rational choice for miners of the 8Mb chain is to decrease their limit to 1Mb.

During this huge reorg, we have a bunch of payment transactions which were not included in the 1Mb chain. What happens to these transactions ?
- the network tries again to include them in the 1Mb chain (provoking a massive ddos attack of the network against itself ?)
- they're definitely dropped from the blockchain (i.e. people lose a lot of money

This thought experiment is just a support to think about the potential threats against the longest chain (with the higher size limit) and the plausibility of this exact scenario isn't very important.

But, imho, it raises interesting questions:
- is it possible to define the security of the longest chain according to the distribution of hashpower among the concurrent chains ? Which margin is considered as enough security for the longest chain ?
- is there a known/empirical threshold for the length of concurrent forks after which a reorg may become an attack vector (ddos of the network against itself) ?


> is the probability that an "average-limit" node is not aware of the fork with most PoW being very low, about 0.2^8 ?

I would go with the formula of hypergeometric distributions (https://en.wikipedia.org/wiki/Hypergeometric_distribution). I didn't do the maths but that should give a low probability with normal conditions. Remains the possibility of an eclipse attack.

 

[theZerg]

This is the situation we were in on testnet. The 2 networks basically worked OK and mostly ignored each other because Core nodes would drop XT connections as soon as a large block was relayed.

However, with real money this could get nasty because 1 txn can be played on both networks.

When my BU node switched from Core to XT it did try to unwind and replay 1000 blocks worth of transactions. It was very slow.

Switching forks makes a lot of sense for users and during a short multiple fork transitional period -- when all txns can be pretty reliably posted on both forks. But you are right we need to think about major forks. Due to the way BU works, major forks can't happen on a BU only network.

But in a network with Core nodes, your scenario is at least possible if unlikely. It would be relatively easy to allow the user to manually eliminate a fork (show the forks and let the user click with the mouse to say "never switch to this one"). Hard to anticipate whether the effort is worth the likelihood of this occurring though...

EDIT: and in reviewing your msg, it doesn't seem likely that the 1MB would be used for "gold" and the 8 (and someday, 16, 32) MB chain would be for daily use. You are right the 1MB chain would essentially be DOSed with invalid transactions if an 8MB client accidentally connected to it. I can only see this situation during a fight to be "the" bitcoin. Eventually the smaller block chain will have to add a patch that changes port numbers or adds a special client version field so it is not exposed to the load it remained small to avoid.

 

[solex]

@laurentmt
It is an interesting thought experiment and the concluding questions are important.

First, if we consider this:

Let's say that we have these 2 concurrent chains:
- the 1Mb chain has 45% of hashpower and is used as digital gold for settlements
- the 8Mb chain has 55% of hashpower and is used for payments

The question arises "what is the market price of the newly mined currency units on each chain?" Whatever they are they will be different and will fluctuate with supply and demand. We know that mining is a marginal business as uneconomic miners are driven out of business constantly. As soon as the price divergence makes it slightly more profitable to switch there will be a runaway effect as miners leave the remaining fork with a difficulty such that it isn't being extended fast enough, price falls and more miners leave it. Either the digital gold or the payments tx choke up.

Alt-coins used to have exactly this problem where the market price of one falls and miners abandon it en masse. So nearly all implemented the Kimoto Gravity Well or other formula which changes the difficulty every block. Bitcoin's 2-week diff means that a weak fork can stall quickly and permanently.
http://cryptorials.io/glossary/kimotos-gravity-well/

But, imho, it raises interesting questions:
- is it possible to define the security of the longest chain according to the distribution of hashpower among the concurrent chains ? Which margin is considered as enough security for the longest chain ?
- is there a known/empirical threshold for the length of concurrent forks after which a reorg may become an attack vector (ddos of the network against itself) ?

These I can't answer. @theZerg mentioned that he tested 1000 block re-orgs, and found it very very slow. IMHO, the speed of any re-org of this depth is somewhat academic because such an event would be a massive PR disaster with so much business unwound, that I doubt Bitcoin could ever regain the world-wide enthusiasm and trust it has now. The "truth machine" of the Economist magazine cover will have been found lying. I know that the Core Devs don't like check-points but being a pragmatist, I like anything which reduces the chance of big re-orgs, and that it is indeed an attack vector of the network against itself.

edit: snap - just read theZerg's reply.

Due to the way BU works, major forks can't happen on a BU only network.

It is so important that this state is reached.

 

[Zangelbert Bingledack]

@solex

Don't checkpoints introduce just another attack vector (I don't know exactly what the term means here)? I think the consensus issues have to be fully figured out, though I believe they will be. However, in the spirit of BU, checkpoints could be mere suggestions made by various groups: mining consortiums, the Core devs, the XT devs, the BU devs, etc. Schelling consensus has to converge on something, but it can take into account many suggestions. That's really what the 1MB cap would be in a BU world: just Core's recommendation.

We are going to see a lot of shift in the meanings of old terms as BU enters the conversation.

 

[laurentmt]

Emin Gün Sirer and Ittay Eyal have just published a post which has many intersections with our previous discussion about several competing chains. Food for thought !