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 37054C002D for ; Fri, 27 Jan 2023 13:27:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 18BE040A71 for ; Fri, 27 Jan 2023 13:27:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 18BE040A71 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=mail.wpsoftware.net header.i=@mail.wpsoftware.net header.a=rsa-sha256 header.s=default header.b=AABOqkyx X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 jdiDeTj_kxxf for ; Fri, 27 Jan 2023 13:27:32 +0000 (UTC) X-Greylist: delayed 00:06:29 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E465340101 Received: from mail.wpsoftware.net (unknown [66.183.0.205]) by smtp2.osuosl.org (Postfix) with ESMTP id E465340101 for ; Fri, 27 Jan 2023 13:27:31 +0000 (UTC) Received: from camus (camus-andrew.lan [192.168.0.190]) by mail.wpsoftware.net (Postfix) with ESMTPSA id 7CDB3400C2; Fri, 27 Jan 2023 13:21:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net; s=default; t=1674825661; bh=u2/FkA0x19/y0Hjixa5tqDv5TWye1g/6X6XUDng2FDk=; h=Date:From:To:Subject:References:In-Reply-To; b=AABOqkyx7ngHrGDlfab3ul4+4b5Mpi2CjPypM0B7ausmt4UwexxFxEvNfTU7ZxmdG RDg0sl/BOZ3wk05nai7RQHevVuZ98Ks/M99c2nxVThIVfrNHP4IY93fts4WEf6Hzka t0YR9W4LLXz9bt8GG+/zx4tZry2XDyRBuzFbeJfzi0CWLPbQpfWJvwk/+QwnUNLdD9 wXP9jf2FhL1Lk8kka0rac3+Bx2nr4K/Ga0+GSNXYrwceDSf9R/5X7uGfoZGr6SwV3O xnAChh8vU4jiZopbtI8LKPBXT18VC/YeczguamTSlMLras9fI8VBwwJz9Y0413c+p3 PNZ94vyj5vJ8g== Date: Fri, 27 Jan 2023 13:21:00 +0000 From: Andrew Poelstra To: Robert Dickinson , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zyzCIOTwfrg8bb3Q" Content-Disposition: inline In-Reply-To: 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: Fri, 27 Jan 2023 13:27:33 -0000 --zyzCIOTwfrg8bb3Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2023 at 09:44:10AM -0300, Robert Dickinson via bitcoin-dev = 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? >=20 > I think it would be useful to link a sat to a deed or other legal constru= ct > 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. Unfortunately, as near as I can tell there is no sensible way to prevent people from storing arbitrary data in witnesses without incentivizing even worse behavior and/or breaking legitimate use cases. 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. Doing so would incur a ~2x cost to them, but if 2x is enough to disincentivize storage, then there's no need to have this discussion because they will will be forced to stop due to fee market competition anyway. (And if not, it means there is little demand for Bitcoin blockspace, so what's the problem with paying miners to fill it with data that validators don't even need to perform real computation on?). But if we were to ban "useful" data, for example, saying that a witness can't have more than 20 signatures in it, then we are into the same problem we had pre-Taproot: that it is effectively impossible construct signing policies in a general and composeable way, because any software that does so will need to account for multiple independent limits. We deliberately replaced such limits with "you need to pay 50 weight for each signature" to makes this sort of analysis tractable. 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. But =66rom a technical point of view, I don't see any principled way to stop this. --=20 Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster --zyzCIOTwfrg8bb3Q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmPTz7oACgkQxYjWPOQb l8H/2Qf/dLcHY2ib8Aq9P7E7IZ3SGGkBEYrYvZu5Z0LuIAJLrPFECwyI1OAQd4id 83IHjjNZGrwfCjbLO4I+1J9pqmYI46JosnMhpNnMBKXnWmv71Wxwe4KIQu325smX 8X4FoPYt99n+Rr59hY7iOdaTqWXZ5/ZXsYPcfZYB5XPowbd7rZRiw493FHSIwD9j 0umURayUHgtNx1j4S8peML6Kqn92/56CKPalUnZ41Ay8rgOISvDEIdFuIpCDW368 cECJD6003LS47NCoKvxJFP1Ch3Aozz7m27BM6wsm9IHSTa1Md/99pDiDiUyXCF3p mYZvVUzABZ7ZH7Co4h8UWsLJ6V9Hpw== =gCjQ -----END PGP SIGNATURE----- --zyzCIOTwfrg8bb3Q--