From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 969E1C002B for ; Sat, 4 Feb 2023 10:39:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 6B320415FD for ; Sat, 4 Feb 2023 10:39:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6B320415FD X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjTkcY67-q7l for ; Sat, 4 Feb 2023 10:39:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 25553415FC Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp4.osuosl.org (Postfix) with ESMTPS id 25553415FC for ; Sat, 4 Feb 2023 10:39:02 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1pOFwf-0002Lq-VF; Sat, 04 Feb 2023 20:38:59 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Sat, 04 Feb 2023 20:38:54 +1000 Date: Sat, 4 Feb 2023 20:38:54 +1000 From: Anthony Towns To: Casey Rodarmor , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Purely off-chain coin colouring 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 10:39:05 -0000 On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev wrote: > Apologies for posting! I've tried to keep discussion of ordinals and > inscriptions off-list, because I consider it to be of little relevance to > general Bitcoin development. Anything that potentially uses up a large percentage of blockspace seems pretty relevant to general Bitcoin development to me... > AJ Towns writes: > > I think, however, that you can move inscriptions entirely off-chain. I > > wrote a little on this idea on twitter already [1], but after a bit more > > thought, I think pushing things even further off-chain would be plausible. I guess I should have explained why I think moving things off-chain is a worthwhile goal. Riffing off: > Another issue is salience and scarcity, as has been mentioned. Off-chain > content is unbounded, and thus less scarce. Usually, we design for > efficiency, volume, and scale. For NFT designs, which are intended to be > collectable, this is in some ways counterproductive. "scarce" has two meanings -- one is that there's not much of it, the other is that it's highly valued (or a third, where it's is consistently underpriced and unavailable even for people who'd pay more, but that hopefully doesn't apply). I think for bitcoin's blockspace, we ideally only want the first of these to be true. We want small blocks because that makes it cheap to verify bitcoin, which reduces the need to trust third parties and aids in decentralisation. But we don't want blockspace to be especially valuable, as that makes it expensive to use bitcoin, which then limits who can use it. Moving things off-chain helps with both these goals: it doesn't make it harder to validate bitcoin, and it also decreases demand for blockspace, making it cheaper for those cases where things can't be moved off-chain. As a result of this approach, bitcoin blockspace is currently quite cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a luxury purchase. If you keep jpegs on-chain, as far as I can see, there's three outcomes: * blockspace stays relatively cheap, and there's no "scarcity" benefit to minting via on-chain inscriptions; it's cheap enough to just mint any random meme, and there's no prestige to doing so * blockspace becomes filled with jpegs, driving up costs for everyone, making jpeg collectors happy, but transactors sad * the amount of blockspace is increased, keeping prices low, and reducing "scarcity" in both senses, so also making it harder to validate bitcoin. no one really wins. I'd guess the first of these is the most likely, personally. As far as salience/notability goes, personally, I'd see ownership of inscriptions as a negative indicator; "hey, when I was young and foolish I wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a permanent cost for everyone trying to use bitcoin in future". That's not unforgivable; people do all sorts of foolish things, and bitcoin's meant to survive attacks, not just foolish pranks. But it doesn't seem like something to brag about or encourage, either, at least if you want bitcoin to be a monetary network that's usable in practice by many/most people. (Even if one day that goes the other way, and there is real (and transferable) social value in being able to say "I donated x sats to fees to help secure bitcoin", such a claim is more charitable/admirable/value with a smaller on-chain footprint, both in that it again keeps validation easier, but also in that it makes it easier for others to also simultaneously make the same charitable contribution) > NFT collectors have a strong revealed preference for on-chain content. The > content of high-value NFTs is often stored partially or completely on > chain, When you identify an NFT by a url that points at someone else's server, that's an obvious vulnerability, as Moxie demonstrated pretty well. But solving that by saying "okay, we'll just externalise the storage costs to the public, while privatising all the benefits" isn't a good approach either. > User protection when off-chain content is involved is fraught. I mean, that seems trivially solvable? Users already have to store the private key that controls ownership of these digital assets; storing the asset as well, which doesn't need to be private, isn't a big ask. And if a public site like ordinals.net is willing to store all the inscriptions that might be on the blockchain, they could just as easily store the same amount of off-chain digital assets. > When a user buys an NFT with > off-chain content, they now have the primary economic incentive to preserve > that content, so that their NFT retains value and can be enjoyed or sold. Yes -- the people who potentially benefit from the NFT should be the ones paying the costs of preserving that NFT. > Many existing NFT marketplaces that sell off-chain content do not explain > this to users, or give users tools that the average, non-technical person > can understand or use, which enables them to protect themselves. Even if > they did give users these tools, there are tricky considerations involved. > IPFS functions much like BitTorrent, Externalising the costs to some different network while privatising the benefits isn't any better than doing it to bitcoin; except in that maybe you're inconveniencing fewer people. Going back to this: > Another issue is salience and scarcity, as has been mentioned. Off-chain > content is unbounded, and thus less scarce. Usually, we design for > efficiency, volume, and scale. For NFT designs, which are intended to be > collectable, this is in some ways counterproductive. Obviously blockchains aren't the only "scarce" good out there. If scarcity is your goal, there's two very easy ways to make your own scarcity. One is requiring proof of work -- you could have a digital asset marketplace that only allows works that have a hash with at least 32 leading zero-bits [0] and use timestamping [1] (or a certificate-transparency approach) to ensure that as proof-of-work techonology improves, it can't be used to backdate mints. [0] https://github.com/nostr-protocol/nips/blob/master/13.md [1] https://github.com/nostr-protocol/nips/blob/master/03.md Or the other approach is you just require people to pay you some sats over lightning to host an NFT. That way you're the one collecting the fees, not miners; and you're (perhaps) the one incurring an obligation to preserve the NFT on behalf of its owners, rather than random bitcoin node operators. > The above issues also make the specification and implementation of NFTs > with off-chain content much more difficult. I'm not meaning to criticise you for doing what you think's interesting, so if it's coming off that way I apologise in advance. I think it's interesting, too. I just think that, when possible, off-chain is always better than on-chain, and it's worth exploring that idea further. In particular, I don't think it *is* actually much more difficult? Here's how I'd change what you've done to turn ordinals.net into an off-chain digital asset site: - setup a nostr relay, with submissions gated by proof of work, and no expiry. maybe https://github.com/Cameri/nostream ? - for any event that includes an "ordinal" tag, treat it as a digital asset, and add it to your digital asset database, just like you do now for inscriptions. either have your own nostr client that subscribes to your relay, or just query your relay's db directly. - have a regular proof of work adjustment targeting say 200MB worth of events per day (vs the 576MB per day of possible witness data). - update the ord tool to be able to encode digital artifacts into a nostr event, apply proof of work to it, and send it to (by default) your relay. That would let nostr clients immediately just add your relay and get a feed of minted digital artifacts, that's already spam-free due to the proof of work requirement. They could follow all of them, or just follow a particular artist by pubkey, too. An artist could publish a collection by publishing an event defining the collection, then linking each artwork to the collection as a "reply", making it pretty easy for nostr clients to follow a collection, while still having each artwork linked to its own ordinal, and I think without requiring any work on your behalf. You don't need to change the way ordinals are spent at all for any of this, I think; all you're doing is replacing the initial two transactions that link the digital artifact with the ordinal with an off-chain message achieving the same thing. Then to go beyond what you've got you could: - add some support for the current owner of an ordinal to link that back to their nostr profile -- eg, sign a message with the pubkey based on the current utxo holding the ordinal, referencing the digial asset; you could perhaps use NIP-2 "following" messages for this. if you've already using an open social network, might as well take advantage of it. - add some support for the "social legitimacy" aspect -- eg linking all the assets created by the same public key as an artist's portfolio; make it easy to go from their nft-related pubkey to their regular nostr profile or similar. - let creators that have already somehow demonstrated "social legitimacy" bypass the proof of work requirement, since "great art" is already naturally scarce. creators who've demonstrated their quality shouldn't need to waste time or money doing proof of work or paying blockchain fees Adding a lightning based patreon-type setup could be awesome there -- content creators post content to a closed relay, patrons pay a fee over lightning to be able to receive events, and 90%+ of those fees are passed on to creators. If creators are happy with subscriptions, they just do that; if they want to auction off NFTs, they can do that; if they want both, that works too... > Additionally, I think the term "inscription" which has a connotation of > permanence, and of an indelible association with a particular satoshi, is > inappropriate for an off-chain NFT protocol. No objections about the "inscription" definition, but I'm not sure if the above means you're misunderstanding what I'm saying. In the off-chain scheme I'm talking about, the "digital asset" includes the ordinal that controls ownership, and is identified by the hash of its contents, including that ordinal's identity -- so there is an indelible association with a particular satoshi, despite it being an off-chain NFT protocol. For example if you take two identical digital assets, such as: https://ordinals.net/inscription/8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94adc2f8i0 https://ordinals.net/inscription/31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b80512966561i0 then in the off-chain world, they would look like two events: { pubkey: kind: 0 tags: [ ord: "8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94adc2f8:0:0" ] content: id: sig: } and { pubkey: kind: 0 tags: [ ord: "31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b80512966561:0:0" ] content: id: sig: } ie two unique digital assets, with two unique identifiers (XXXX and YYYY) that are each indelibly linked with particular satoshis. Obviously there's nothing stopping Alice minting the exact same content to two different ordinals -- presumably that's what happened with the two inscriptions above -- nor is there anything stopping Bob from right-click-save-as and doing the same; but as above, that's obviously true for inscriptions as well. The only truly unique thing is the specific hash and the specific content that generated the hash. The relationship does go the other way compared to inscriptions -- here you keep the association so long as you remember the asset; with inscriptions you keep the association so long as you have bitcoin's historical blocks. As I've said above, the off-chain approach seems much better aligned with incentives to me, with the people who gain the benefit from that association paying the cost of preserving it. Cheers, aj