Topic: Soft forks (Read 173 times)

Very good points indeed, thanks for highlighting this!

I didn't mean to give the impression that anything I mentioned is a fix-- they're all just incremental steps. The way I look at it, attacks are a question of incentives so even if we can just increase the cost a little or the effectiveness a little, or even just the uncertainty of the effectiveness, we're making it less likely that an attack is even attempted.

w/ Taproot you reveal only the clause you are executing, but not any of the other independent clauses.  So, for example, if your use case is only distinguishable by the sum total of the options from other activity-- then taproot hides it.  For example: if your spending possibilities might be "Cooperation" or "fallback A" or "fallback B"  and each of these options occurs separately as options in other kinds of transaction that miners wouldn't want to block, then yours can't be distinguished because all the miners see is the one option you used.

Just the fact that cooperation is indistinguishable from a boring spend is valuable on its own however--- for example,  the fact that miners could collude to make a particular fallback branch unreliable but users could still cooperate means that they couldn't e.g. straightforwardly freeze all funds that had been setup for use with that particular contract--  only those funds that were AND where cooperation wasn't possible.

I probably should have also mentioned P2SH as a big advance in this area (since it prevents block outputs with a specific script structure),  also scriptless scripts as useful ongoing research work along these same lines.

Thanks for the informative post, there's indeed a lot of food for thought in it!

I'm just wondering about this bit:


As far as I understand it, taproot allows you to build contracts whose "cooperation clause" is indistinguishable from ordinary payments.  But if you need to use a different branch of the contract (e.g. because you want to invoke a timeout condition and your transaction partner is not cooperating), you have to reveal it.  Wouldn't that mean that miners can again censor certain usage types?  Because even if they cannot censor the normal operation of some system like Lightning, I need to be sure that I can also get my transactions confirmed even if others on the contract do not cooperate.  (For instance, to close a channel if the other party is misbehaving.)  So if miners are censoring those transactions that invoke non-cooperative branches of a constract, then that effectively also censors the entire usecase.

Or am I misunderstanding how taproot works?

(I'm not saying this makes miner censorship a practical problem, since all the other reasons you cite are very valid.)

A majority of hashpower can add softforks.  They don't even have to publish software that are compatible with them, but they could.

For all we know-- there are some of these active now, invisible to us. -- though probably not.

The way carlton described it up thread-- it's not obvious why it could even be a problem.  If it was just some new transaction feature and it was useful and not bothering anyone else... then it might well be not a problem.  But it can take other forms where it clearly is a problem.

This has been raised as a weakness in Bitcoin's history-- and some have looked to solve it.  Usually the context it discusses is softforks that block a particular user (e.g. Bad Guy Bob) or style of transactions (e.g. Lightning payments).   Sometimes people have been concerned with fluffyforks-- ones where the rule will be bypassed if a violating chain gets ahead.

But it appears to be fundamentally hard to solve because a miner imposing a soft-fork is indistinguishable from an unmodified miner operating behind a network filter that hides certain transactions/blocks from it.  You could make sure they weren't getting filtered if there was some consensus about their inputs ... yo dawg I hurd u like blockchains.

There is obviously the nuclear option: If a majority hashpower is disruptive enough the users of Bitcoin will take some extreme action like changing to a new POW ...  But not only would that path be dangerous and disruptive (making it a less potent threat), it's unlikely to work if the attack is only harming a few users ("so sad Wikileaks can't move their funds, but not my problem").

So the open questions are: Are their less extreme defences than the nuclear option, is there a way to amplify attacks so that any amount of attacking will trigger the political will to fight back, can malicious softforks be stopped?

There has been advancement in a number of these dimensions.

Detection:   now that the network is operating against the weight limit most of the time there is little reason to have valid transactions rejected (except for forward compatibility reasons)--- transactions really should be being accepted in a fee-rate sensible order, and if they're not thats clear and detectable. So if it started happening at any scale, we could probably see it.

Amplification:  Coinjoins and sendmanys  link together the spends of multiple users, you can't block one input in a transaction without blocking them all.  More researchy right now, but non-interactive aggregate signatures have the property of building transaction bundles that cannot be unlinked. Both result in disruption amplification and additional fee income loss for miners that censor.

Indistinguishably:  Taproot should make different kinds of transactions much more indistinguishable (and an older technology, the coinswap transform can have similar indistinguishability benefits without taproot), and if usage types can't be distinguished they can't be targeted.  Similarly, privacy improving practices (avoiding reuse, coinjoins, swaps, anti-network-monitoring, p2p encryption)  can get in the way of censoring based on who's transacting.

Anonymous mining:  The system's existing incentives discourage leaving out any economical transactions -- after all, you'll miss out on their fees. But external pressures might make you act in ways that aren't rational within the system.  Tech like compact blocks, satellite block transmission, and not bloating the hell out of the maximum block size preserves the at least the threat that a lot of mining could go dark.

Mining distribution/security:  These attacks assume a majority hashrate is colluding against user interests. That's easier if mining is more centrally controlled. Betterhash/stratum2 make some steps in the direction of improving that.  There is probably a lot more to do to further decentralize mining control-- and this area has probably the least progress and some of the most importance for this issue.

In any case,  -- I hope this is some food for thought.

That is certainly an interesting thought.  But I think at least in the case of a soft fork like segwit or BIP16 (which adds new transaction types that are only "secure" with the new rules), step 5/6 is quite risky.  As long as others are not enforcing the fork yet, everyone runs the risk of losing money if they already use those tx.  Even if they are submitted privately to the pool who enforces the rules, an attacker could just try to orphan one of the pool's blocks to steal funds from the tx in there.  (And stuffing their own blocks with tx like that would be risky for the pool - they likely need to include a lot of money in those tx as well for it to look realistic, and then someone could steal the pool's money if they orphan a block.)

