pull down to refresh

Something I've been struggling with for a while is that supporters of BIP-110 have been making statements like this:


source


source


source

There seems to be a belief among BIP-110 supporters that even a minority of hashrate (45%?) could pull of a successful soft fork that carries the rest of the chain with it. I'm surprised by this belief because my not-expert mind had not heard of a 45% attack.

So I wanted to think through how a BIP-110 chainsplit would look:

The BIP-110 soft fork is supposed to activate either when 55% of blocks in a 2016 block difficulty period signal for it, or in September at block 965664.

Let's start with the scenario where we make it to September without hitting the 55% threshold.

The first block where BIP-110 is active could be a block that both BIP-110 and non-BIP-110 nodes see as valid (imagine it doesn't include any BIP-110 banned transactoins). In this case we are all still on the same chain. Let's call this block 965665.

Imagine that a miner supporting BIP-110 mines the next block (965666). BIP-110 doesn't add any new transaction types, so non-BIP-110 nodes should still see this block as a perfectly valid block.

Now imagine that a non-BIP-110 miner mines the next block (965667) AND the block includes a transaction that has been banned by BIP-110.

This is when we get a split.This is when we get a split.

All the BIP-110 nodes will see block 965667 as invalid. BIP-110 miners will not mine on it. Instead they will continue to mine on the previous valid block (965666). When they find a block, we get block R-965667.

Blocks R-965667 and 965667 both have the same amount of work behind them, so the non-BIP-110 nodes will see whichever block they learn about first as the best chaintip (BIP-110 nodes will only see R-965667 because as far as they are concerned 965667 is not a valid block).

Now comes the interesting part

Say the BIP-110 miners get lucky and mine another block in quick succession (block R-965668).

In this case, ALL nodes (both BIP-110 and non-BIP-110 nodes will see block R-965668 as the new best tip of the chain. Block 965667 gets orphaned. The miner who mined that block will never get their block reward from it. Transactions in that block will go back to being unconfirmed (unless they were included in one of R-965667 or R-965668).

In this lucky case, even miners who have never heard of BIP-110 and haven't updated their node software in years will see R-965668 as the best tip and will start mining a block that builds on that side of the split.

This is BIP-110's "asymmetric advantage"This is BIP-110's "asymmetric advantage"

Because BIP-110 blocks are valid as far as non-BIP-110 nodes are concerned, the BIP-110 side of the split can benefit from hashrate of miners who are not running BIP-110.

However, as far as I can tell, this only works if the BIP-110 chain has more hashrate than the non-BIP-110 chain.

Let's go back to the situation at block R-965668. The non-BIP-110 miners have just seen a block orphaned (965667), but they keep mining with non-BIP-110 rules on R-965668 with non-BIP-110 rules.

Let's say they find block S-965669 and include non-BIP-110 transactions in it. This will cause another split. The BIP-110 nodes won't recognize S-965669 because it contains invalid transactions as far as their ruleset goes. Instead they will continue mining on 'R-965668`.

But now in this case, let's say the non-BIP-110 miners get lucky and mine a new block (S-965670).

Now the BIP-110 chain (`R-965668) is two blocks behind. They now have to mine three blocks before the non BIP-110 miners mine 1 block. If they do not get this lucky, they will be even further behind.

It seems to me that this asymmetry doesn't actually exist if we zoom out of the microcosm of an individual one or two block race. If there is more hashrate mining on the BIP-110 side, I would expect that chain to grow longer than the non-BIP-110 chain. And expect the opposite to be true if the BIP-110 side has less than half the hashrate.

What am I missing?


I found an article on the idea of an intolerant minority in Bitcoin mining, but they didn't really explain why things would work out differently than I have outlined above.

https://bitcoinmagazine.com/business/op-ed-user-activated-soft-forks-and-intolerant-minority

Is this the answer I've been looking for?

source

reply
122 sats \ 7 replies \ @oomahq 3h

Yes. The pre BIP-110 chain can always be wiped out again and again even if it gets ahead momentarily, while the BIP-110 chain cannot be wiped out when it falls behind.

To neuter this effect a counter-softfork would need to be deployed. Thence the lowest friction to a miner is to go with a soft fork.

reply
121 sats \ 1 reply \ @Scoresby OP 1h

Same energy:

It seems to me that this is all predicated on having a majority of hashrate. My frustration has been with an argument that goes: "We don't need a majority of hashrate because we will eventually get a majority of hashrate."

reply
102 sats \ 0 replies \ @Murch 1h
"We don't need a majority of hashrate because we will eventually get a majority of hashrate."

That’s it: you have distilled the essence of the RDTS fallacy perfectly.

reply
0 sats \ 4 replies \ @Murch 2h

That’s unnecessary if support for RDTS remains as marginal as expected. Miners could also use invalidateblock on the first block of the RDTS chain to ignore the RDTS chain permanently; no fork necessary.

reply
21 sats \ 3 replies \ @oomahq 54m

Well, what you just described is a fork. The counter-softfork I alluded to, actually.

reply
0 sats \ 2 replies \ @Murch 52m

Fair enough! I thought you meant to express that it required a coordinated software update with a consensus rule change.

reply
2 sats \ 1 reply \ @oomahq 49m

Running invalidateblock in the manner you described is a consensus rule change (soft fork, introduction of a new rule) that targets RDTS, so.. Yes, that's what I meant.

reply
0 sats \ 0 replies \ @Murch 46m

Yeah, that’s why I said “fair enough”.

reply

This is why using Voskuil's code, where you can set your own checkpoints, promises Super Fun Times ahead.

reply
100 sats \ 4 replies \ @Murch 2h

Bitcoin Core has invalidateblock which you could use to render your node unable to consider the RDTS chain.

reply

As I understand it, it works differently. But to be honest I only remember sipa's narration so i have to re-review code to actually be sure.

I'll do that tomorrow.

reply
100 sats \ 2 replies \ @Murch 1h

A checkpoint is a commitment to a specific block, invalidateblock rules out a specific block. Is it that what you mean?

However, if RDTS doubles down on their minority chaintip, invalidating the first block of that branch in the chain makes your node consider all descending blocks invalid, too.

reply
0 sats \ 1 reply \ @optimism 1h
However, if RDTS doubles down on their minority chaintip

I think the if is hardcoded to a block height / flag day, so this is not a question of if or even when anymore. It's a question of "what now"?

invalidating the first block of that branch

The one that applies to forking rules, yes.


I just re-read #5316 - must have been 11 years since I read that ugh - and now I think I'm confused about the mechanism. I remember that at one point the consensus was that invalidateblock would tag a block to lose to a competing block of lower weight, but now I am uncertain of where I read that.

reply
0 sats \ 0 replies \ @Murch 1h

No, invalidateblock causes your node to treat the passed block as invalid. Naturally, any blocks succeeding it are therefore also treated as invalid. And IIRC, we ban peers that send us invalid blocks, so you also get rid of your RDTS peers all in one go.

reply

I have not refreshed my memory on this but isn’t part of the logic of an intolerant minority that the majority may change their behavior to accommodate because it’s less costly than dealing with the difference.

That makes me think the reasoning here is that the threat of missing a few early rewards will be enough to get miners who are on the fence to switch because they view the bip 110 people as more dug in.

reply

That seems less like an argument to me than an assumption or a hope. It's certainly not a technical argument. It's based on what one thinks other people will do.

reply

Well, I am an economist. The most common context I have for things is predicting behavior.

reply

in my mind, the way they are handling this, is kind of like:

look, It's safe to use a low entropy bitcoin key as long as the incentives are such that no one will want to steal your bitcoin.

(Bitcoin seems to be designed more along the lines of we don't know what all the incentives are, so the system needs to be durable to any kind of action)

reply

I’m not advocating for an intolerant minority strategy but it’s not an unreasonable expectation that those who have gone out of their way to adopt a particular block template are more committed than those who are using a default setting.

reply
21 sats \ 14 replies \ @optimism 4h

What makes you think that other pools are using a default setting?

reply

If the other pools are just as committed then their intolerant majority will trump the intolerant minority.

The point is just that people who consciously defect from the norm tend to be more committed to their position because they had an affirmative reason to change.

reply

Intolerant of non-profit-maximalism. With Antpool & co and Viabtc this is the clearest strategy. But do you really think that Foundry customers will suck wood for Luke's principles? lmao.

90 sats \ 1 reply \ @Scoresby OP 4h

Sure, but what I'm getting at is that there is a pretty narrow window when this is relevant.

In the moment of a split, miners have to make a decision about this. If >51% hashrate is on the non-BIP-110 side, every block they find means they will have to sacrifice more block rewards and fees in order to accommodate the intolerant minority, right?

Now, if the argument is that miners will appease the intolerant minority before activation and signal that they will mine BIP 110 blocks, then perhaps you have a point.

reply

I think it's that final point, plus some group who makes the switch quickly after activation.

Your logic seems right that if this distribution persists for very long then the minority will lose and become irrelevant.

reply

I think what you're missing is that at any given moment, there is a risk of the first scenario you outlined (i.e. BIP-110 miners getting lucky, causing a non-BIP-110 to be orphaned). This reduces the expected returns of non-BIP-110 miners in perpetuity, even if BIP-110 miners have a minority of the hash rate.

How large this effect is, I'm not sure. And that might be Luke's point about how "under 50% could work" but is not a "strong guarantee"

reply

It's not at any given moment. It is only at the moment of a split.

As soon as a split goes on for a few blocks, it becomes much more than getting lucky. As the difference in length of chain grows, the magnitude of the luck needed to cause the dynamic increases. Clearly there is a difference in chain length at which no one ever really worries about it anymore.

Now, if the BIP 110 people really wanted to do something, they could make it so if their chain ever gets 2 or 3 blocks behind, they reorg to use the non-BIP-110 tip and try again. Maybe people would get so frustrated that they would run BIP 110 just to stop the reorg storm.

And if they ever had a really great streak of luck, it might actually be enough to get some hashrate to switch.

reply

No, what I'm saying is that at any given moment, there's a chance of a split which results in one of the non-BIP-110 blocks getting orphaned.

The split isn't likely to last long, and at most a block or two, if BIP-110 miners have minority hash rate.

But since the risk is there at all times, it could result in a meaningful reduction of expected profits for a non-BIP-110 miner.

Does that make sense?

So I'm not saying that the splits will ever be large. Only that at any given moment there's a chance for a small one.

reply
202 sats \ 0 replies \ @optimism 3h
But since the risk is there at all times, it could result in a meaningful reduction of expected profits for a non-BIP-110 miner.

Not really. Because we measure the accumulated work over time. So with 40% vs 60% thats a whole lotta luck to have to get consistent threat over, say 500k blocks.

What will happen though is this op: the moment 110-enjoyoors fork off (flag day) they will start spamming the majority with CP. However, at least one - but more likely many of them - will fuck up with their KYC'd coins. This person will be traced, and made an example of. Spooks love this play. Mixers too.

reply
172 sats \ 1 reply \ @Scoresby OP 3h

hmm, maybe I'm missing it.

But once there is one split, it's all or nothing. Hashrate will have to change sides for a new split to occur.

I don't see how you could have multiple orphaned blocks in this situation: as soon as one BIP110 violating block is mined, none of the BIP110 miners will mine on it.

The only reason non-BIP110 miners would mine on the BIP110 chain after a split was if it had more hashrate. But my whole question was about this assertion that a BIP110 with a minority of hashrate somehow can overtake or pose a threat to a majority hashrate non BIP110 chain.

reply
Now, if the BIP 110 people really wanted to do something, they could make it so if their chain ever gets 2 or 3 blocks behind, they reorg to use the non-BIP-110 tip and try again. Maybe people would get so frustrated that they would run BIP 110 just to stop the reorg storm.

I think this is what I implicitly had in mind, because i am still thinking from the perspective of today, where the miners are in sync.

But you're right, if they just stay on their own fork, then it just becomes another fork coin.

reply
102 sats \ 0 replies \ @Murch 1h

The RDTS fork activates at a specific height. Unless they have at least close to half the hashrate, as soon as the non-RDTS chain finds a block they’ll get behind and continue to fall behind further.

The behavior you describe would apply if RDTS activated with a majority of the hashrate: every non-RDTS block would cause a short fork and then be reorged out.

reply
102 sats \ 0 replies \ @Murch 2h

No, the RDTS nodes will enforce the rules from the activation height. They will therefore fork off immediately on the first block that doesn’t adhere to their new rules. If the non-RDTS nodes get a few blocks lead and RDTS doesn’t have a majority of the hashrate, it’ll get increasingly unlikely that they’ll ever catch up.

reply
102 sats \ 0 replies \ @Murch 2h

You’re not missing anything. If RDTS activates with a minority of the hashrate supporting it, nodes enforcing those rules get stuck on a lower-work chaintip as the rest of the network pulls away with the most-work chain.

It seems that some proponents are fully aware, and prepared to create a minority fork:

reply
244 sats \ 7 replies \ @optimism 4h

If it is that easy to get 50%, then why does Ocean not have 50%?

reply

I don't mind if someone says "it's easy to get 50%"

In that case, it is something measurable and either they will or they won't.

But I'm mystified by these statements which assume some knowledge that I apparently have great difficulty accessing but also imply certitude that things will go a certain way.

If less than 50% of hashrate does not run BIP110, I fail to see how that changes. Every block that gets found in such a state will require the majority of hashrate to sacrifice even more in order to "comply" with BIP110 chain.

I really don't understand what I'm missing.

reply
244 sats \ 5 replies \ @optimism 4h

It's all bullshit. Luke is speaking to his base, not to you.

If there is a chaintip split and you're on the not-forked side, you can still replay all txns on the other side and get the fees, including those that you didn't mine. The only thing you cannot get is the fees from utxo that were doublespent.

reply

Is it bad of me to occasionally write the acronym for this fork as RTRDS?

reply
102 sats \ 3 replies \ @optimism 3h

YES!!! Shame on you! 😭 lol

Naw... but I dont know what the fuck that means and why we all can't just get along.

Worse. I don't understand why there is a toxic conversation between the author of said BIP and Murch while I spent 7 fucking hours trying to be nice and bring actual issues to the table.

reply
100 sats \ 2 replies \ @Murch 2h

Because Dathon doesn’t actually want feedback, he wants engagement.

I thought your comments were well-thought out and zapped a bunch of them, fwiw.

reply
21 sats \ 0 replies \ @optimism 2h

Thanks Murch.

Since all my zaps go to CCs, I have paid them fwd. <3

reply

I would accept feedback if you had it. But you don't have feedback, you just have FUD that you refuse to back up with facts or arguments.

It's bullshit.

Miners that mine on the minority soft fork would lose money. No one can lose money forever.

Luke is preaching this to his followers but doesn't actually believe it himself.

If I am reading him right, it's a pretext to raise awareness for luke's secret utreexo rebase at some near future time. Well fingers crossed he does it and doesn't keep us all anticipating here.

#1278933

reply
102 sats \ 8 replies \ @ynniv 3h

BIP110 is never "activated", because it doesn't provide anything that the other miners won't accept. the "BIP110 chain" is also the regular chain. you'll just get more re-orgs

reply

what about the eventuality where a nonBIP110 miner mines a block that includes a tx that is banned by BIP110?

Doesn't this cause a split?

If the majority of hashrate is not running BIP110, won't we see a BIP110 chain that forks off the nonBIP110 chain?

If hashrate does not go over to BIP110, why would you expect any reorg?

reply
0 sats \ 6 replies \ @ynniv 3h

it's easy to say that you don't want to lose your block rewards. that's what BIP110 is banking on. but what if the BIP100 miners have a dip in hash rate and two blocks are mined that aren't BIP100 compliant? are BIP100 miners going to work at a two block deficit, hoping that they catch up? or are they just going to "start over from here"?

this can go on forever, and the fees on those non BIP100 transactions are going to start getting real fat. what if someone puts two non BIP100 transactions that can't be mined in the same block, each with a 1BTC reward? think that line will hold?

hah

reply
0 sats \ 4 replies \ @Murch 2h

RDTS node runners can’t change the activation mechanism in their software without recompiling, so no, they can’t decide to accept a few invalid blocks after activation to start over at a higher height.

reply
0 sats \ 3 replies \ @ynniv 1h

a voluntary censorship fork ... weird flex but okay 🤷🏻‍♂️

reply
0 sats \ 2 replies \ @Murch 1h

Having a hard time making sense of your reply.

reply
0 sats \ 1 reply \ @ynniv 58m

what's the benefit of running BIP110?

reply
0 sats \ 0 replies \ @Murch 56m

If you think I was arguing for RDTS, you misunderstood me.

0 sats \ 0 replies \ @ynniv 1h

deleted by author

I don't understand your question. The wall of text looks like propaganda of miners/mining pools lobby. As a matter of fact, hashrate is not everything (especially temporary one). Honest nodes play important role too.

reply

My question had to do with Luke's statements.

  1. "Mining against a BIP110 chain requires them to counter-fork."
  2. "Technically under 50% could work too"

I have tried to understand these statements, but I don't see how they can be true...unless one assumes that enough hashrate will soon join the BIP110 side so they have more than 51%.

But if that is the necessary assumption, I don't understand why one would make the claim that "under 50% could work"

Additionally, I have not gotten an even remotely reasonable answer about why a non BIP110 chain must counterfork (and not just ignore) if it has more than 51% of hashrate.

If you can explain either of these positions, I'd be very grateful.

reply

There could coexist 2 chains with 40% (A) and 60% (B) of the pre-split hashrate. Neither of the chains would probably sacrifice their hashrate to attack each other (reorg).

Anyway, chain split probability is low. Most probably malicious miners won't attempt a hardfork in the wake of the activation of the BIP-110.

reply
Anyway, chain split probability is low

This is the most ridiculous statement I've ever heard. On what do you base it? Do you think that the high rate (90%, 95%) of signalling used for past soft forks was chosen because people thought the numbers looked pretty?

And while I have you: this business of defining anyone who disagrees with you as "malicious" is petty. If a miner wishes to continue using their hashrate to mine with rules that sync with the current bitcoin blockchain, that is their choice.

It is your choice to call such a miner malicious, but it sounds childish.

reply

I can't imagine a spammer not being malicious. They shouldn't mine bulky spam, e.g. 100kB (or more) garbage in OP_RETURN. Bitcoin is money. BIP-110 makes it more secure.

It's ridiculous to apply double standards: promoting malicious miners choice (and free-riding) while disregarding choice of honest ones and nodes.

I base the low probability of chainsplit on the fact that malicious miners are greedy and so have strong incentive to follow the Bitcoin network with the BIP-110 security improvement rather than hardforking their own, short-lived chain to mine bulky spam.

reply

A miner who mines a valid tx seems to me to be a factual miner (greedy).

I run a node and have been for years. It hasn't gotten appreciably harder or more expensive.

Storage is the absolute cheapest resource.

But where we really disagree is that I think BIP 110 makes Bitcoin less secure. By arbitrarily picking some previously valid transactions and disallowing them, it damages the confidence bitcoiners have that the coins they hold will be spendable in the future. It sets a precedent for evaluating a transaction not by block validation rules, but some other moral argument. It is no different than the foolish attempts of governments to label certain kinds of speech "bad."

reply

You don't know what you are writing about. Or you are intentionally trolling.

reply

Which statement do you believe is ignorant?