Using the Acceptable Depth mechanism to vote for different versions bits

[Erik Hedman]

Maybe I'm clueless, maybe this have already been discussed somewhere where I couldn't find it, but anyway, here we go:​

A node operator cannot influence the miners during the phase that leads to activation of a consensus change proposal in other ways than waving a flag and hope for the best
Currently a node operator (like me) have hardly no way of influence the progression of the functionality of bitcoin. It is up to the miners to chose which changes are to be made to the consensus rules and for me it's very hard to have any impact on the decisions of the miners.

If I want BIP109 to succeed I can run a client that accepts big blocks, but it's very hard for me to voice my opinion to miners because nothing that I do can influence them directly. And on the contrary, If there is a proposed change that I don't like, it's hard to vote against it.

Of course, if I don't like BIP109, I can just keep on running Core. But if suddenly the miners decided to support BIP109, I can't influence their decisions in other ways than keep running Core (which they could just ignore) and get thrown of the network after the first large block get mined.

In none of these cases can I influence the decisions of the miners through bitcoin mechanisms in the phase leading up to the activation, only old yesterdays meat space manipulations (like going to Hong Kong and lock a door).

Voting by enable acceptable depth to different version bits in blocks makes node operators able to influence the profitability of miners by influencing the orphaning risk
Currently Bitcoin Unlimited's Acceptable Depth mechanism is used to decide which block sizes you accept right away, and how many blocks deep a block with excessive size has to be before accepting the chain that builds on that block.

If that mechanism is used on version bits, I could, as an example, set the acceptable depth 4 on any block that has the bit for BIP109 set, making miners that mines BIP109 blocks to risk greater orphaning risks and being less profitable. The orphaning will also make less BIP109 blocks being accepted in the chain of most work and the activation with 750 out of 1000 blocks will be harder.

On the other hand, I could also set the acceptable depth to -4, meaning that I if a non-BIP109 block comes along, I will accept it in the chain of most work if at least four other blocks builds on that block. This will make the profitability for BIP109-miners higher making it more probable that a non-BIP109 block get orphaned than a BIP109 block. It will also making it easier for the hard fork to occur.

A single node operator can't make much of a difference by setting the acceptable depth, but as in elections, if a lot of nodes votes for the same thing, you can actually influence the politics of bitcoin, and it's consensus rules (which in my eyes are the same).

* * *
​

Decentralising the power over bitcoin from miners and developers to users
By letting node operators vote, there is more incentive to run a node, you could actually make a difference, not just giving away your services for free. It will also decentralise the power over Bitcoin from Developers and miners, and to node operators.

* * *
​

Bring on the comments! Do you think this is a good or a bad idea?

EDIT: there's a more detailed explanation further down in the thread with pseudo code.

 

[Peter R]

This idea goes meta on the meta of Bitcoin Unlimited. It's a way for nodes to fight soft-forking changes that they disagree with, without putting them at risk of losing track of consensus. Very interesting!

 

[Erik Hedman]

@Peter R I don't really understand what you mean, only soft forks?

 

[Peter R]

Hmm, good point. It works for hard forks too. I guess I was just focussing on soft forks because the "present way of thinking" is that it only takes a mining majority to implement a soft-forking change. This would give nodes further influence here (they already have influence over hard-forking changes).

 

[Erik Hedman]

The best thing, as I see it is that I can influence how the miners' hashpower produces valid votes for activating a hard fork before activation, not just veto an activated hard fork at activation time.

 

[Peter R]

@Erik Hedman : yes, exactly!

 

[Erik Hedman]

Now I just have to learn to code C++ to implement this

I actually did not think about the soft forks and that I as a node operator have nothing to say in that regard currently, but this proposal will give me that power.

 

[freetrader]

Erik, I guess I have some trouble following what exactly you're suggesting. Please forgive me if I raise some questions because I haven't fully understood.

My first question:

Q1: Version bits are set in blocks (set by miners). How can node operators use these to vote, since they can't change them - they can only accept or reject a block?

