BIP 110: Temporary Softfork with Reduced Data

User @Satofan44 already talked about this BIP proposal here, but I thought I'd start a new thread to keep things organized. From what I've gathered, this BIP is trying to prevent some methods of adding arbitrary data to Bitcoin transactions. Honestly, I doubt it'll get the green light. It’s pretty controversial, has some technical flaws, and could render certain Bitcoin UTXOs unspendable. You can check out the BIP and all the discussions around it on GitHub. If you just wanna see the changes, I've quoted them below. Edit: It’s now available on GitHub as well. Update: Here are some links to blogs and articles that talk about this BIP.

This is an insane proposal that will probably break tons of scripts for solutions that are yet to be penned. Information theory teaches how it is futile to try to stop "spam", as it can take nearly infinite forms. Any attempt to stop information from being able to spread is against this principle. I'll gladly sell my BCashJr forkcoins for bitcoin.

This proposal is confiscatory and will therefore by rejected in its inception. Luke-jr is a compromised and greedy religious nutjob. If he wasn't we would not have to deal with this situation. Don't let them mislead you by telling you this is about his views or some other crap. If we let this proposal pass, which we won't, the consequences would be along these lines: Draws attention to more miner regulation and censorship.Sets a precedence for using legal threats to pass a BIP.Sets a precedence for coin confiscation using a fork.Other. If it is not clear to someone that luke is compromised, it is time to wake up.

I get the idea of trying to make Bitcoin lighter and prevent unnecessary bloat but honestly this BIP feels like it’s crossing a line. The moment a soft fork starts risking existing UTXOs or limiting how people use block space, it stops being about optimization, it then becomes control. Bitcoin was never meant to be “tidy” or restricted to one idea of usage. If a proposal can break valid transactions just to enforce someone’s version of purity, then it’s not an upgrade, it’s a red flag. We should be very careful before entertaining anything like that before it becomes a norm in the Bitcoin network.

First, I appreciate that this is at least a proposal, and at least tries to limit the fake public key problem somewhat (it would for example not allow P2MS anymore due to the 34 byte limit). However, as far as I understand it, this would only add a little bit more overhead to "spamming". And if I'm not incorrect, it would not stop the OLGA stamp protocol, which is currently one of the most used Stampchain-style "fake public key" protocols for up to 64 kB of data (which allows images) per transaction. See the following transaction for a typical OLGA output: https://mempool.space/tx/926920c4adce5f3fa2171ee4be337c79eb1aa580295bf7ea38e1a52e2276f613 This transaction contains a lot of the following P2WSH outputs which have exactly 34 bytes: I also think that the "sidechain commitment hash use case" (Citrea example) should not be blocked. So if it were for me, I would limit OP_RETURN to 160 or 256 bytes.

I just noticed this part of the BIP. I may be wrong, but i wonder whether retroactively mean undoing few years worth of blocks. But it also reduce OP_RETURN size limit, which give people incentive to use certain approach of fake pubkey that is cheaper than using OP_RETURN with the new limit.

all these changes that bip-444 would entail would mean a softfork in the Bitcoin network the main argument of the proposal is that the Bitcoin blockchain should not be misused as a repository for illegal or unethical content. it should only be used for financial transactions

