BIP ?: Reduced Data Temporary Softfork

[BlackHatCoiner]

If it breaks scripts by design, can it really be called a soft fork?

Softfork is invaliding some of what is currently valid. For example, invalidating any transaction that contains OP_RETURN after block 1,000,000 is a softfork, because it breaks all the wallet software that makes uses of OP_RETURN. But it also breaks all theoretical scripts that can be used to solutions that haven't been penned yet. Samourai Wallet used OP_RETURN in whirlpool coinjoin transactions long after it was only used for including arbitrary data.

[d5000]

Meanwhile, back in 2018, researchers ^{who recognized the potential danger of arbitrary data in transactions} have proposed the solution that includes "text detector to identify transactions carrying text or ASCII-based files and (ii) a known-file detector to identify binary files such as images or archives". They also highlited the importance of " mandatory minimum transaction fees to make content insertion economically infeasible".

Apart from the issues already mentioned by ABCbits, I'd add the following problems:

- a text/image detector can only identify codecs that already exist, and here we are again with the cat and mouse games ... the spammers are always faster.
- mandatory minimum fees: We have seen in the Ordinals wave that in the situation of such a "fad", spammers will be willing to pay very high fees (thousands of dollars in some cases, hundreds in many ...). The fees would thus have to be prohibitively high (higher than in the Ordinals wave fee top), so they practically would make Bitcoin unaffordable for all uses with exception of high value transactions.

By the way, @gmaxwell thanks for your explanation, while I think old P2PK outputs would then not be in danger, a lot of protocols would indeed.

[stwenhao]

If it breaks scripts by design, can it really be called a soft fork?

Each and every soft-fork breaks something "by design". It is always about making something invalid tomorrow, which is valid today. Before Taproot, all scripts in the form of "OP_1 <32 bytes>" were valid, as long as these 32 bytes were non-zero. Now, they no longer are, and you need a valid Schnorr signature, or a valid TapScript.

The main problem with this specific soft-fork, is that it can invalidate transactions, which were standard for years (for example 2-of-3 bare multisig). Usually, marking transactions as non-standard, and dropping them, is needed, to discourage usage of things, which could be invalidated by a future soft-forks. But if some mining pools will lift more and more rules, then next soft-forks will be more confiscatory, than they were; or they wouldn't happen at all, if their creators wouldn't know, how to make it properly, without breaking some presigned transactions.

Also, soft-forks can go very far, and it is known since at least 2016, if not earlier: https://petertodd.org/2016/forced-soft-forks#radical-changes

[gmaxwell]

You can use one definition of a softfork that is literally just "a strict tightening of the rules"-- and under that umbrella all sorts of things are "possible" like confiscating everyone's coins.

But that kind of free wheeling anything goes softfork is not something the network has ever accepted, and I expect would never accept.  What has been accepted is a much narrower kind of softfork,  but one we don't have a clear name or conscious definition of.

One element I think that backs every prior softfork and every one that ever will be successful is that it won't have a meaningful risk of confiscating anyone's coins, or at least anyone who wasn't doing something weird and stupid that could easily have been predicted to cause coin loss.  (Bitcoin isn't your mommy and if you want to fire bullets at your feet that's your own decision-- the networks obligation to save you from the reasonable and expected consequences of your bad choices is not significant.)

So, for example, most prior softforks (after Satoshi at least) have used explicit forward-compatibility mechanisms such as future tx-version numbers, segwit version numbers, or NOP-codes.   Now some maniac could have been using those do-nothing fields and caused themselves funds loss when they later got used as intended, but if they were it was an error and for no purpose except perhaps intentionally screwing things up.  For tapscript OP_SUCCESS makes it even harder for any prospective maniacs since any premature use of the forward compat renders the entire script insecure.

There are probably a dozen other such criteria that all existing softfork fits and that any successful one would need to meet... they're not part of a definition of "soft fork" and no one has written them all down or given a name to the class yet but that doesn't prevent them from being requirements and doesn't prevent them from making "but softforks could do almost anything" a useless argument as a prediction about what the network might actually do in the future.