And especially if the pool tries to make it look like "everyone is using the new feature already" (step 6), it would look quite suspicious that a lot of people were risking a lot of money in a way that is not yet secure at all.  So I doubt a) real people would start using such a fork before it is agreed and enforced, and b) others would believe the pool that lots of users already are, even if they stuff their own blocks.

But of course it depends on the concrete circumstances in the end.  Like the nature of the soft fork, and also how well the pool in question can perform the social engineering.  My argument assumes people are critically thinking and aware of the technical details, which might not be true enough....

i've definitely been here too long

no, that's not really what I'm thinking of. I mean the whole sequence of events the other way round


1. big miner/pool thinks of a forking change to consensus
2. miner/pool implements it as a softfork
3. miner/pool releases new Bitcoin client with softfork included
4. miner/pool accepts the supa-dupa new tx's over their website (or maybe bake that into the client)
5. miner/pool begins including transactions in it's blocks, because no other miners are
6. miner/pool can inflate success of the fork, by stuffing blocks with tx's that they made themselves
7. miner/pool hopes everyone will follow the fork, bouyed by the (faked) success

I guess a reason against the strategy would be the same as was discussed upthread: if another miner/pool wanted to take the opportunity to add to the uncertainty of this situation, they could look for a way to force a hard fork right at a critical point of the soft fork's acceptance (i.e. ~50%). Although that would also be a risk in of itself, as there is no direct way to know whether those signalling support are actually running the putsch-client (does this actually imply a positive incentive for miners not to run an upgraded client while signalling readiness, until the readiness signalling level is very high?)

https://bitcointalksearch.org/topic/m.45966212

It was this one.


That makes me feel like it was a hard fork but I haven't read the thread since September 2018 so... One things certain: I've been here too long 🤣.

which vulnerability was that? I don't recall anything that needed a soft fork (or where the miners were proposing changes instead of the devs)