Only if they are properly activated, and supported by the hashrate majority. Otherwise, a soft-fork can end up on a minority chain. For example: if "Knotcoin" would have 1% hashrate support, and "Corecoin" would have 99% hashrate support, then "Knotcoin" would have an option: to activate a soft-fork, and end up on a minority chain, which would produce a block or two per day, until it would adjust the difficulty, or to not activate it, and try different ideas. Also, I don't know any coin, which would be properly protected from a hashrate majority, working on a different chain. For example: chains like BCH or BSV are not protected. If BTC miners would have enough incentive, then they could constantly attack these coins, and trigger endless chain reorganizations. The main reason why they don't, is the lack of incentive. Because it is often better to leave alone the group you disagree with, than to try to cause more drama. Which means, that if the soft-fork will be proposed, and some support for it will be measured in that way or another (for example by checking version bits in block headers), then later, one group can become disappointed, no matter if the community will decide to activate it or not. And then, if people would still talk about forks (hard or soft), without thinking about other solutions, then we will just have more altcoins as a result. People can do whatever they want. They can start a new chain, where the Genesis Block is different, and no longer has a data push of the "Chancellor" message. Or they can decide, that everything should be built on top of the block number 123456. It doesn't matter. Solving a problem with forks (hard or soft), which has a known solution, without any forks, is stupid. If people don't understand it, then it is their problem, if they will land on an altcoin, as a consequence of their decisions. Also, the solution, where Initial Blockchain Download is changed, is forkless, and allows addressing existing spammy transactions. Which is yet another reason, why making any kind of fork is stupid, to solve this problem. There are worse problems, for example confiscating potential presigned transactions, sending coins to things like 1-of-2 bare multisig. For example: imagine if someone made a transaction in 2009, and timelocked it to 2026. If the output of such transaction is a bare multisig (which existed back then, and was standard, and valid; and it is still standard today), then that person would perceive the soft-fork to be confiscatory. Another important problem, is that temporary soft-forks were never tested in practice. Who knows, if these temporary restrictions will be lifted in the future or not? One of the outcome could be, that we could have a soft-fork now, which could turn into a hard-fork later, when one of the groups would decide, that they don't want to deactivate soft-forked rules. And then, it could end up with a hard-fork, especially if there would be any minority chain, supported by many miners, but not the majority.

Except you will not have any BCashJr coins. He will either loose them due to his poor security: https://bitcointalk.org/index.php?topic=5432665.0 Or mine them out of existence if he does not like you: https://bitcointalk.org/index.php?topic=56675.0 Or just filter the transactions: https://bitcointalk.org/index.php?topic=816578.0 As you can see from the last link he has been trying to shrink the bitcoin use case for over a decade. Yet people still follow him. Can't wait till they leave and their coins fall like BCH and BSV Side note, kind of funny but for all the people saying it's difficult or expensive to run a "big node" just spun up a new node for someone. The PC is a bit over 10 years old (summer 2015) running with DDR3 and a 7200RPM drive. So more or less a paperweight by today's standards.  Actually started it last week but we had internet issues at the office from late Thursday until mid morning Monday and just checked and a nice new 30 node is running. No idea when it actually finished. Probably sometime yesterday. So at MOST 4 days of working internet from installing windows & updates and fully syncing core. -Dave

Yes, correct. The "I appreciate" was more directed at the idea that the faction around Luke-Jr has always criticised and never delivered any consensus based proposal which would have actually any effect, only filters which are actually not effective at all. This proposal would have an effect, it would make data storage slightly more expensive, but at least compared to OP_RETURN not really by much (about 25% afaik). The OLGA protocol is quite efficient storage wise, only 2 bytes in the ScriptPubKey, 1 byte for the script length, and the 8 bytes to encode the amount of satoshis is needed per output. You have thus 11 bytes of overhead per 32 bytes encoded. So the fee is only slightly higher than for a single large OP_RETURN. The only other cost component is that you have to burn 11 satoshis per byte due to the dust limit. In a low fee scenario this is the main cost, but if fees rise to >10 sat/vbyte again, the transaction fee becomes more costly. It is quite funny that they propose to ban bare multisig if the bare multisig storage method actually seems to be less efficient ... (at least according to the Stampchain website). I also oppose the totally rushed and *cough* intransparent way this BIP is delivered. Couldn't Luke at least have had the balls to propose it himself?

Well thankfully it's been locked on github until dathonohm luke comes back to explain some things. Like that's going to happen. Hopefully they just fork off and leave everyone alone like BCH. -Dave

