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 81F42C002B for ; Sat, 28 Jan 2023 10:58:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 50090405F9 for ; Sat, 28 Jan 2023 10:58:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 50090405F9 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=E0XKsowA X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 xB6gGdVp-x4H for ; Sat, 28 Jan 2023 10:58:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4C973405F5 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp2.osuosl.org (Postfix) with ESMTPS id 4C973405F5 for ; Sat, 28 Jan 2023 10:58:21 +0000 (UTC) Date: Sat, 28 Jan 2023 10:58:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1674903498; x=1675162698; bh=7hKVRtUnlJ/w/MQIsstuLJoSoPwuWcnDQDINus+0b7c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=E0XKsowAE8EOQ13xMIljLcnEhTrbqPH1oM5NWQ7+G+D8vzfOyT5hcqmeLe0HAWoa6 4DZErCG5CTcLFwT+neYc5OX77rK9K2r5noLwv2hCtgMPp2Dctfa3BOchzuafCL3u5h e/o22+vLLqh1UsP7r0191DqSA0VjUzuQWqpK/mu5ucKvHy+f366xeRDRWrE/XMVUS6 OX8L71ZRdDtEBZGrcfNGJ3W8AU1TitEAl2xqe8fpENhPyRAO/r/1uvgmLq8T88njXa i9L6mfxYnu6bLYBNv3o07z4WqDA+f2h+HPT1C0bgCvyNpVnEszrqAnFFgLkl40le9+ KXNvsv8Z7FcmA== To: Bitcoin Protocol Discussion From: alicexbt Message-ID: In-Reply-To: References: Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 28 Jan 2023 15:28:49 +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: Sat, 28 Jan 2023 10:58:22 -0000 Hi Bitcoin Developers, > Anyone who runs an unpruned bitcoin node should be capacity-planning thei= r disk space assuming that in the future blocks will be more full - as dema= nd for blockspace increases, people will make better use of the space that = we already have and average block weight will trend upwards. If you= =E2=80=99re thinking about how much disk you will need when we have consist= ently full blocks, ordinal inscriptions don=E2=80=99t change that number.= =C2=A0 I completely agree with this. > If we ban "useless data" then it would be easy for would-be data storers to instead embed their data inside "useful" data such as dummy signatures or public keys. > There's a reasonable argument that this sort of data is toxic to the network, since even though "the market is willing to bear" the price of scares blockspace, if people were storing NFTs and other crap on the chain, then the Bitcoin fee market would become entangled with random pump&dump markets, undermining legitimate use cases and potentially preventing new technology like LN from gaining a strong foothold. Initially I considered ordinals and the use of witness for inscriptions use= less and harmful. However I have changed my opinion after looking at differ= ent things and reading several comments. I do not consider such things 'use= less' or 'crap' and it won't affect bitcoin fee market negatively. There is= no threat to LN as well. I consider every bitcoin transaction a legit use case and would like to sha= re an example and different perspective of how such inscriptions might be u= sed at different places: During the festival of Diwali, it is a common tradition among many Indian f= amilies to buy gold coins with the image of the goddess Laxmi, the goddess = of wealth and prosperity. The coins are often bought as a symbol of good lu= ck and prosperity for the upcoming year. They may also be given as gifts to= family and friends or used as a form of investment. The coins can be purch= ased from a variety of sources, including jewelry stores and online retaile= rs. If people start buying bitcoin during Diwali, and sellers use the witness t= o include the image of Laxmi in the inputs used, it would be an innovative = way of combining traditional customs with modern technology. Since some use= rs consider bitcoin as digital gold, I won't be surprised if this really ha= ppens in future and won't consider it bad as the transactions are paying fo= r block space used. /dev/fd0 floppy disc guy Sent with Proton Mail secure email. ------- Original Message ------- On Friday, January 27th, 2023 at 6:28 PM, rot13maxi via bitcoin-dev wrote: > Hello, >=20 > =E2=80=9CUnlimited storage=E2=80=9D isn=E2=80=99t really accurate. It= =E2=80=99s witness data in a taproot transaction, so the block size limit s= till applies. Anyone who runs an unpruned bitcoin node should be capacity-p= lanning their disk space assuming that in the future blocks will be more fu= ll - as demand for blockspace increases, people will make better use of the= space that we already have and average block weight will trend upwards. If= you=E2=80=99re thinking about how much disk you will need when we have con= sistently full blocks, ordinal inscriptions don=E2=80=99t change that numbe= r.=C2=A0 >=20 > - rijndael >=20 > On Fri, Jan 27, 2023 at 7:44 AM, Robert Dickinson via bitcoin-dev wrote: >=20 > > 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 u= se of all unpruned nodes, I question whether unlimited storage is wise to a= llow for such use cases. Wouldn't it be better to find a way to impose a si= ze limit similar to OP_RETURN for such inscriptions? > >=20 > > I think it would be useful to link a sat to a deed or other legal const= ruct for proof of ownership in the real world, so that real property can be= transferred on the blockchain using ordinals, but storing the property its= elf on the blockchain seems nonsensical to me.