* [bitcoin-dev] Witness script validation to reject arbitrary data
@ 2023-05-08 20:16 Moth
2023-05-08 21:33 ` angus
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Moth @ 2023-05-08 20:16 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
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.
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?
Thanks,
Moth
Sent from Proton Mail for iOS
[-- Attachment #2: Type: text/html, Size: 1988 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Witness script validation to reject arbitrary data
2023-05-08 20:16 [bitcoin-dev] Witness script validation to reject arbitrary data Moth
@ 2023-05-08 21:33 ` angus
2023-05-08 21:43 ` Christopher Allen
2023-05-08 23:55 ` Peter Todd
2 siblings, 0 replies; 6+ messages in thread
From: angus @ 2023-05-08 21:33 UTC (permalink / raw)
To: Moth, Bitcoin Protocol Discussion
[-- Attachment #1.1.1: Type: text/plain, Size: 1435 bytes --]
> 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
[-- Attachment #1.1.2.1: Type: text/html, Size: 5931 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Witness script validation to reject arbitrary data
2023-05-08 20:16 [bitcoin-dev] Witness script validation to reject arbitrary data Moth
2023-05-08 21:33 ` angus
@ 2023-05-08 21:43 ` Christopher Allen
2023-05-09 17:45 ` Aymeric Vitte
2023-05-08 23:55 ` Peter Todd
2 siblings, 1 reply; 6+ messages in thread
From: Christopher Allen @ 2023-05-08 21:43 UTC (permalink / raw)
To: Moth, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev <
bitcoin-dev@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
[-- Attachment #2: Type: text/html, Size: 5407 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Witness script validation to reject arbitrary data
2023-05-08 20:16 [bitcoin-dev] Witness script validation to reject arbitrary data Moth
2023-05-08 21:33 ` angus
2023-05-08 21:43 ` Christopher Allen
@ 2023-05-08 23:55 ` Peter Todd
2023-05-09 12:20 ` Moth
2 siblings, 1 reply; 6+ messages in thread
From: Peter Todd @ 2023-05-08 23:55 UTC (permalink / raw)
To: Moth, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Witness script validation to reject arbitrary data
2023-05-08 23:55 ` Peter Todd
@ 2023-05-09 12:20 ` Moth
0 siblings, 0 replies; 6+ messages in thread
From: Moth @ 2023-05-09 12:20 UTC (permalink / raw)
To: pete, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
> They could have just as easily used OP_RETURN
outputs or any number of other data encoding techniques.
But doesn't OP_RETURN render the UTXO unspendable, thereby making it impossible to "trade" the minted BTC-20 tokens?
Moth
Sent from Proton Mail for iOS
On Mon, May 8, 2023 at 7:55 PM, Peter Todd <[pete@petertodd•org](mailto:On Mon, May 8, 2023 at 7:55 PM, Peter Todd <<a href=)> wrote:
> 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
[-- Attachment #2: Type: text/html, Size: 3629 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Witness script validation to reject arbitrary data
2023-05-08 21:43 ` Christopher Allen
@ 2023-05-09 17:45 ` Aymeric Vitte
0 siblings, 0 replies; 6+ messages in thread
From: Aymeric Vitte @ 2023-05-09 17:45 UTC (permalink / raw)
To: Christopher Allen, Bitcoin Protocol Discussion, Moth
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
Le 08/05/2023 à 23:43, Christopher Allen via bitcoin-dev a écrit :
> There was a recent thread discussing raising the limit on
> OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043
Indeed we already discussed all of this, and the conclusion was: there
are no reasons to impose limits, because people will find some deviant
(or not) workarounds (like Stamps), and fees will regulate this
And how to control the value of what is stored? If I store e=mc2, the
way I like since as many said it's super easy to find plenty of ways to
store in bitcoin, this one is short and supposed to have more value than
bitcoin, no?
Personnally I think of course that you should store a reference to
something and not the something, so a few hashes and/or signatures which
you cannot do with OP_RETURN today (80B Moth, not 80kB)
I don't see very well what can be done against the freeriders, except
avoiding that they impact the whole network (a bit à la bittorrent),
maybe the issue is more about decentralization rather than trying to
impose limitations, so the decentralized miners can't have the whole
image of the whole txs and hold low fees txs, which is not the case at
all today, but it seems a bit utopic right now
Or maybe when the ordinal meme stuff/BRC20 will be proven to have
finally zero value the market will self regulate
[-- Attachment #2: Type: text/html, Size: 2208 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-05-09 17:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-08 20:16 [bitcoin-dev] Witness script validation to reject arbitrary data Moth
2023-05-08 21:33 ` angus
2023-05-08 21:43 ` Christopher Allen
2023-05-09 17:45 ` Aymeric Vitte
2023-05-08 23:55 ` Peter Todd
2023-05-09 12:20 ` Moth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox