bitcoin
BIP 110: Reduced Data Temporary Softfork
Mailing list thread at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8
Editor note: please post conceptual feedback and meta-commentary on the mailing list thread, and focus here on:
- expert technical review of the specification
- specific, concrete, helpful proposals for the other sections
Please refrain from personal or heated commentary, trolling, pedantry, and repeating yourself. As this PR now has many comments, please only comment if you are adding new valuable information to the discussion.
I suggest you add an FAQ item for “why block 987424“. If the intent is to have it be a year out, the height might actually move during discussion, and right now its just a magic number in the document.
There is opportunity to also discuss the effect on DoS blocks and the scope of legacy script as a DoS vector.
Will or can this softfork affect lightning or currently planned upgrades of it?
btw, fwiw, there's also some discussion at https://stacker.news/items/1265553 (sorry for the shameless plug, I work at SN)
According to BIP-2:
Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the Bitcoin development mailing list.
When will this be posted to the mailing list as its own thread so it can get greater attention & review?
Blocks with a height from (TBD) until and including 987424 are checked with these additional rules:
New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid. 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. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.
It is possible to write the motivation, rationale etc. for these proposed changes without legality non sense. That would make it easier for reviewers and reduce the noise in the pull request.
When will this be posted to the mailing list as its own thread so it can get greater attention & review?
I reached out yesterday to suggest this and apparently the post is currently in the ML queue for acceptance/publication.
When will this be posted to the mailing list as its own thread so it can get greater attention & review?
Hi all, a mailing list post by has been published by the BIP author at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8.
Post conceptual feedback and meta-commentary there, and focus here on:
- expert technical review of the specification
- specific, concrete, helpful proposals for the other sections
Please refrain from personal or heated commentary in both venues. I've attempted some minor moderation here above.
NACK
The fact that transaction txid 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c contains the full text of this BIP as of writing, while also being compliant with this BIP shows how utterly ineffective this approach is.
Concept ACK
The fact that transaction txid [...] contains the full text of this BIP as of writing, while also being compliant with this BIP shows how utterly ineffective this approach is.
By needing to resort to data obfuscated as code vs using the only sanctioned method of data carrying (OP_RETURN) in order to comply with the BIP, you've in fact actually just proven that the BIP can be completely effective at mitigating the outlined risks. So, thanks for proving that point for everyone.
I've run some initial tests, the miniscript compiler will use OP_IF and OP_NOTIF for taproot descriptors if you don't break it out spending conditions into specific tapleafs explicitly, so this would be freezing those funds on chain (or confiscating if this was extended indefinitely).
Concept ACK
The fact that transaction txid [...] contains the full text of this BIP as of writing, while also being compliant with this BIP shows how utterly ineffective this approach is.
By needing to resort to data obfuscated as code vs using the only sanctioned method of data carrying (OP_RETURN) in order to comply with the BIP, you've in fact actually just proven that the BIP can be completely effective at mitigating the outlined risks. So, thanks for proving that point for everyone.
If that was the point, the proposed soft fork would only be narrowly limiting to OP_RETURN, and not MAST and OP_IF.
If that was the point, the proposed soft fork would only be narrowly limiting to OP_RETURN, and not MAST and OP_IF.
It's one point of many.
Addressing simple low hanging fruit currently exploited or that could obviously be exploited makes perfect sense for a soft fork intended to limit arbitrary data.
To be clear as well, there is no confiscation risk here at all. At worst there is a potential inconvenience risk to some outlier edge cases that may or may not exist. But as a temporary soft fork those issues can be addressed without the need to hard fork to refine these changes.
I've run some initial tests, the miniscript compiler will use OP_IF and OP_NOTIF for taproot descriptors if you don't break it out spending conditions into specific tapleafs explicitly, so this would be freezing those funds on chain (or confiscating if this was extended indefinitely).
@Rob1Ham Important finding. Can you share which miniscript implementations and provide example descriptor/s that generates OP_IF/OP_NOTIF?
Two possible solutions:
- Pre-activation UTXO exemption (which could also be used for the taproot control block issue where coins can become unspendable)
- Narrow restriction to OP_IF with unexecuted push data >256 bytes (targets spam, not legitimate branching)
I've run some initial tests, the miniscript compiler will use OP_IF and OP_NOTIF for taproot descriptors if you don't break it out spending conditions into specific tapleafs explicitly, so this would be freezing those funds on chain (or confiscating if this was extended indefinitely).
@Rob1Ham Important finding. Can you share which miniscript implementations and provide example descriptor/s that generates OP_IF/OP_NOTIF?
Two possible solutions:
Pre-activation UTXO exemption (which could also be used for the taproot control block issue where coins can become unspendable)
Narrow restriction to OP_IF with unexecuted push data >256 bytes (targets spam, not legitimate branching)
Miniscript as is will use fragments that leverage OP_IF/OP_NOTIF if you don't break out each spending conditions (where you'd use an OR) into a separate leaf.
If you declare each spending condition to be its own tap leaf, it won't use OP_IF/OP_NOTIF (from my limited testing, reviewing the rust-miniscript compiler would determine if they do appear with tap script).
NACK. This proposal provides an economic incentive for on chain CSAM.
A bad actor who wants to conduct a double spend attack, could put CSAM on chain to cause a re-org and succeed with the attack.
I think the language needs work.
The original draft offered by Luke assumed a post-hoc fixing of a block containing untenable content which this BIP does not offer as the preferred approach thereby making the multiple references to legal implications needlessly inflammatory.
Therefore I suggest removing them so that we can focus on technical concerns around what these new rules would limit - of which there are a couple but are getting drowned out.
Certainly for me the benefit of reducing arbitrary data is that it makes Bitcoin a more efficient monetary system and helps preserve decentralization of nodes so this BIP makes sense on that basis alone.
The following are unrelated to the stated motivation of the BIP (and its sense of urgency) which is to address potential issues from OP_RETURN relay policy changes introduced in Bitcoin Core 30
- Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid.
- 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.
- Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.
The fact that transaction txid 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c contains
Does it? I followed that link to the transaction on Mempool. I can't see anything other than a lot of inputs into a transaction and it costing $110... How can I see what you are claiming?
A bad actor who wants to conduct a double spend attack, could put CSAM on chain to cause a re-org and succeed with the attack.
If this is the case, then I suggest to implement this ASAP, rather than give a bad actor the ability to plan the attack.
Concept ACK
However, if the Code consensus approved, I suggest deployment immediately, rather than watching (and possibly missing) and waiting for an attack that could well be co-ordinated with a double-spend, in anticipation of the "reactive deployment". If the code is sound, deploy ASAP.
Does it? I followed that link to the transaction on Mempool. I can't see anything other than a lot of inputs into a transaction and it costing $110... How can I see what you are claiming?
That's the point, isn't it? This is exactly how the theorized CSAM and any other "illegal data" would look on the blockchain, no matter if it's encoded in an OP_RETURN, or multiple OP_RETURNs, or in the witness using the OP_FALSE OP_IF trick, or in the 20-of-20 tapscript multisig theorized by Anthony Towns on the mailing list which supposedly is more effective than OP_RETURN but indistinguishable from a "real" tapscript multisig, or any of the other of the myriad of ways you could possibly encode data into a transaction.
You can block some of them, but it is literally impossible to block all of them. And crucially, no matter the method used to encode the data, you would always need some sort of viewer that knows how to assemble and present the data - the only difference is how complicated it would be to reassemble. And without said viewer, you cannot generally be be said to "possess" the data legally.
Fun fact: for any randomly generated data, there exists a decryption algorithm and a decryption key to turn it into literally any data you want. Simplistic example: XOR-based "encryption" with an "encryption key" that is just the random data XOR'ed with the data you want to turn it into.
A bad actor who wants to conduct a double spend attack, could put CSAM on chain to cause a re-org and succeed with the attack.
If this is the case, then I suggest to implement this ASAP, rather than give a bad actor the ability to plan the attack.
Can you explain how implementing now would stop that from happening?
Also the problem goes beyond the one hypothetical attacker. Anyone that transacted in blocks that get re-orged can also double-spend their transaction with RBF, not just the attacker.
Can you explain how implementing now would stop that from happening?
As I have stated, I cannot review the Code itself. But assuming the Code works as intended, without any detriment... Then doesn't implementing it immediately remove any uncertainty as to how the chain is being constructed from that point forward? Am I missing something?
Also the problem goes beyond the one hypothetical attacker. Anyone that transacted in blocks that get re-orged can also double-spend their transaction with RBF, not just the attacker.
Agreed. And hence it is best to just make it Go Live immediately (assuming Code is good) rather than waiting for some objectionable material to surface and hoping it gets detected/caught quickly.
Can you explain how implementing now would stop that from happening?
As I have stated, I cannot review the Code itself. But assuming the Code works as intended, without any detriment... Then doesn't implementing it immediately remove any uncertainty as to how the chain is being constructed from that point forward? Am I missing something?
Also the problem goes beyond the one hypothetical attacker. Anyone that transacted in blocks that get re-orged can also double-spend their transaction with RBF, not just the attacker.
Agreed. And hence it is best to just make it Go Live immediately (assuming Code is good) rather than waiting for some objectionable material to surface and hoping it gets detected/caught quickly.
The detriment comes from the proposal itself. There is currently no economic incentive to put illegal material on chain. Activating this would change that. So i’m not sure how activating immediately would address this. Again this creates a much larger surface area than a single attacker(anyone who transacts in the re-org block).
Why does this request not block P2PK & P2MS for future spends?
Putting data in raw pubkeys using these payment methods is the most harmful way of embedding arbitrary data by bloating the utxo set.
NACK
I move to remove this BIP from consideration due to breaking the user space, explicitly requiring a hard fork, being obviously contentious, being anti-consensus, and being entirely motivated by subjective and speculative predictions about how uninvolved entities may behave outside of the protocol.
BIPs are for specifying methods of applying Bitcoin and adding rules to its protocol afaik. This BIP, and Ocean's efforts, are about disrupting Core, bringing attention to the Ocean team, and legitimizing a need for regulation on miners.
If it doesn't already exist, BIP reviewers should be obligated to define & enforce policies that reject BIPs that are toxic, without alienating BIPs that are merely unpopular.
I am not convinced that anyone here cares about spam or lawyers, or that there is a spam problem at all.
If they want a hard fork, they can also hard fork this BIP repo for their new blockchain and stay out of this one.
Please close this, thank you for your patience and work.
