BUIP038: (closed) Revert "sticky gate"

[Peter Tschipper]

@dgenr8 "Automatically increasing local EB immediately when one excessive block is accepted would not solve my concerns at all. That is an even more significant lowering of the bar required for the network to accept larger blocks. One that a minority has a much greater chance of triggering."

Why? How would that happen, that the bar would be lowered? EB would only be raised for those that had their sticky gate triggered. Others with higher AD are not affected. And in raising their EB the sticky gate is re-enabled preventing anyone from just creating blocks of any size for the 24 hour period.

 

[Peter Tschipper]

@dgenr8 I think we're having a misunderstanding (I re-read what you had said), I was not suggesting that we raise EB as soon as one excessive block is received but only if the sticky gate is triggered, meaning that AD was overcome. So if AD is 5 and we get 5 excessive blocks then the EB would be raised to be the largest block size of those last 5 blocks. In such a way the attacker (if it is an attack) would not be able to just create blocks of any size but then would have to overcome the new EB/AD once again.

 

[dgenr8]

@Peter Tschipper A single EB confirmed by AD blocks would also trigger your rule. Otherwise you are proposing a totally new behavior involving the number of actual EB's generated. You are also proposing something different than @theZerg when you suggest that the window for selecting the new EB is AD blocks, and not 144 blocks.

Regardless, automatically resetting the local EB on a single AD trigger event doesn't prevent an attacker from causing a reset to arbitrarily high block size, because attacker is the one creating the excessive blocks.

An auto-resetting EB policy can only have the effect of making the whole network accept larger blocks more easily than it would with the sticky gate alone (since alone, node has to reset EB manually and would otherwise reset back to their old limits once the sticky gate closed (the latter being a property I think everyone sees as problematic now)). The strength of the effect on the whole network depends on the number of nodes triggered.

Returning to stickiness itself, stickiness makes the network accept larger blocks much more easily than it did without the sticky gate, and makes it feasible for a minority of hashrate to reset the block size. This alone should totally disqualify it as a simple implementation adjustment. It is a major change to the fundamental dynamic blocksize design.

 

[theZerg]

I have posted my counter proposal here: https://bitco.in/forum/threads/buip041-buip038-counter-prevent-minority-hash-power-from-injecting-very-large-blocks.1648/
and am formally opening these BUIPs up for community discussion.

 

[sickpig]

Sure. It is simply ($738/BTC) * (12.5 BTC) * K / p.

1/p is the average number of trails to first success of Bernoulli process.

In a more formalized way:

Let V be event that occurs in a trial with probability p. Mathematical expectation E of the number of trials to first occurrence of V in a sequence of trials is E=1/p.

In our case p is the probability of an attacker with a given % pf the total hash rate to mine AD+1 blocks faster the the rest of the net.

That said I wonder if the formula above overestimate the cost of an attack.

Let say that the avg # of trials for an attacker is 5 (i.e. 1/p = 5). We are sure than he's going to spend
12.5* btc_value_in_usd * (AD+1) on the winning trails. But we don't know anything about the first 4 attempts.

It could be that the attacker miner 0 blocks on each failed attempt or AD blocks on all of them, this od course depend on the hash rate he owns, hence is p value.

What I'm trying to say is: shouldn't we have to know the avg # of mined blocks for a failed attempt to get a proper estimation of the cost?

Something like:

12.5* btc_value_in_usd * (AD+1) + (1/p -1) * cost_of_failed_trail

where

cost_of_failed_trail = 12.5* btc_value_in_usd * E(mined_blocks_of_a_failed_attempt)

 

[awemany]

@sickpig: I don't understand yet where you are coming from. Are you talking about the miner somehow optimizing his trial process and stopping early? I don't see how that is possible, but of course I might simply miss something here.

 

[sickpig]

@awemany it is entirely possible that it's me not understanding something obvious, it happens all the time

Let me see If I'm able to explain what I meant more clearly.