What a weird proposal! The logic behind this doesn't make sense to me. Solution should fix the problem not postpone it. That would make all P2PK outputs (aka perfectly valid and standard outputs) unspendable (35 and 67 bytes) locking possibly thousands of bitcoins (mostly the reward for early mined blocks). Also as it was pointed out it would make future use cases that may need larger pubscript size impossible without splitting the chain since the nodes would reject them as invalid. 256 byte is too big for pushes itself! And when there is an exception like this, it is not solving anything. Again this will make any future expansion (eg. introducing witness version 2+) impossible without splitting the chain. Same as previous. Annex and OP_SUCCESS are already non-standard IIRC. Not so sure about this after reading the logic in the proposal, even though it sounds weird. Hold on a minute there. This is NOT a soft-fork. This is an attack on Bitcoin and its principles. I feel like this is BIP148 attack all over again saying "we are going to activate without giving a shit what the majority says". Wasn't Luke advocating for that attack as well?!!!

I agree with the rest of your post, but isn't the wording "new output scriptPubKeys" referring to outputs created in new transactions which wouldn't be included anymore in blocks if this ever activates? In this case, old P2PK outputs would not be affected as they are already included into blocks. I've read the proposal again now, but didn't find anything that this rule would be applied to the spending of existing, accepted outputs.

New is not good enough to give a guarantee of no-confiscation, because people can (and do) have presigned (and potentially also timelocked) transactions that can't be replaced and haven't shown up in blocks yet (and if timelocked can't show up in blocks yet). It's fine that you weren't aware of this but anyone who isn't hasn't studied the history of consensus changes in any detail since it's been in  consideration in ~all consensus and policy adjustments since the time of Satoshi.  It's also why OP_SUCCESS in tapscript works the way it does-- so that opcodes can be added without any risk of making a previously secure output unspendable.

well I like your explanation of how soft forks depend on hashrate consensus and why rushing into them can be risky. Personally I think it also shows how much Bitcoin’s governance actually depends alot on social consensus as much as technical enforcement like miners can produce blocks but it’s actually the broader majority of users and developers that decides which chain actually holds value. Even if a minority fork keeps running it’s basically meaningless if the network ignores it. The point about forkless solutions is a strong one too which  could improve how the Initial Blockchain Download works or creating smarter validation logic could solve certain issues without actually splitting the network. But the thing is some protocol level fixes like enhancing long term scalability might eventually need coordinated soft forks but only if they’re approached with broad support and likely clear reversibility and transparency. Otherwise as history shows even small disagreements can quickly turn a temporary update into a permanent divide that creates another network.

Thus, instead of solving the problem, this BIP leads to other, more serious issues... it's almost ironic. 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". What do you think about this?

I don't know what research they have made. What I know, is that arbitrary data inclusion can become indistinguishable from regular bitcoin transactions simply by dividing data in chunks of 256 bits, and by paying those witness hashes. This way you get segwit discount, and there's absolutely no way to prevent this, unless you softfork into preventing any output from having a value less than x. There's also more ways to include arbitrary data, by playing with cryptography, spending from a witness hash etc., depending how much creative you are.

Economic majority has the final word. At first, some miners would mine BTC, while others BCHjr. If I'm not mistaken that's what had happened with Bitcoin Cash at first. When the economic majority of BTC started selling BCH for BTC, that devastated the price of BCH, and thus made miners more incentivized to mine BTC. Miners can control which fork will remain alive over the short term, but considering they're mining a fork with less economic power, they can't keep burning money forever. Eventually they will submit to economic majority, or go bankrupt.

It's one of paper where the result unlikely will be applied in reality. From quick skimming, there are some things i could critic. It will discourage custodial service to perform batch transaction, where they will create multiple smaller TX that have bigger total size in either byte or weight unit. I also doubt it can be applied without hard-fork. I recall this idea have been discussed on this forum. But it wouldn't work since spammer could continue to use old address format and i'm not sure it can be applied to Taproot.

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