MIME-Version: 1.0
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
 <CANPykMqJ823NcCPxdwHvjOdW2MQPE8oA2JzThFQ2rUa8zHGUvA@mail.gmail.com>
In-Reply-To: <CANPykMqJ823NcCPxdwHvjOdW2MQPE8oA2JzThFQ2rUa8zHGUvA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 6 Feb 2023 13:05:05 -0500
Message-ID: <CAJowKgJv9uMo3x+fNjDyo4SvdxUDAdAUmXzF80580pneK+M2JA@mail.gmail.com>
To: Claus Ehrenberg <aubergemediale@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009effdc05f40bdf4b"
Cc: Robert Dickinson <robert.lee.dickinson@gmail.com>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Precedence: list

--0000000000009effdc05f40bdf4b
Content-Type: text/plain; charset="UTF-8"

there are already images encoded in the chain using multisig.  when we
eliminated the max-witness size in 2017, that made it a bit cheaper, that's
all (one tx instead of many)

https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

my favorite one is the javascript exploit for people that like to render
untrusted blockchain data in their browser

the script to interpret these is trivial, and it's not much harder to add a
mime type


On Mon, Feb 6, 2023 at 12:34 PM Claus Ehrenberg via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The inscriptions are designed to be easy to use, they even specify that
> mime types should be used. I'd say, the way the data is stored is anything
> but 'obscure'. UIs will be popping up to make this really easy. The main
> chain can't be censored, what's in a block is in a block. I'm predicting a
> huge success.
>
> So, are we ready to accept that we'll likely see the first pictures with
> insults or worse in the Bitcoin chain? I really like the idea, but the risk
> is pretty obvious. I think it would be prudent to have at least an opt-out
> feature for the data. So that it's possible to use the chain without the
> potentially malicious content. That means the content shouldn't live in the
> essential data of the main chain. Better would be something like the
> extension blocks in Litecoin.
>
> Best Regards
> Claus
>
> On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I'm curious what opinions exist and what actions might be taken by core
>> developers regarding storing unlimited amounts of NFT (or other?) content
>> as witness data (https://docs.ordinals.com/inscriptions.html). The
>> ordinal scheme is elegant and genius IMHO, but when I think about the
>> future disk use of all unpruned nodes, I question whether unlimited storage
>> is wise to allow for such use cases. Wouldn't it be better to find a way to
>> impose a size limit similar to OP_RETURN for such inscriptions?
>>
>> I think it would be useful to link a sat to a deed or other legal
>> construct for proof of ownership in the real world, so that real property
>> can be transferred on the blockchain using ordinals, but storing the
>> property itself on the blockchain seems nonsensical to me.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000009effdc05f40bdf4b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">there are already images encoded in the chain using multis=
ig.=C2=A0 when we eliminated the max-witness size in 2017, that made it a b=
it cheaper, that&#39;s all (one tx instead of many)<br><br><a href=3D"https=
://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html">https:=
//www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html</a><br><=
br>my favorite one is the javascript exploit for people that like to render=
 untrusted blockchain data in their browser<div><br>the script to interpret=
 these is trivial, and it&#39;s not much harder to add a mime type</div><di=
v><br><div><br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Mon, Feb 6, 2023 at 12:34 PM Claus Ehrenberg =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">The inscriptions ar=
e designed to be easy to use, they even specify that mime types should be u=
sed. I&#39;d say, the way the data is stored is anything but &#39;obscure&#=
39;. UIs will be popping=C2=A0up to make this really easy. The main chain c=
an&#39;t be censored, what&#39;s in a block is in a block. I&#39;m predicti=
ng a huge success.<div><br></div><div>So, are we ready to accept that we=
9;ll likely see the first pictures with insults or worse in the Bitcoin cha=
in? I really like the idea, but the risk is pretty obvious. I think it woul=
d be prudent=C2=A0to have at least an opt-out feature for the data. So that=
 it&#39;s possible to use the chain without the potentially=C2=A0malicious =
content. That means the content shouldn&#39;t live in the essential data of=
 the main chain. Better would be something like the extension blocks in Lit=
ecoin.</div><div><br></div><div>Best Regards</div><div>Claus</div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, J=
an 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr">I&#39;m curious what opinions exist =
and what actions might be taken by core developers regarding storing unlimi=
ted amounts of NFT (or other?) content as witness data (<a href=3D"https://=
docs.ordinals.com/inscriptions.html" target=3D"_blank">https://docs.ordinal=
s.com/inscriptions.html</a>). The ordinal scheme is elegant and genius IMHO=
, but when I think about the future disk use of all unpruned nodes, I quest=
ion whether unlimited storage is wise to allow for such use cases. Wouldn&#=
39;t it be better to find a way to impose a size limit similar to OP_RETURN=
 for such inscriptions?<br><br>I think it would be useful to link a sat to =
a deed or other legal construct for proof of ownership in the real world, s=
o that real property can be transferred on the blockchain using ordinals, b=
ut storing the property itself on the blockchain seems nonsensical to me.<b=
r></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000009effdc05f40bdf4b--