I'm an attacker with an X amount of hash rate, such amount will guarantee me to have a probability p to "open" the sticky gate, i.e. mining AD+1 block before the rest of the network.

Let say that p=0.2, that means that on average it took me 5 (1/p) trials to get the first success, being able to open the gate.

For the sake of simplicity I'm going to assume that all the BU miners node is signaling EB=2/AD=5.

This how I see a failed attempt at opening the gate:

1 - the attacker will produce an excessive block (let say 3MB) on top of the current chaintip (CT)

2 - the rest on the network will start keep track of that "fork" but won't start building on top of
of it before another AD # of blocks will mined on top of it faster than what i mined on the main
fork.

3 - Unfortunately for the attacker the hash power on the main fork was able to produce AD+1 blocks
on top of the original chaintip (CT)

4 - The "honest" part of the network will stop monitoring the minority chain because the main
fork shown to have more PoW and being longer.

5 - In the process the attacker had mined 2 blocks on top of the initial excessive block. So this
mean that he wasted 12.5 * 3 bitcoin in this attack.

Repeat pints 1 to 5 four times, again for simplicity we suppose that every time the attacker waste 3 blocks.

The 5th time he was lucky enough to being able to mine AD blocks on top of the EB block and open the sticky gate.

In the first 4 trials he "spent" 12.5 * 3 btc on the 5th he spent 12.5 * (AD + 1) btc = 12.5 * 6 btc.

So it seems to me that it's not that the attacker is going to stop early to minimize the attack cost, it's just that once the main fork will be extended by AD+1 on top of CT before the attacker forked chain he has to restart again because his chain will be discarded by the honest majority.

edit: s/minority/majority/ in the last line

 

[HostFat]

@Peter Tschipper
I like the idea of increasing the EB to the last accepted (after the AD trigger) bigger block, .

But also I think that the node should not accept any bigger blocks then the bigger one that it has received first.
I mean that with a node that has EB 1 (and AD 6), then if he receive a 2MB block, then it will not accept a 2.1MB (or more) block on the same chain.
There must be 6 blocks (to enable the AD trigger) before accepting a bigger block on the same chain.

Also, I think that the auto-update of EB should be an option, enabled by default, but that can be disabled (a simple checkbox near the EB/AD settings)

I also think that with the auto-updating EB, the default AD (set after the first installation) should be set to something higher, not less then 6, maybe 10.
This to avoid even the "possible attack" from the malicious minority miner, and the larger majority of the miners will have to concur everytime to start making bigger blocks.

On this way, the sticky gate can be removed. I also think that it is simpler than some complicate math formulas.

Nodes that still want to avoid accepting bigger blocks, they just need to set AD to 99999.

 

[Peter Tschipper]

@HostFat I think the best solution here is BUIP041 the counter to BUIP038. If BUIP038 goes forward and we remove the sticky gate then we effectively kill Emergent Consensus as a mechanism that the miners can use. That means no larger blocks anytime in the near future and a likely outcome that the miners will have no choice but to activate SegWit as the only viable solution IMO. As far as I can see, BUIP041 resolves all the issues regarding the attack vector the Tom has outlined.

 

[HostFat]

Hmm, I see the auto-update of EB by default (that doesn't accept any bigger blocks before the AD trigger) a different way to have the current sticky gate function, just safer

 

[freetrader]

@HostFat I think the best solution here is BUIP041 the counter to BUIP038. If BUIP038 goes forward and we remove the sticky gate then we effectively kill Emergent Consensus as a mechanism that the miners can use. That means no larger blocks anytime in the near future and a likely outcome that the miners will have no choice but to activate SegWit as the only viable solution IMO.

Nothing against promulgating your preferred solution, but to me this outcome sounds hyperbolic.

1. Miners can always run the code they choose, including one with sticky gate as-is.

2. Node operators can always run the code they choose, including one with sticky gate removed

3. BUIP038 is a reminder that some of us see a "gate wide open" as problematic. Miners surely realize already that the rest of the network is going to have a say about a block size increase. If you disagree, you play into the hands of those Core supporters who claim that BU opens the door to unsafe block size increases at the sole discretion of miners. This has never been BU attitude since I can recall, emphasis was always that the full node network can act as a control mechanism.

I don't think miners are so unimaginative that they don't see the middle ground here.

IMO EB + AD are sufficient to let miners + relay node operators come to a safer emergent consensus about block size increases.

Miners who wish to guard against loss of money due to trailing the chain will *always* run something like a sticky gate or some similar algorithm (see BUIP041). Just make the sticky gate optional, as was proposed by @solex in this thread.

 

[theZerg]

To summarize the 3 ideas recently proposed:
1. removing the sticky gate (BUIP038)
2. making the sticky gate optional
3. wait AD blocks every time a blocks comes in that's bigger than EB, and bigger then prior blocks (Hostfat's idea)

