From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1E1FAC002B for ; Mon, 6 Feb 2023 17:31:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ECAE481353 for ; Mon, 6 Feb 2023 17:31:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ECAE481353 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=Z2gXRv1q X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYng97j32xEL for ; Mon, 6 Feb 2023 17:31:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C362F8134A Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by smtp1.osuosl.org (Postfix) with ESMTPS id C362F8134A for ; Mon, 6 Feb 2023 17:31:56 +0000 (UTC) Received: by mail-lj1-x22f.google.com with SMTP id y19so12834328ljq.7 for ; Mon, 06 Feb 2023 09:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Cy2UFSfskbYthBxKt0Fl6a4e8VUFhCVFLlDaZbmlqP4=; b=Z2gXRv1qdgMpIIVqmOmA3cwFyoTMFLabeuBOzhIFr9Zs9S9HGgmPxMugyrQ6d39qRb +I8e/nOB5PGKXOwK0U73udvynI0SMQkwzTvZlfkMJVzWp93RujEpEZTo7/+lIN5+E0vV Fp0C2R264DofcQwXne5Gm1ahzQBXw5LIZxg19e4YQtNYCsfCk/fa+u1n78YMOcOX3+dV ORflZ1tdgeIWY/K7VFT6TMaLUwoZPPu6T90mjIsTCYyTGJmhgSy+HfLU3guO/x4u4HO8 V/yHHIvize192y4Vlc581zEm9M8G/N077GbF/gMHLx17lLQShP756Ya22eXU0snMH/v+ 9JDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=Cy2UFSfskbYthBxKt0Fl6a4e8VUFhCVFLlDaZbmlqP4=; b=Bvk9t5Vg76czvDe5adYIsGq6j4cb7gyWWKoXsFatnqRxW/EvZoC2QnGML6F11tYl7W lbSKGn/pEe0PJjYdTUMWcHMosYroPezr53Yf1ylBge0R+zAlSXIS7P/YYwHKssFGTfgw oNzyzSZ1hZHgwXLE9GZpUpPw5L1YHIAeP0yv20+F6JS64YxYI/v3X6OJbdNB89M9VnCe 9cjH3gd1AGJOW7fJXuI5TZnlOrRu4qOVBZvK/Nhoxd9JzKGwTOgNXlrR4bl0LYY5ToRG wMz6f+NLfbH87vGPPxglUEEL3yS6MNhJ1oSEKIDEWFNgArBAuQZYk1i36mApIgodwMUz Wcuw== X-Gm-Message-State: AO0yUKXyPh+MBPDs01y4YPZIEkhb2KG/kAcN6FbSm/Z6+O4WNdF4ehD6 TOT8mZp3cw6d5wXeA+s5kWCNumnZjBi6nX1u9tA= X-Google-Smtp-Source: AK7set9Z+xtxGWl3SJMRwYNEuzewWEJhGeP4oSRbiY+F1GglPcHaYv6D4M2pxVKpoS457hAEMyV+q/cKCOUjgLudSkM= X-Received: by 2002:a2e:720c:0:b0:290:54d6:8a58 with SMTP id n12-20020a2e720c000000b0029054d68a58mr2580590ljc.49.1675704714564; Mon, 06 Feb 2023 09:31:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Claus Ehrenberg Date: Mon, 6 Feb 2023 18:31:45 +0100 Message-ID: To: Robert Dickinson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000004298bb05f40b68bd" X-Mailman-Approved-At: Mon, 06 Feb 2023 17:34:24 +0000 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 17:31:58 -0000 --0000000000004298bb05f40b68bd Content-Type: text/plain; charset="UTF-8" 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 > --0000000000004298bb05f40b68bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 s= tored is anything but 'obscure'. UIs will be popping=C2=A0up to mak= e this really easy. The main chain can't be censored, what's in a b= lock is in a block. I'm predicting a huge success.

S= o, 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 ris= k is pretty obvious. I think it would be prudent=C2=A0to have at least an o= pt-out feature for the data. So that it's possible to use the chain wit= hout the potentially=C2=A0malicious content. That means the content shouldn= 't live in the essential data of the main chain. Better would be someth= ing like the extension blocks in Litecoin.

Best Re= gards
Claus

On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I'm curious wh= at opinions exist and what actions might be taken by core developers regard= ing storing unlimited amounts of NFT (or other?) content as witness data (<= a href=3D"https://docs.ordinals.com/inscriptions.html" target=3D"_blank">ht= tps://docs.ordinals.com/inscriptions.html). The ordinal scheme is elega= nt and genius IMHO, but when I think about the future disk use of all unpru= ned nodes, I question whether unlimited storage is wise to allow for such u= se cases. Wouldn't it be better to find a way to impose a size limit si= milar 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 no= nsensical to me.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000004298bb05f40b68bd--