📅 Original date posted:2023-05-08
🗒️ Summary of this message: A proposal to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags to prevent overloading the network with inscriptions, while still allowing taproot benefits, has been suggested. However, there are other ways to inscribe data. Some have called for a larger OP_RETURN to store tagged root of a hash-tree, but objections to putting anything on-chain have delayed this. Inscriptions are causing problems for some free privacy services, and frustration is growing over the free-rider problem.
📝 Original message:On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> From what I understand, things like inscriptions can only be inserted
> between two specific flags - OP_FALSE and OP_IF. Having a validation check
> to reject witness scripts that have arbitrary data between these two flags
> could be used to reject inscriptions while still allowing all the benefits
> of taproot. This will prevent people from overloading the network with txns
> geared solely for ordinals and brc-20 tokens.
>
Unfortunately, there are many other ways to “inscribe” other than that
particular trick.
>
> 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. 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?
>
There have been some of us that had hoped for a slightly larger OP_RETURN
such that we can store a tagged root of a hash-tree (~128-512 bytes). For
instance, open time-stamps, ION, and my own privacy-focused Gordian
Envelope (https://www.blockchaincommons.com/introduction/Envelope-Intro/),
all consolidate large sets of proofs into a hash, which we use for L2
proofs-of-inclusion. My own preference is that the size can be large enough
so you can store the hash, optionally have a signature on it, and have a
few bytes for self-describing data (we like CBOR as it is quite small).
All of us held off for years asking for larger OP_RETURN or standardizing
on a pay-to-contract BIP for the techniques we do use because of objections
to putting anything on-chain. But now we are dismayed by the inscription
technique that freeloads on the network mempool, the validation network,
and volunteer unpruned full nodes.
For instance, I host an alternative explora instance (the source code base
used by blockstream.info), offering it publicly via Tor so that there is
more than a single server offering its details. Inscriptions combined with
DOS attacks on Tor is making it more expensive for me to host and maintain
this free privacy service.
There was a recent thread discussing raising the limit on OP_RETURN
https://github.com/bitcoin/bitcoin/issues/27043
Here is an old relevant thread from open time-stamps:
https://github.com/opentimestamps/python-opentimestamps/pull/14
I’m not sure what the solution is. I feel like I’ve been a good neighbor
for some time on this topic, always recommending minimal on-chain data, and
now I feel frustrated with this free-rider problem.
— Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/be4a7f25/attachment-0001.html>;
Christopher Allen [ARCHIVE] /
npub19g…ct5d0
2023-06-07 23:21:41
in reply to nevent1q…t94s
Author Public Key
npub19g47w5ewcqlpd7n07wpkp5cvcu2gjwrse0vl47l0avwl9hu933xsqct5d0Published at
2023-06-07 23:21:41Event JSON
{
"id": "8f7c758d05d857d32a6b14a8fe62e65c8377e48a5b286cf77e208c083675dfa6",
"pubkey": "2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d",
"created_at": 1686180101,
"kind": 1,
"tags": [
[
"e",
"569649b072848a6174ed646c40966783da04cda4306ba021091a69ba13849827",
"",
"root"
],
[
"e",
"681ab5d0e13c949002773196181ada4d994a3c128db25c4cad90d72d739fe24f",
"",
"reply"
],
[
"p",
"bc46e9956a775d1ebb7f1a62c436d907ed39fea9616d57be34474d7b8e868638"
]
],
"content": "📅 Original date posted:2023-05-08\n🗒️ Summary of this message: A proposal to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags to prevent overloading the network with inscriptions, while still allowing taproot benefits, has been suggested. However, there are other ways to inscribe data. Some have called for a larger OP_RETURN to store tagged root of a hash-tree, but objections to putting anything on-chain have delayed this. Inscriptions are causing problems for some free privacy services, and frustration is growing over the free-rider problem.\n📝 Original message:On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e From what I understand, things like inscriptions can only be inserted\n\u003e between two specific flags - OP_FALSE and OP_IF. Having a validation check\n\u003e to reject witness scripts that have arbitrary data between these two flags\n\u003e could be used to reject inscriptions while still allowing all the benefits\n\u003e of taproot. This will prevent people from overloading the network with txns\n\u003e geared solely for ordinals and brc-20 tokens.\n\u003e\n\nUnfortunately, there are many other ways to “inscribe” other than that\nparticular trick.\n\n\u003e\n\u003e Is there a reason such a validation check is a bad idea? We already have\n\u003e OP_RETURN to store arbitrary data that is limited to 80kb. Was it an\n\u003e oversight that arbitrary data can be inserted between OP_FALSE and OP_IF\n\u003e when the size limit for witness scripts was lifted as part of taproot?\n\u003e\n\nThere have been some of us that had hoped for a slightly larger OP_RETURN\nsuch that we can store a tagged root of a hash-tree (~128-512 bytes). For\ninstance, open time-stamps, ION, and my own privacy-focused Gordian\nEnvelope (https://www.blockchaincommons.com/introduction/Envelope-Intro/),\nall consolidate large sets of proofs into a hash, which we use for L2\nproofs-of-inclusion. My own preference is that the size can be large enough\nso you can store the hash, optionally have a signature on it, and have a\nfew bytes for self-describing data (we like CBOR as it is quite small).\n\nAll of us held off for years asking for larger OP_RETURN or standardizing\non a pay-to-contract BIP for the techniques we do use because of objections\nto putting anything on-chain. But now we are dismayed by the inscription\ntechnique that freeloads on the network mempool, the validation network,\nand volunteer unpruned full nodes.\n\nFor instance, I host an alternative explora instance (the source code base\nused by blockstream.info), offering it publicly via Tor so that there is\nmore than a single server offering its details. Inscriptions combined with\nDOS attacks on Tor is making it more expensive for me to host and maintain\nthis free privacy service.\n\nThere was a recent thread discussing raising the limit on OP_RETURN\nhttps://github.com/bitcoin/bitcoin/issues/27043\n\nHere is an old relevant thread from open time-stamps:\nhttps://github.com/opentimestamps/python-opentimestamps/pull/14\n\nI’m not sure what the solution is. I feel like I’ve been a good neighbor\nfor some time on this topic, always recommending minimal on-chain data, and\nnow I feel frustrated with this free-rider problem.\n\n— Christopher Allen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/be4a7f25/attachment-0001.html\u003e",
"sig": "c7ed4a55c4e613ec5a080fe1f703193593edc56cf0e5f3ce1c618bad7b8aab78b24c6d65b8cfd0f86d1abb72d5d3b05a3ff1e03075f45cf63e9466627d841ef1"
}