All of these ideas do not fully address the attack. An attacker can make his first few blocks huge, before the AD is even exceeded. The attacker does not have to wait until the "gate" is sticky before issuing large blocks...

BUIP041 fully addresses the attack. It makes the AD block wait proportional to how much bigger the block is than your EB. Or proportional to the prior biggest block if your EB has already been exceeded.

So If your EB is 2, and a 4MB block comes in, you'll wait twice as long before accepting it. This makes it much, much harder to overwhelm other node's ADs with huge blocks.

 

[HostFat]

BUIP041 fully addresses the attack. It makes the AD block wait proportional to how much bigger the block is than your EB. Or proportional to the prior biggest block if your EB has already been exceeded.

So If your EB is 2, and a 4MB block comes in, you'll wait twice as long before accepting it. This makes it much, much harder to overwhelm other node's ADs with huge blocks.

Ah good, I missed this.

Anyway, what do you mean with "twice as long"? Twice the AD setting of the node?
So, in you example, if EB is 2, and AD is 4, with a block of 4MB, the node will wait for 8 blocks? Right?

 

[Peter Tschipper]

@freetrader

Nothing against promulgating your preferred solution, but to me this outcome sounds hyperbolic.

Sorry for the perceived hyperbole, but in my mind that is the logical outcome.

I would like to say though I'm grateful for the open and full debate on this issue. This is the first BUIP challenge that we've had in BU. It's a milestone in Bitcoin development, that we can debate and issue that is contentious and follow it with a meaningful vote. Something we've never seen in Bitcoin before!

That said, I think the sticky gate is an essential component of the behavior of Emergent Consensus and one that would be most wanted/needed by the miners. I just don't see the miners enjoying the prospects of having to lose sleep at night wondering if someone has forked to larger blocks. Particularly the smaller miners who may not be as plugged in or have the resources to be plugged in to everything that happens on the blockchain. The miners already have a hard enough time with the paradigm shift to EB/AD without also having to baby sit the blockchain and their EB/AD settings on a minute/hour/daily basis. That's why I believe that without the sticky gate the rational for going with and activating EC is basically dead.

 

[adamstgbit]

I think the sticky gate is an essential component of the behavior of Emergent Consensus and one that would be most wanted/needed by the miners.

I dont think so on both counts... weird.

having to baby sit the blockchain

i dont think this would be really an issue, i dont believe miners would take any drastic action such as increasing block size without first making some kind of announcement or increasing it ever so slightly as to not disturb nodes.

I think BU devs have created a very responsive / adaptive system for blocksize limit, but no miner will accept potentially losing AD # of blocks because of a disagreement on some settings... miners are way more likely to simply find the lowest EB setting on the network and religiously try to respect that lowest common denominator, in such a scenario, i fail to see the point of AD other than allowing that lowest common denominator some kind of help in being uncooperative, It also would appear to minimize the amount of consensus required to incress block size.

I fail to see the point of allowing users to set AD if the software will not respect that setting. I mean if i set my AD to 2 i mean 2, not 4 if the block is an obvious attack on the network.

