From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id ECB24C002B for ; 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 ; 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 ; 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 ; Mon, 6 Feb 2023 18:05:18 +0000 (UTC) Received: by mail-vs1-xe2e.google.com with SMTP id d66so13523707vsd.9 for ; 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: In-Reply-To: From: Erik Aronesty Date: Mon, 6 Feb 2023 13:05:05 -0500 Message-ID: To: Claus Ehrenberg , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009effdc05f40bdf4b" X-Mailman-Approved-At: Mon, 06 Feb 2023 18:45:33 +0000 Cc: Robert Dickinson 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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's all (one tx instead of many)

https:= //www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html
<= br>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 ar= e designed to be easy to use, they even specify that mime types should be u= sed. I'd say, the way the data is stored is anything but 'obscure&#= 39;. UIs will be popping=C2=A0up to make this really easy. The main chain c= an't be censored, what's in a block is in a block. I'm predicti= ng a huge success.

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's possible to use the chain without the potentially=C2=A0malicious = 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 Lit= ecoin.

Best Regards
Claus
On Fri, J= an 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
I'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 (https://docs.ordinal= s.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 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?

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.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000009effdc05f40bdf4b--