From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CF7C2C002B for ; 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 ; 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 ; 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 ; Sat, 4 Feb 2023 14:26:10 +0000 (UTC) Received: by mail-yb1-xb29.google.com with SMTP id a1so9515301ybj.9 for ; 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: In-Reply-To: From: Kostas Karasavvas Date: Sat, 4 Feb 2023 16:25:58 +0200 Message-ID: To: Melvin Carvalho , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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


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


p=C3=A1 27. 1. 2023 v=C2=A013:47 odes=C3=ADlatel Robert Dickin= son via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> napsa= l:
I'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 (https://docs.ordinals.com/inscriptions.html). 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't it be better to find a way to = impose a size limit similar to OP_RETURN for such inscriptions?


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'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!).

=C2=A0
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.
=

Low tech solution: miners charge a p= remium for storing images in the block chain.=C2=A0 Say 2x, 5x, 10x.
<= div>
This encourages bitcoin to be used as a financial networ= k, while increasing the security budget.

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


--000000000000416e6705f3e0945f--