path: root/79/959597fac4fe4b0844cd4855704e226fc8d662

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ECB24C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  6 Feb 2023 18:05:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id BA9F560B9B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  6 Feb 2023 18:05:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BA9F560B9B
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=4KeuTZsl
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id K6yhA0sxgILf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  6 Feb 2023 18:05:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8C6C260B9A
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com
 [IPv6:2607:f8b0:4864:20::e2e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8C6C260B9A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  6 Feb 2023 18:05:18 +0000 (UTC)
Received: by mail-vs1-xe2e.google.com with SMTP id d66so13523707vsd.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 06 Feb 2023 10:05:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=NwoVTwwGnrZt8OQZeD/offN3UDX8NKkmrg91P6600WE=;
 b=4KeuTZslAQ24J7yjE2dvj7a0DzLYXBRmYwI2pK7wauSPOqwMPPkGIpN/5KGNTtorKy
 idqGVSRaK8IsXmvheDWe8N1Hfdsx+f9e+etXX80gHCO7GMkAyG8ss3QAzRPTpPa2TKAC
 NyhKXnOxHcTkJ00PfPPsHqAmX+R+lQlxtbt3SC6ITQ5mdAEhAoJVWUlISeBIDUt3Zr2b
 i1mgUOm+WNDWeJhlUBjpmipe8SKVKlZLbnt2cnjSlrQP0X/7wEEY378RZnixZS7+B1kS
 y9n1MWZviAkqic5er8iAnerSRuvG/m+UVbSaWYCzzeeS4xYvzKBzPiE8efTkcmMZon33
 NEtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=NwoVTwwGnrZt8OQZeD/offN3UDX8NKkmrg91P6600WE=;
 b=sjjQ37YhjyOyi4wAakAJ5ONkXkt5j0AcvxG/A1AvREmxEJJgPCveYSfHQfgfdwxK92
 s02c+JXE0HcnXwhwFOIwd4yaAYaXqs+HJmrHfiA4ZClUDFHk8ffqB0aaXzjXU9eb+VCY
 3T2mpny9C+lFi/JWQBYBeH0kl3h+6dr586tMcC862Zys6N5rt7huihCXM4JDVO32nkb/
 BPBG46ChmYTYG2/4+TTbKTR3xpWW5ovZqrW9/nb1MqI3Z4fP3tibp3BXfpBuLidHJrNo
 kC+q8pF0mjN2z7+VHGNoS/HFrPozdqtOydU/So5P0jQgEw2kjgp4VcDF/bdh3CiSsqLG
 MX+A==
X-Gm-Message-State: AO0yUKW6p1XUYk70qm/6jiM4+Q+vG7NUO3Iu1fmQYCm58z8CifcgoPtd
 IrN0eZ9mYUi6NPxsrTLup5js3NWvX77Rj0E7j+GDYCg=
X-Google-Smtp-Source: AK7set8w7RBsrrPk0VLiIcPVZxHwRZ3d7ao43E0iO4VjHYVjc79lDEHQHfHgUUQMaK8hPrNn2vWyYJI0gLICs2J5Gwk=
X-Received: by 2002:a67:486:0:b0:3ea:837a:f58d with SMTP id
 128-20020a670486000000b003ea837af58dmr143576vse.34.1675706717108; Mon, 06 Feb
 2023 10:05:17 -0800 (PST)
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"
X-Mailman-Approved-At: Mon, 06 Feb 2023 18:45:33 +0000
Cc: Robert Dickinson <robert.lee.dickinson@gmail.com>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2023 18:05:20 -0000

--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&#3=
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--