From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9344EC002D for ; Fri, 27 Jan 2023 12:44:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6933540B2F for ; Fri, 27 Jan 2023 12:44:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6933540B2F Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=O9LXnLtI 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHIt5ApE1ryo for ; Fri, 27 Jan 2023 12:44:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6CB704040D Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6CB704040D for ; Fri, 27 Jan 2023 12:44:23 +0000 (UTC) Received: by mail-yb1-xb2b.google.com with SMTP id b1so5782032ybn.11 for ; Fri, 27 Jan 2023 04:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=VFvVvCoxGQjADL4uHEh8+DCyhV+kCrPv52y7RFl+eqU=; b=O9LXnLtIHaBPtVVkVF24JPPDLm0zmVog4cxcku5nSl+cqpVTs1nc8idxg+YIvVYNYz sDeAnGVkOWSfwCeKJnRT25K3oXUs/Z/Kcgc4U4ayGAvbEfn3+HyXlLXMmxYRIIkOpBTw 5YFA7i5yx5GoQxr5MeL+E4QzdgIuKnOe20QLpjlu895+GkhmM+OkTOpz5wEqI4R/HJ/h Usnc8VdIqHJHTvYYgjfNhRwNxP1D03YELErC5eXlTmHU43AYeTAQYhD4tVJorKSKzdxW RACdtbvWZjgCHJNYzeTh9KQJvzT8N11mNUtlbtmx/AbJ59mx4+l2SLlDeklMMaeleTQO E+rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VFvVvCoxGQjADL4uHEh8+DCyhV+kCrPv52y7RFl+eqU=; b=0vs9noqdvmhgrH0Ewi8wShz4vRqqU9WZM5+pFeboPVT7PCtxlmz82Jhs5HKaBXC0Q/ u7hWj4S22GOolryO89x0TqOBujwoWHk1/o1pYfW2VU5gmCXqoYGs1tiTLCC7nHGPkMWZ W6o1YUnas0dHm63vpejjB0luzEAXsahYD/eyQr5O5LfF+zSMHVH8kzk7ytz/BFKPAe2A O+t6klqRB9sfwMJMukM0hDfyGpD2AaFl8KyXs0yJ58uR1s5HLx6675yXFaK/iEl99oTv kX7snmAXsQo3jNyMa1tQfYlVp947FuSSpJfd2kqM54DxI5cHKfq9MMgVUeHwqNZt+vs/ +pzw== X-Gm-Message-State: AFqh2koBCeC/SiEifZB8kf/MGMyJ+l8D8blbv5DjuDXewsnjHc+NTxJz fTJBsdp+GlpoXTf5ZTUrN9NrD16V5SWZtogEZSXONuOkjQ== X-Google-Smtp-Source: AMrXdXuX62zi84ubv8GRnEKc+6rpH4G7RFzyAU9EoMzLVK0YEKB4koJZV8m5KfCHpqpsXIyzCg6sFB7ufnQa9WI3WPI= X-Received: by 2002:a25:3c42:0:b0:740:b601:45e6 with SMTP id j63-20020a253c42000000b00740b60145e6mr3792353yba.121.1674823462019; Fri, 27 Jan 2023 04:44:22 -0800 (PST) MIME-Version: 1.0 From: Robert Dickinson Date: Fri, 27 Jan 2023 09:44:10 -0300 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="00000000000083e6e205f33e39fd" X-Mailman-Approved-At: Fri, 27 Jan 2023 12:47:12 +0000 Subject: [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: Fri, 27 Jan 2023 12:44:24 -0000 --00000000000083e6e205f33e39fd Content-Type: text/plain; charset="UTF-8" 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. --00000000000083e6e205f33e39fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 ordina= l 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 impos= e a size limit similar to OP_RETURN for such inscriptions?

I think i= t would be useful to link a sat to a deed or other legal construct for proo= f 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 bl= ockchain seems nonsensical to me.
--00000000000083e6e205f33e39fd--