EDIT: Ah, I guess you mean that nodes should *react* to the version bits by adjusting their AD accordingly (i.e. apply some sort of dynamic AD dependent on a block's version bits). Indeed that might be a good refinement to the current BU scheme. But I'm skeptical due to the configuration complexity that would have to come with it, if a node operator is to retain complete freedom on how to configure this. I think many people already have problems grasping BU configuration parameters. This would add a whole new dimension of complexity.

 

[Erik Hedman]

@freetrader I don't get what you mean with dynamic, otherwise you get what my thoughts are in your "edit" paragraph.

Indeed it's tricky to understand, but if you understand the "acceptable depth mechanism as it is used in the block size case, I think you can understand it in thiscase too. And if it can give node operators a bit more power than they have today, I think it is worth the complexity. But you do have to do some education. On the other hand, nowadays I guess that the people running full nodes are geeks anyway.
[doublepost=1464272750][/doublepost]@freetrader or maybe I did not understand you. Did you think that I meant that we should adjust the acceptable depth for the excessive block size? That was not what I had in mind, rather to have different acceptable depth mechanisms in parallel, one for each version bit plus the size.

 

[freetrader]

@Erik Hedman : With "dynamic" I just meant that it's no longer a fixed parameter (AD), but it's a function of the versionbits.

Besides the fact that you may have a combinatorial explosion on the different bits, what do you do when you get bits which would be conflicting according to your desires? I guess you need a Turing-complete plugin capability to let everyone determine what they're going to do with the bits to compute the AD of their dreams. OTOH, if you want to provide them that much freedom, they can just modify the client code directly

Did you think that I meant that we should adjust the acceptable depth for the excessive block size?

No, not really what I meant to suggest.

Q2: What do you mean by "plus the size" ? that the AD depends not only on the versionbits of the block in question, but also it's size?

 

[Erik Hedman]

@freetrader I have a feeling that we misunderstand each other.

Currently Bitcoin Unlimited accepts a block if the block size is less or equal to the excessive size or the block depth is equal or greater than acceptable depth. In pseudo code that would be:

Example 1

if (blocksize ≤ excessive_size) OR (blockdepth ≥ size_acceptable_depth) then
    accept_block()
end if

My idea is that in addition to the rule above you should also check if you you have set different acceptable depths for the different version bits. In this example I call the acceptable depth for each version bit vbn_acceptable_depth where n is the number of the version bit. The version bit itself would be called vbn.

That vbn_acceptable_depth could be either positive and work like size_acceptable_depth, that means delay the inclusion of a block with vbn set to 1 until the block is vbn_acceptable_depth down. Or, vbn_acceptable_depth could be negative and delay the inclusion of a block with vbn set to 0. In pseudo code:

Example 2

if ((vbn = 1) AND (vbn_acceptable_depth > 0)) OR ((vbn = 0) AND (vbn_acceptable_depth < 0)) then
    if (blockdepth ≥ absolute_value_of(vbn_acceptable_depth)) then
        accept_block()
    end if
else // the case when vbn_acceptable_depth = 0
    accept_block()
end if

For all blocks you then run the code in example 1 to determine if the block should be accepted after checking the size of the block. Then you run the code in example 2 for all version bits possible where n = 0..28} to check if it should be accepted based on the version bit criteria.

So a block will only be accepted if the block is accepted by the size check AND the 29 version bit checks. If any of these 30 tests do not accept the block, it will not be accepted.

Did we talk about the same thing?

 

[freetrader]

Thanks Erik, that makes your idea much clearer and solves my Q2.

I had assumed up to now that the example #1 check is dropped completely in favor of just a version-bits based check similar to #2.
Also, I now get what you meant by the negative AD values - a mirror image for allowing to handle the bit-not-set case while re-using the same parameter vbn_acceptable_depth and also allowing to ignore a version bit (by setting the parameter to 0). Another condition when a version bit will also be de-facto ignored is if absolute_value_of(vbn_acceptable_depth)) < size_acceptable_depth , because then the second-level check is made redundant by the first.
So that should probably be prevented by configuration input validation.

 

[YarkoL]

This idea is of course worthy of consideration, but I think we ought to wait until the simple, already implemented use of AD, EB is employed first in significant numbers, before building on that
.

 

[Erik Hedman]

@YarkoL The difference, as I see it, is that the AD mechanism for block size cannot do any difference as long as there is no force strong enough to push for a higher block size limit (unless you are a part of the 1MB is to much-crowd).

If you implemented the AD on version bits, you could do (a little, at least) difference today.

 

[YarkoL]

as I originally understood BU - it was not to force anything, just to signal preferences. But that didn't catch on, so maybe your approach could make a difference.

I need to mull over this some more.

 

[Erik Hedman]

@YarkoL I appreciate mulling, and questions and ideas after the mulling.

 

[Erik Hedman]

After some thinking I have a question that maybe you people could help me to sort out.

The acceptable depth mechanism tries to orphan not preferred block (like blocks to big right now). But that works only when there are more than one alternative to a block. And there are few such cases.

Would a mechanism where the nodes has more influence to which blocks are orphaned or not make any real difference? Does that give miners incentive to make sure blocks are also propagated into the rest of the network to because, e. g., a miner could use the advantage of knowing that a lot of nodes would prefer just their block?

 

[Erik Hedman]

P.S. some off-by-one incongruencies in the final paras of your post, assuming you wanted to number the 29 version bits (and their 29 version bit checks) from 0..28.

Thanks. Text above corrected.

 

[HelloGuy]

@Erik Hedman I think only mining nodes will be able to provide a negative economic pressure for another mining node in the choice of fork, right? As a non-mining node, how my choice will give miners any incentives?

It could not be propagation time. Miners usually are setting up their own network to broadcast their block in a very fast way.

 

[Erik Hedman]

@HelloGuy

About the block size, Unlimited is still one CPU one vote. And the governance model of Bitcoin should not changed too much. The problem with Core is that some developers are trying to take control. However, if we let the ordinary transactions to have power, it is also change of the governance model. People are very easy to be led by some people like Greg, who is good at soliciting and intimidation. We should keep the same governance model of Bitcoin as it is./

Maybe I interpret you wrong, but my idea is about letting node operators have a say in which blocks they accept, and have nothing to do with transactions. It's about letting operators choose a block with one set of version bits over another, in the same way as you today can choose to have accept a smaller block instead of a larger, but ultimately accept a non preferred block, if the network chooses to build upon that.

When it comes to the question of governance. In my view, it's better to have a democracy, and with that comes that you have to accept that the people choose wrong (heck, in Sweden I think the people chooses wrong about half of the time). Because the other alternative would be to have developers to decide, together with a cartel of miners. And that is the situation we have right now.