I fail to see the point of allowing nodes to attempt obvious attacks on the network. IMO attempting to force a block size > then what majority consider EB is a flat out attack, nodes need to KNOW they can orphen these blocks without worrying about how lucky that % of hash rate will be... ( no matter how high that hash rate might be)

 

[dgenr8]

All of these ideas do not fully address the attack. An attacker can make his first few blocks huge, before the AD is even exceeded. The attacker does not have to wait until the "gate" is sticky before issuing large blocks...

Correct, this is not a problem with stickiness, but with AD itself.

It should not be possible for some rogue miner to get a gigantic block into the chain.

AD, including with the extensions in BUIP041, is actually not suitable as a mechanism for miners to know what size block to generate as they build the chain. They cannot be expected to try different block sizes until they see what the chain will accept. Nor can they be expected to guess whether another miner's block will be accepted.

What miners need is clear rules that only require data in the blockchain itself to determine whether a block is acceptable or not -- rules like the ones that govern difficulty. This does NOT preclude a coinbase vote. But it does mean that there needs to be a sane algorithm for knowing maxblocksize(height) based only on those votes.

With a few updates BIP100 would do the trick.

 

[HostFat]

@dgenr8

What do you think about the average coinbase voted size of the past 2016 blocks? (on the BIP100 idea)

On this way, EB/AD settings lose much of their value.
EB can still be used as a vote from the nodes, but this can still be subject to Sybil attack.

There is another way to show a preference to the miners (but it can be very different from the preference of node owners):
https://bitco.in/forum/threads/voting-signaling-on-txs.1247/#post-24598

transaction signatures can safely contain a few bits of information-- wallets could sign with different ECDSA nonces until they get a signature with the bits set the way they want to vote. That's a little messy (you can't tell if somebody is voting or not, you can just see if there is a bias in the bits to tell if LOTS of people voted one way over another) and subject to all the usual use-transactions-to-vote problems (miners can censor, relaying nodes might drop, etc).
I wouldn't suggest pushing any transaction voting idea, because the end result is very likely to be just another year or three of endless goal-post-moving discussion.

Maybe both EB and votes on tx can be useful as signals to the miners, to better understand which is the right choice of the next blocksize.

 

[theZerg]

@adamstgbit, I am proposing to revise the definition of AD to basically be "depth per EB" rather than just "depth". This is similar to other definitions in BU like "sigops per MB". So from that perspective, I am not proposing that we override the configured AD. I'm proposing that we change what AD means in a small way...

@dgenr8, you say "is actually not suitable as a mechanism for miners to know what size block to generate as they build the chain. They cannot be expected to try different block sizes until they see what the chain will accept." You then move on to suggest a higher layer "consensus" algorithm similar to bip100, which is a miner voting scheme.

It sounds to me in this last post that you are disagreeing with the emergent consensus idea as a means to determine block sizes. Can you clarify?

 

[adamstgbit]

@theZerg
your solution will most definitely work. minority hashing power will have no chance at creating a very big block. but i'm undecided if its the best way to go about solving this "problem".

i'm dreaming up another solution, which might be slightly more involved.. it sets a sort of "global EB" value based on all the EB values other miners provided in the last 1000blocks. blocks would automatically be orphaned if it's size is > then what 70% of the network considers EB

https://bitco.in/forum/threads/buip042-buip041-counter-buip038-counter-implicit-blocksize-limit.1664/

thinking outloud.

 

[dgenr8]

@theZerg All of the action will be in the coinbase signals, whether everyone knows how exactly the signals will be used to determine the size other miners are willing to build on, or whether we must guess. When bip68 was being signaled, it made 3 attempts to cross 50%. When it hit 55% consensus quickly emerged to support it. Segwit shows a different outcome. Both represent emergent consensus and neither required miners to guess which blocks to build on.

@HostFat There's always room to debate specific numeric values. Whether using AD, or BIP100, miners have to believe the non-miner part of the network will support the size they signal in coinbase, before they display that size, else when it comes to pass they may find the network ignoring them.

@adamstgbit Your suggestion is BIP100, using 70% rather than 80%.