Failing to acknowledge that is kind of like saying bitcoin could be expected to hardfork lots because a hardfork is a rule change, and given that Bitcoin has adopted many softforks (which are also rule changes) it can be expected to make other rule changes like hardforks.  It's a false equivalence that comes from being overly general.

[ABCbits]

Author of BIP announced he made few changes 4 days ago[1]. The general specification isn't changed that much though.

Specification

Blocks with a height from 934864 until and including 987424 are checked with these additional rules:

    1. New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.
    2. OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.
    3. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.)
    4. Witness stacks with a Taproot annex are invalid.
    5. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.
    6. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.
    7. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

Inputs spending UTXOs that were created before the activation height are exempt from the new rules. Once the softfork expires, UTXOs of all heights are once again unrestricted.

[1] https://github.com/bitcoin/bips/pull/2017#issuecomment-3524711494

[Greg Tonoski]

There is the website short URL to the Bitcoin Improvement Proposal BIP-444: "https://bip444.github.io".

[ABCbits]

Jameson Lopp just write a very long blog post about this BIP yesterday, A Layman's Guide to BIP-110. I already aware with most of the argument, but there are few parts i want to share.

11. It doesn't stop embedding of arbitrary data.

This BIP just kicks off a never-ending game of cat and mouse and was immediately proven ineffective by Peter Todd when he embedded the entire text of the BIP into a BIP-110 compliant transaction. (BIP-110 was originally called BIP-444)

No Miner Support

In order to activate "cleanly" without splitting the chain, a soft fork needs a supermajority of miners to enforce it. At time of writing, miners signaling support is precisely... zero.

There's not a rational reason for miners to WANT to support BIP-110 because it only results in to REDUCING the transaction fees they collect. Why would anyone in their right mind voluntarily take a pay cut?

My Predictions

1. As the August deadline grows nearer, BIP-110 supporters will grow more desperate. I suspect it's only a matter of time before some nutjob Knotzi puts child porn into the blockchain as a last ditch desperate measure to coerce miners and node operators via legal threats into their poorly designed fork.

I certainly hope his first prediction won't happen.

[Satofan44]

My Predictions

1. As the August deadline grows nearer, BIP-110 supporters will grow more desperate. I suspect it's only a matter of time before some nutjob Knotzi puts child porn into the blockchain as a last ditch desperate measure to coerce miners and node operators via legal threats into their poorly designed fork.

I certainly hope his first prediction won't happen.

There is no reason why it would not happen, and it would be surprising if it didn't already happen. Both actions that are needed are trivial, finding child porn on the dark web or Telegram and including it into BTC using OP_RETURN. The person who first "discovers" it as embedded recently in the chain will probably be part of the group that did it. If you are not actively looking for this, you won't find it on the chain. Why would anyone want to see that, and even worse present it to the public? To prove a point and fake innocence. Therefore, we can assume that it has already happened. It is just that nobody came out in public with it.

Anyway, the general consensus is that these things are already in the chain and in many others top blockchains as well. Such an inclusion would effectively not change anything, but bringing it up in public that way can cause some harm. The "filter" people clearly have Bitcoin's best interest at heart. 

[ABCbits]

--snip--

I'm aware such thing already happened, even before SegWit exist[1]. I was simply wishing they wouldn't resort to such action, since should know it would hurt overall Bitcoin reputation.

[1] https://bitcointalk.org/index.php?topic=5557375.msg65774888#msg65774888

[tromp]

Both actions that are needed are trivial, finding child porn on the dark web or Telegram and including it into BTC using OP_RETURN.

So is the action of including it into BTC using any of various methods NOT using OP_RETURN.
Possibly some unfilterable methods like fake public keys.
So all the point it proves (for the millionth time) is that Bitcoin is not immune to having arbitrary data embedded in it
That doesn't have all that much to do with OP_RETURN, except for OP_RETURN being designed as the
least harmful way of embedding data.

[Wind_FURY]

Jameson Lopp just write a very long blog post about this BIP yesterday, A Layman's Guide to BIP-110. I already aware with most of the argument, but there are few parts i want to share.

11. It doesn't stop embedding of arbitrary data.

