path: root/a3/283dfd0b456c8a08f4d59a3598b9c1af7d1b4e

Return-Path: <kkarasavvas@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CF7C2C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 14:26:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9D5CF60ACE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 14:26:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9D5CF60ACE
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=KQex5G0o
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bbetJB47J0Sj
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 14:26:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7D90D608A5
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com
 [IPv6:2607:f8b0:4864:20::b29])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 7D90D608A5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 14:26:10 +0000 (UTC)
Received: by mail-yb1-xb29.google.com with SMTP id a1so9515301ybj.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 04 Feb 2023 06:26:10 -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=4T13GTtpn9oG8nyrh588eu4C4Rfr57NanEgu0hUaP1A=;
 b=KQex5G0o6VG549WYySZc0wn9sZDCjIhB2hvby4Is47VoMtnE6KfC2KwUmTPYjjoDlU
 FzyxP4nKJYS1XyVLh4ZP5ce4qGY3Qu33tcNez6V0/klRj+moLMaE8hpZ6zK/UoySoAsH
 AOdqr86DfxEsweygLEJDVRUdVxa8bkPST2Ip6E6T8cF8POeEOBXTMJ3z6O8SOcLyOAcG
 nsW02ebcdW8TUsexB4cvcG1cpjLF3QzDS5aPrubAKCMzcs8CHgZD+Kuq6DtoqUt0fW7o
 TAOv6Mm+y3YjByZRN5w+VbRvXEIPjdh4xB5a0q39kdo4NfPiCjDz6NW3NsgwUQgA/V4C
 85Og==
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=4T13GTtpn9oG8nyrh588eu4C4Rfr57NanEgu0hUaP1A=;
 b=jtxCb+0Ez90ntJ8mU1KI33xfUWT29bjGZxT66SHlTSwujwCWwvpFA/vXkcCkoCb2vD
 eJWZIuinsNgZunaAPcGuJkC+PxjWeszEtVICcFQTH1RR1sNV5EEOblMQDKbpxHjfgsM+
 7YhOrwpSNmFKIFdBLT94jg4BBm+03Q5mjTiYGpCWCtnXV45EFMjmM5P4JjcCfT0qeEi7
 vVe5+hDsKYCXdPsHc9k8eFrQwWZ5z3ZHtChCu7goSQO6DHdxQ87VqronZLY/0268zJgm
 ToNIWsMsxCfcZBE03m8jPfY0yNVzlkhgXsCd0+mNZJwnu3M562X/aQ2wBpUfoHDwsGbe
 h3Aw==
X-Gm-Message-State: AO0yUKVqsVaalQC5tvHhBtkOUbG2/hDM9XScNFrjRHQw8JUfow/VHRUA
 e/Lc9w9zy14DJb+pAUW8aDGRI0VYbdXdXmdo9hfQeeRPTH0=
X-Google-Smtp-Source: AK7set8ff2KETf6pGSmW46OjD8gaADDVC2Kl0xJsUoNCLGu2NQnbBJZVrgsPOVMP/pKBTHPrlCfu2SBZGAML38pCtFQ=
X-Received: by 2002:a25:b1a0:0:b0:7ee:b52b:6d11 with SMTP id
 h32-20020a25b1a0000000b007eeb52b6d11mr1664421ybj.74.1675520769091; Sat, 04
 Feb 2023 06:26:09 -0800 (PST)
MIME-Version: 1.0
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
 <CAKaEYhJ_8tph3v9n139Ta+3sBaL-TmeOBNr-cCtti9dbdYuhCQ@mail.gmail.com>
In-Reply-To: <CAKaEYhJ_8tph3v9n139Ta+3sBaL-TmeOBNr-cCtti9dbdYuhCQ@mail.gmail.com>
From: Kostas Karasavvas <kkarasavvas@gmail.com>
Date: Sat, 4 Feb 2023 16:25:58 +0200
Message-ID: <CABE6yHvRihAbP3NYOiAiXmRFQu-28Rnz6QBn17bHxBwM-V4wdw@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000416e6705f3e0945f"
X-Mailman-Approved-At: Sat, 04 Feb 2023 15:46:47 +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 <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: Sat, 04 Feb 2023 14:26:11 -0000

--000000000000416e6705f3e0945f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 3, 2023 at 10:17 PM Melvin Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> p=C3=A1 27. 1. 2023 v 13:47 odes=C3=ADlatel Robert Dickinson via bitcoin-=
dev <
> bitcoin-dev@lists.linuxfoundation.org> napsal:
>
>> I'm curious what opinions exist and what actions might be taken by core
>> developers regarding storing unlimited amounts of NFT (or other?) conten=
t
>> 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 stor=
age
>> 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?
>>
>>
Personally, I was always considering future disk use at full capacity
anyway (and planning accordingly). Even without inscriptions/ordinals that
would happen. The latter competes for block space and are paying tx fees so
I don't see it as that much harmful (esp.now that it is out there... I
would be more conservative if we were talking about introducing it!).



> 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 propert=
y
>> can be transferred on the blockchain using ordinals, but storing the
>> property itself on the blockchain seems nonsensical to me.
>>
>
> Low tech solution: miners charge a premium for storing images in the bloc=
k
> chain.  Say 2x, 5x, 10x.
>
> This encourages bitcoin to be used as a financial network, while
> increasing the security budget.
>

How would you enforce this technically?  I only see it feasible if miners
agree by social contract.

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 3, 2023 at 10:17 PM Melvi=
n Carvalho via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.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 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">p=C3=A1 27. 1. 2023 v=C2=A013:47 odes=C3=ADlatel Robert Dickin=
son via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; napsa=
l:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr">I&#39;m curious what opinions exist and what actions might be taken by =
core developers regarding storing unlimited amounts of NFT (or other?) cont=
ent as witness data (<a href=3D"https://docs.ordinals.com/inscriptions.html=
" target=3D"_blank">https://docs.ordinals.com/inscriptions.html</a>). The o=
rdinal 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 wi=
se 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></di=
v></blockquote></div></div></blockquote><div><br></div><div>Personally, I w=
as always considering future disk use at full capacity anyway (and planning=
 accordingly). Even without inscriptions/ordinals that would happen. The la=
tter competes for block space and are paying tx fees so I don&#39;t see it =
as that much harmful (esp.now that it is out there... I would be more conse=
rvative if we were talking about introducing it!). <br></div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr">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.<br>=
</div></blockquote><div><br></div><div>Low tech solution: miners charge a p=
remium for storing images in the block chain.=C2=A0 Say 2x, 5x, 10x.</div><=
div><br></div><div>This encourages bitcoin to be used as a financial networ=
k, while increasing the security budget.</div></div></div></blockquote><div=
><br></div><div>How would you enforce this technically?=C2=A0 I only see it=
 feasible if miners agree by social contract.<br></div></div><div dir=3D"lt=
r" class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><br></d=
iv><div dir=3D"ltr"><br></div></div></div></div></div>

--000000000000416e6705f3e0945f--