š
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 transactions for ordinals and BRC-20 tokens is deemed pointless. The current flood of BRC-20 inscriptions is small and could have used other data encoding techniques.
š Original message:On Mon, May 08, 2023 at 08:16:41PM +0000, Moth via bitcoin-dev wrote:
> From what I understand, things like inscriptions can only be inserted between two specific flags - OP_FALSE and OP_IF.
That's just an artifical limitation of the current inscription protocol. There
are endless ways to embed arbitrary data in Bitcoin transactions. Blocking them
all is a hopeless task.
> 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.
>
> 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?
It's pointless to even try.
The current flood of inscription txs are very small, about 150vB, and embed
very little data in the chain. They could have just as easily used OP_RETURN
outputs or any number of other data encoding techniques. Blocking that kind of
use-case is hopeless.
The _purpose_ of the current flood of BRC-20 inscriptions - tl;dr the creation
of a new set of assets via an auction - is something that doesn't even require
any data to be embedded in the chain at all. They could have implemented them
with perfectly normal transactions indistinguishable from any other
transaction. Blocking that is truly hopeless.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/d4716aa5/attachment-0001.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 23:21:41
in reply to nevent1qā¦q7e7
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:21:41Event JSON
{
"id": "27890833cbb030521a0fb4d0731b6a2819f709f57c4ee5d2cfea235cb8759f3c",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686180101,
"kind": 1,
"tags": [
[
"e",
"569649b072848a6174ed646c40966783da04cda4306ba021091a69ba13849827",
"",
"root"
],
[
"e",
"8933f0ed0275cc802b819eba27df1f3bf2ceca07a269b7db3ee62f5a87b24f6a",
"",
"reply"
],
[
"p",
"a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df"
]
],
"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 transactions for ordinals and BRC-20 tokens is deemed pointless. The current flood of BRC-20 inscriptions is small and could have used other data encoding techniques.\nš Original message:On Mon, May 08, 2023 at 08:16:41PM +0000, Moth via bitcoin-dev wrote:\n\u003e From what I understand, things like inscriptions can only be inserted between two specific flags - OP_FALSE and OP_IF.\n\nThat's just an artifical limitation of the current inscription protocol. There\nare endless ways to embed arbitrary data in Bitcoin transactions. Blocking them\nall is a hopeless task.\n\n\u003e 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.\n\u003e \n\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. 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\nIt's pointless to even try.\n\nThe current flood of inscription txs are very small, about 150vB, and embed\nvery little data in the chain. They could have just as easily used OP_RETURN\noutputs or any number of other data encoding techniques. Blocking that kind of\nuse-case is hopeless.\n\nThe _purpose_ of the current flood of BRC-20 inscriptions - tl;dr the creation\nof a new set of assets via an auction - is something that doesn't even require\nany data to be embedded in the chain at all. They could have implemented them\nwith perfectly normal transactions indistinguishable from any other\ntransaction. Blocking that is truly hopeless.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/d4716aa5/attachment-0001.sig\u003e",
"sig": "dac19eb336e1f2632b94a98971a2623bf919454e22f16b64336a7297a0229db8db53e389819bf13c967d845eece09dd41d22063e9798b435bd7921c00dcf711d"
}