This BIP just kicks off a never-ending game of cat and mouse and was immediately proven ineffective by Peter Todd when he embedded the entire text of the BIP into a BIP-110 compliant transaction. (BIP-110 was originally called BIP-444)

No Miner Support

In order to activate "cleanly" without splitting the chain, a soft fork needs a supermajority of miners to enforce it. At time of writing, miners signaling support is precisely... zero.

There's not a rational reason for miners to WANT to support BIP-110 because it only results in to REDUCING the transaction fees they collect. Why would anyone in their right mind voluntarily take a pay cut?

My Predictions

1. As the August deadline grows nearer, BIP-110 supporters will grow more desperate. I suspect it's only a matter of time before some nutjob Knotzi puts child porn into the blockchain as a last ditch desperate measure to coerce miners and node operators via legal threats into their poorly designed fork.

I certainly hope his first prediction won't happen.

That WON'T happen because there was no intent by node operators and the miners to put or retrieve child porn in the blockchain - a decentralized database that ANYONE could put data into.

The person with malcious intent in J. Lopp's example is actually the person who PUT the data INTO the blockchain.

Although I don't what that to happen, I'm also curious "what would happen".

[DaveF]

No Miner Support

In order to activate "cleanly" without splitting the chain, a soft fork needs a supermajority of miners to enforce it. At time of writing, miners signaling support is precisely... zero.

There's not a rational reason for miners to WANT to support BIP-110 because it only results in to REDUCING the transaction fees they collect. Why would anyone in their right mind voluntarily take a pay cut?

That's not entirely true.
Ocean supports it.
Now do all the people who are pointing their miners to that pool support it?

That is an interesting question.

I sent some hash there when they 1st opened but moved back to my old pool quickly since their payout structure did not work for me. But even with a quick look now, I don't see any mention on their homepage of 110 support.


-Dave

[Wind_FURY]

No Miner Support

In order to activate "cleanly" without splitting the chain, a soft fork needs a supermajority of miners to enforce it. At time of writing, miners signaling support is precisely... zero.

There's not a rational reason for miners to WANT to support BIP-110 because it only results in to REDUCING the transaction fees they collect. Why would anyone in their right mind voluntarily take a pay cut?

That's not entirely true.
Ocean supports it.

Now do all the people who are pointing their miners to that pool support it?

That is an interesting question.

I sent some hash there when they 1st opened but moved back to my old pool quickly since their payout structure did not work for me. But even with a quick look now, I don't see any mention on their homepage of 110 support.


-Dave

Ocean Mining is a mining POOL, not a miner that generates its own hashing power. But WHO are those miners that are pointing their hashing power in Ocean?

  ¯\_(ツ)_/¯

They probably will need to point their hashing power to another pool before the August deadline.

[Satofan44]

--snip--

I'm aware such thing already happened, even before SegWit exist[1]. I was simply wishing they wouldn't resort to such action, since should know it would hurt overall Bitcoin reputation.

[1] https://bitcointalk.org/index.php?topic=5557375.msg65774888#msg65774888

Yeah you should not make wishes or have expectations about desperate and malicious people, instead you should expect that they will do the worst thing they can imagine. The people that are pushing this topic, consciously or not, are harming Bitcoin already.

Both actions that are needed are trivial, finding child porn on the dark web or Telegram and including it into BTC using OP_RETURN.

So is the action of including it into BTC using any of various methods NOT using OP_RETURN.
Possibly some unfilterable methods like fake public keys.
So all the point it proves (for the millionth time) is that Bitcoin is not immune to having arbitrary data embedded in it
That doesn't have all that much to do with OP_RETURN, except for OP_RETURN being designed as the
least harmful way of embedding data.

You are absolutely correct with this, my point was more that this does not change anything. The correct assumption is that there are all sorts of illegal data in Bitcoin, embedded in a variety of ways. So if someone does it now using the big OP_RETURNs to make a point I would not exaggerate the significance of this. It would only be significant if there was no illegal data of such kind in Bitcoin before, and thereby that would be the first case of CSAM content or other illegal data in the chain.

Ocean supports it.

Ocean can be considered a hostile and malicious actor at this point. They are a mining pool only for being clear on the terminology.