Christopher Allen [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 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>;
🗒️ 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>;