📅 Original date posted:2023-05-08
🗒️ Summary of this message: Storing arbitrary data should not be banned as people will start abusing useful data to do so, which is worse. The UTXO set getting too big is a bigger problem than the chain getting bigger.
📝 Original message:> Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb.
A reason to not ban storing arbitrary/non-functional data is that people will still want to store things, so will start (ab)using useful data to do so, which is worse -- see Stamps[1], which stores Inscription-like data in fake outputs that consume UTXO set storage (using the Counterparty spec IIRC).
The UTXO set getting 'too big' is a much bigger problem than the chain getting bigger at closer to 4MB/10mins than the 'expected' ~1MB/10mins is (some nuance/argument to be had here, though).
> Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?
Kinda? But if we want Taproot to enable large useful scripts, it's probably hard/impossible to have an undefeatable definition of 'not useful' to then filter out. You could say "scripts must not have any unreachable code (dead code)" but then it'd be easy to come up with Inscriptions 2.0 where the code is reachable but never used, rinse and repeat in a game of whack-a-mole.
In my opinion, it'd be wise to not incentivize people to do something worse by attempting to censor what they're currently doing, given that it could be a fair bit worse!
[1]: https://github.com/mikeinspace/stamps/blob/main/BitcoinStamps.md
Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/13d8dff3/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/13d8dff3/attachment-0001.sig>;
angus [ARCHIVE] /
npub1h3…77mc5
2023-06-07 23:21:40
in reply to nevent1q…khkh
Author Public Key
npub1h3rwn9t2waw3awmlrf3vgdkeqlknnl4fv9k40035gaxhhr5xscuqc77mc5Published at
2023-06-07 23:21:40Event JSON
{
"id": "681ab5d0e13c949002773196181ada4d994a3c128db25c4cad90d72d739fe24f",
"pubkey": "bc46e9956a775d1ebb7f1a62c436d907ed39fea9616d57be34474d7b8e868638",
"created_at": 1686180100,
"kind": 1,
"tags": [
[
"e",
"569649b072848a6174ed646c40966783da04cda4306ba021091a69ba13849827",
"",
"root"
],
[
"e",
"478ebade2eb32cbbc1c22ac2e2884f1b62770968a7603d68bebe34fee6d5235e",
"",
"reply"
],
[
"p",
"adbdf2e9416fd87edbda95e9156ef831ee4f630fca523aec94ab05dc0e99232f"
]
],
"content": "📅 Original date posted:2023-05-08\n🗒️ Summary of this message: Storing arbitrary data should not be banned as people will start abusing useful data to do so, which is worse. The UTXO set getting too big is a bigger problem than the chain getting bigger.\n📝 Original message:\u003e Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb.\n\n\nA reason to not ban storing arbitrary/non-functional data is that people will still want to store things, so will start (ab)using useful data to do so, which is worse -- see Stamps[1], which stores Inscription-like data in fake outputs that consume UTXO set storage (using the Counterparty spec IIRC).\n\nThe UTXO set getting 'too big' is a much bigger problem than the chain getting bigger at closer to 4MB/10mins than the 'expected' ~1MB/10mins is (some nuance/argument to be had here, though).\n\n\n\u003e Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?\n\n\nKinda? But if we want Taproot to enable large useful scripts, it's probably hard/impossible to have an undefeatable definition of 'not useful' to then filter out. You could say \"scripts must not have any unreachable code (dead code)\" but then it'd be easy to come up with Inscriptions 2.0 where the code is reachable but never used, rinse and repeat in a game of whack-a-mole.\n\nIn my opinion, it'd be wise to not incentivize people to do something worse by attempting to censor what they're currently doing, given that it could be a fair bit worse!\n\n[1]: https://github.com/mikeinspace/stamps/blob/main/BitcoinStamps.md\n\nAngus\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/13d8dff3/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 249 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/13d8dff3/attachment-0001.sig\u003e",
"sig": "a3d30b1d90dc094ef53a5676aa2455e9302e0f9f663d84ebcee1aea53eb30d4d5885b7e6771421d634fc996f76181b4c1aa8c6c3e125d0b23ee59b26a95950c2"
}