BIP ?: Reduced Data Temporary Softfork

[ABCbits]

User @Satofan44 already mention about this BIP proposal on https://bitcointalk.org/index.php?topic=5539943.msg65973710#msg65973710. But i create this thread to prevent the other thread getting cluttered.


From what i understand so far, the BIP aim to stop some approach/method from putting arbitrary data on Bitcoin TX. I don't expect it'll be accepted though. Aside from being controversial, it has some technical error and may make some Bitcoin UTXO become unspendable. The BIP along with the discussion can be seen on https://github.com/bitcoin/bips/pull/2017. If you just want to know the change, see below quote.

Specification

Blocks with a height from (TBD) 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 nor Taproot/BIP 341) is invalid.
    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.

[BlackHatCoiner]

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.

[Satofan44]

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.

[Donneski]

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.

[d5000]

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:

Code:

OP_0
OP_PUSHBYTES_32 0c5947494638396120002000f20100ff270800000017570df59c0eff6f06fcbb

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.

[ABCbits]

I just noticed this part of the BIP.

Does this cause a chain split?

Generally, softforks do not cause chain splits. However, since we are rejecting an already-mined block proposal, this softfork does indeed cause a chain split. In fact, that is an important part of its purpose: to keep the illegal content storage in block out of Bitcoin.

To achieve this, the softfork must activate retroactively, invalidating that block and all its descendants. The prior segment of the blockchain including this block will eventually (hopefully quickly) be discarded entirely, as the network adopts the softfork proposed herein.

I may be wrong, but i wonder whether retroactively mean undoing few years worth of blocks.

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).
--snip--

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.

[cygan]

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

[stwenhao]

Generally, softforks do not cause chain splits.

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.

I may be wrong, but i wonder whether retroactively mean undoing few years worth of blocks.

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.

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.

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.

[DaveF]

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.

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

[d5000]

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.

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?

[DaveF]

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.

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

[pooya87]

What a weird proposal!

Blocks with a height from (TBD) until and including 987424 are checked with these additional rules:

The logic behind this doesn't make sense to me. Solution should fix the problem not postpone it.

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

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).

Code:

PUSH_33 + OP_CHEKCSIG
PUSH_65 + OP_CHEKCSIG

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.

OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.

256 byte is too big for pushes itself! And when there is an exception like this, it is not solving anything.

Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid.

Again this will make any future expansion (eg. introducing witness version 2+) impossible without splitting the chain.

Witness stacks with a Taproot annex are invalid.
Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.
Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.

Same as previous.
Annex and OP_SUCCESS are already non-standard IIRC.

Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

Not so sure about this after reading the logic in the proposal, even though it sounds weird.

Therefore, there is no time for lengthy signaling periods or careful deployment; the only remaining option is immediate and retroactive activation to mitigate the harm.

However, because this is a softfork,

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?!!!

[d5000]

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

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).

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.

[gmaxwell]

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.

[Mia Chloe]

~snip

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.

[satscraper]

This is an insane proposal that will probably break tons of scripts for solutions that are yet to be penned.

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?

[BlackHatCoiner]

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.

[BlackHatCoiner]

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.

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.

[ABCbits]

This is an insane proposal that will probably break tons of scripts for solutions that are yet to be penned.

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?

It's one of paper where the result unlikely will be applied in reality. From quick skimming, there are some things i could critic.

Thus, we propose to enforce mandatory minimum fees to penalize large transactions and thus disincentivize content insertion
--snip--

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.

D. Self-Verifying Account Identifiers

We propose a simple adaption of standard Bitcoin transactions to make content insertion computationally infeasibl

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.

[NotATether]

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.

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