This was actually done recently from a vulnerability found on the bitcoin network (wasn't social engineering though) the core devs asked a load of miners to update their software but I think bitmain still held a majority share at the time (40-55%) but if the 95% compliance is necessary this won't be enough and I assume a lot of miners reviewed the code before updating it (or we can at least hope they did). You'd probably also have to make it look like you knew what you were talking about too and probably reference the code adjustments and how they can add and compile them from source.

---

I reported this thread from your second post in the hope it could be split into a new topic as it'll be an interesting standalone thread.

so here's an attack (with a significant social engineering angle) I thought up that large miners/pools could attempt. Could it work?


Right now, anyone-can-pay can be used as a wrapper around a transaction that subscribes to any fantasy soft-fork. Regular people with no hashpower cannot try to popularize a fork they like by getting such transactions confirmed, as the network will ignore the fantasy rules, and simply allow whoever picks the money up of the ground to do so. Someone using that strategy is no more than a cough in a stadium full of voices.

But big miners/pools could start a public campaign for their preferred soft-fork, and launch a Bitcoin client that can perform the transactions that observe the new rules. Then they can mine these transactions themselves out of band, to ensure users that other miners/pools won't allow picking the money up off the sidewalk. And of course miners/pools can artificially inflate the numbers of people using their minority soft fork's rules, simply by stuffing blocks with their own transactions using the same rules.

Maybe it's a high risk strategy, but the bigger the miner/pool, the more likely they could pressurize the overall marketplace to fully endorse their softfork, thus taking (some) control of protocol development. How much control they could attain depends alot on the nature of the fork.... not sure, what do we all think about this? willing to take this to a new thread also

Yes, well kinda. For most softforks no remotely recent mining software will provoke a hardfork.

I believe that someone to erroneously mine a segwit invalid block with unmodified I think would have required they use software from 2012. ... cleanstack was added later than that, but before cleanstack there were rules to only allow standard transactions.

But they could also do it intentionally and the non-upgraded hashrate would follow them. Having a high hashrate guarantees that any such fork will be short... which protects non-upgraded users and spv wallets from seeing a big reorg. If there won't be a big reorg then there isn't much incentive to do it intentionally.

I now understand better the reason for having a high (95%) signalling threshold for entering soft fork activation periods; hard forks can be provoked with transactions that are crafted to break the rules introduced by the soft fork. So I guess something small was achieved out of all of this to-ing and fro-ing

This post of yours is what I am referring to (here quoted in full).  In here, you imply that the quoted statement here (not the other about "new rules" which I'd say is still not wrong, just formulated in a misleading way) is wrong, or what you "disagreed with".  But if you now agree this statement is correct and you no longer disagree with it, then all is clear to me.  (And if you already agreed to it earlier, I must have overlooked that in your previous post - sorry for that.)

The definition of a soft-fork is pretty widely spread and firmly established, so I don't think it can really be changed.

Also the safer subset that Bitcoin does in practice is much harder to define precisely.  For one, many softforks have been unsafe with respect to sufficiently old code that no one is using anymore-- particularly, before 'standardness' was introduced, nodes would relay and mine arbitrary scripts including explicit forward extension stuff,  ... a long time ago nodes would also mine transactions with arbitrary version numbers, etc.

Besides, the term softfork stinks because there isn't even necessarily any fork at all. ... particularly in the case of the safer ones.

i don't care to really

(i've since then agreed already that it's possible, why are you ignoring that?)


here's what we're supposed to be discussing:


this is wrong, by any definition

you've agreed it's wrong. you're not helping anyone in particular, least of all the OP

Yes indeed, that's what I'm saying.


Ok, so I see where the confusion comes from - my original post above is probably not worded in the best way.  However, this one is clear IMHO:


But you claim to disagree with that exact quote.  Can you please explain what you think is wrong about this formulation?

ok, well it's difficult then to see how any soft fork can be implemented without an inherent risk of a hard fork. You're basically saying that pre-fork nodes are blind to the new rules, and so one can break the new rules without the pre-fork nodes being aware, that's perfectly sensible.

But you're still wrong. The old nodes are not "accepting the new rules", as you said. They cannot be accepting any new rules, because they are not designed to recognize rules that did not exist before that version of the consensus rules were written, Bitcoin does not (yet) have an algorithm that can see into the future!

What's happening is that they do not understand any new rules, and blocks with transactions adhering to any new rules are interpreted as "no signature required", i.e. anyone can pay. How else, logically, could old nodes be capable of accepting tx's that both observe and violate a new soft-fork? It's because they don't know what the new rules are that they are able to accept both, that's how anyone-can-pay can function as a backwards compatible upgrade mechnanism, because it enables nodes following only the older rules to ignore any and all assessment of adherence to new rules with 1 universal rule: "this transaction is valid, because it has no spending conditions". Saying that's the same thing as accepting new rules (which you did) is not accurate.

You seem to be dancing around the semantics, for reasons that are

1. Not obvious. What is this achieving
2. Not relevant to the OP anyway


I could instigate an attack on the ambiguities of the way you've worded things too, but I'm not going to do it. Why do you think that is?

Actually segwit has cases like this.  As I wrote in my last post, if you take a segwit transaction and strip the witness data off it, then it will be a valid transaction under the old rules but not valid in the new ones (because it is missing the witness).  Adding restrictions like this (in the case of segwit, that the witness is verified in addition to the old-style signature) actually is the only point of a soft fork, and hence why you may call it "enforcing segwit".  gmaxwell's mention of "safe" is very useful in the context of this discussion, but if you re-read his answer precisely, it only states that that means "extra care" is taken.  My quote above, as it stands, is correct as far as I can tell.

Perhaps it is easier to illustrate this with the BIP16 soft fork instead of segwit.  In this case, the validation rules for scripts were modified, so that

OP_HASH160 [20-byte-hash-value] OP_EQUAL

would be validated according to the old rules (i.e. you need to provide a preimage for the published hash), but also the preimage itself must validate as script.  Pre-fork, you could spend a P2SH output by simply knowing the redeem script itself, even if you did not provide valid signatures for it - because that is what the script above says.  The soft fork then introduced the bolded extra rule, so that P2SH would work meaningfully.  But this means that you can produce blocks and transactions that are valid for pre-BIP16 nodes but invalid with BIP16.  There is one pre-BIP16 block, 00000000000002dc756eebf4f49723ed8d30cc28a5f108eb94b1ba88ac4f9c22, which actually has this situation - it is valid pre-BIP16 (and is valid because it was created before the soft fork), but it would not be valid anymore now due to the added restriction.

But maybe we are just misunderstanding each other's meanings.  I think the OP's question related to the use of "old mining pool software" has been answered.

ok, instead of fanning the argument out into things everyone agrees with, let's stick to the point I disagreed with:


that didn't happen with segwit, it was implemented using the so-called "safe" soft fork design

you implied it could, and that was wrong

Why do you say that's not possible?  In the case of segwit (and a soft fork in general), old nodes will accept transactions and blocks following the new rules - in your terms because soft fork.  They will simply see an "anyone can spend" signature.  (This assumes that you do not send them witness data they do not understand, but that is part of the network protocol and not the consensus rules.  You could also discuss a softfork of "reduce block size" to make it simpler to understand.)


Sorry, but that's just what a soft fork is.  Segwit introduced new rules, namely that in addition to the pre-segwit signature validation, also the witness needs to be valid.  If you take a segwit transaction and remove its witness, it is perfectly valid under the old rules and will be accepted by old nodes.  But it won't be accepted (without the witness) by nodes following segwit rules.  In other words, if you were to build a block of segwit transactions without the witness data, then old nodes would accept the block while new nodes would reject it.  That's exactly what a soft fork is.

The reason why that is useful (and thus why a soft fork is better than a hard fork) is because this allows nodes and wallets running according to the old rules to remain working, since they will accept anything that used to be valid before.  (Just their security might be reduced to SPV level.)  But if you do a soft fork and miners also do not upgrade, then yes, you get a chain fork.  (Which is why there were things like BIP9 signalling required from a majority of nodes.