Peter Todd [ARCHIVE] on Nostr: š Original date posted:2023-05-08 šļø Summary of this message: A proposal to ...
š
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>;
šļø 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>;