From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3547CC002B for ; Fri, 3 Feb 2023 06:39:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 05326820B9 for ; Fri, 3 Feb 2023 06:39:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 05326820B9 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=rodarmor.com header.i=@rodarmor.com header.a=rsa-sha256 header.s=google header.b=gUjCY7ul X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9C3jRBgyuL1 for ; Fri, 3 Feb 2023 06:39:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6A7BA820B6 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6A7BA820B6 for ; Fri, 3 Feb 2023 06:39:23 +0000 (UTC) Received: by mail-vs1-xe33.google.com with SMTP id s24so4361092vsi.12 for ; Thu, 02 Feb 2023 22:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rodarmor.com; s=google; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=pAkYYD+NiOvePGz0s284x3jX5exlOX3XqJJnusiucUk=; b=gUjCY7ulIcRCHcjzpZ1XsAAPg/69T82CPLEj8Z9YtsU3B1pfEnKhw6dCcsslyWXkSQ MpoYN/Z29jkLzC//q32ccnm7FDZTMW5cWJq6XUkYaWy5JFwkMTXKgC8MWVAw6HjMBt0j sRVtfUGIaytinztukoLJVN1MuEK7//y/f1jlMoPqxKtiRfZJuxaRoi18PvtV+EQ8fgOs B3DHoVyJHnBKtkpXsf64bm8Lspd9RxFFEc6HoecqGlNlaFe6T8SsvnASkWc1qX2ATf8V W5hYe/E8Wb20o63Hm6BeteYxqe2BXrjln+azi/9gDyLd4BPTI0hiTh9iH70lLI/PFIi8 R6EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pAkYYD+NiOvePGz0s284x3jX5exlOX3XqJJnusiucUk=; b=PKwZqZZCUNN+S3ILWaxyslpBVa2LvmdTPGNKfXZKnWAsL32/v+4ZtO0JSXGgtfPhux 4cx75yNhXf9OYhHsT0FjHfUrifmVQVe10yg9jgL8yBzuDYi/4XtvB0nZERz3rypHjvR1 geelGhbqG33Q3/f2WLJOJBkZHBRBg3yAozCpE/1kx8TgR2trZsG0ZCTnuTtu8WCzNYhp ysnycm8KoA/luXAa4+wwyT1l/N0ukA3RZrPQpzmu6qe0AzZXj7HIRLEr+RIbljerf78Z QosAuRFYvlwvEEv/1hBmoBFf7Trs+sEgNziimnRuMeTj0l3OdO8S2mupjzJKUjlNy0xv SZ3w== X-Gm-Message-State: AO0yUKUft0dbRS/3bWGj2QqrQRDUdTT4pYUpSgYJ6SUxNK0l37uKuGui yzq8pWZSv7mmH3mzjE66CmW94TA1QoJCOPhqpDTXN6UZ66wzeQ== X-Google-Smtp-Source: AK7set8qm12WFz7HJcItqyAU3z9/6r9i0/Vx7wGTbOsY+C97CHybNRGgLTBCUXkewPu8Kg5gNb396qjlZ6ydqlhvMvE= X-Received: by 2002:a67:e1cb:0:b0:3e9:6d7f:6f37 with SMTP id p11-20020a67e1cb000000b003e96d7f6f37mr1467211vsl.3.1675406361793; Thu, 02 Feb 2023 22:39:21 -0800 (PST) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 2 Feb 2023 22:39:21 -0800 Mime-Version: 1.0 X-Superhuman-Thread-ID: draft00eb096193755ab9 From: Casey Rodarmor X-Mailer: Superhuman Web (2023-02-02T23:05:55Z) X-Superhuman-ID: ldo5odp8.64e30edb-72c6-4b22-9667-97d4952c3583 X-Superhuman-Draft-ID: draft008b73e5cbfb47c6 Date: Thu, 2 Feb 2023 22:39:21 -0800 Message-ID: To: Bitcoin Protocol Discussion , Anthony Towns Content-Type: multipart/alternative; boundary="0000000000000cac6705f3c5f1c1" X-Mailman-Approved-At: Fri, 03 Feb 2023 10:13:25 +0000 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: Fri, 03 Feb 2023 06:39:25 -0000 --0000000000000cac6705f3c5f1c1 Content-Type: text/plain; charset="UTF-8" Good evening list, 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. Also, apologies for the HTML mail, but I don't have my email client configured correctly. And finally, also apologies if this breaks the thread, I was subscribed but not receiving mail, so I can't respond to the original message. 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. Actually, my initial sketch for Ordinal NFTs worked in a similar fashion, with off-chain messages pointing to an ordinal, which could be tracked by following the chain of custody of that particular sat. I gave a workshop last year where I handed out paper wallets to participants with a private key that controlled some sats, which could both be assigned NFTs and used to sign messages as a form of provenance: https://www.youtube.com/watch?v=j5V33kV3iqo Ultimately, I decided against this design, and Peter provided an excellent explanation of some of the trade-offs of such a design in his mail, but to at least partially recap and explain my own thinking: 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, even if details of the NFT protocol involved actually prevents that content from being what you see when you view the NFT on a website or marketplace. User protection when off-chain content is involved is fraught. Users are not equipped, due to lack of technical knowledge, easily available, user-friendly tools, and education, to protect themselves when they buy a collectable whose content is stored off-chain. 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. 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, so even if users were provided with an IPFS application that could persist their off-chain NFT content automatically, they might reveal their IP address, which would then be linked to ownership of their NFT, which would have privacy and safety considerations. 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. The above issues also make the specification and implementation of NFTs with off-chain content much more difficult. Ordinals is a project largely written by a single developer, me, with the assistance of two part time interns. It is very intentionally the simplest thing that could possibly work, much like Bitcoin itself. Sometimes I refer to it as "cave-man technology". If I was designing an off-chain NFT protocol, I would likely have had to raise money and recruit a large team, which I have not done, or be at risk of never launching anything at all. I would absolutely love for the ordinals protocol, that is, the numbering and transfer of individual satoshis, be used as the basis for alternative, off-chain NFT and colored coin schemes, with proper consideration given to the issues above. However, I would request that, to avoid confusion, these alternative schemes never be called inscriptions. I'm a dev, not a cop, but fine distinctions are hard to properly explain and understand. Inscriptions, that is, the NFT protocol which embeds content in transaction witnesses, has a particular set of trade-offs and guarantees. I want users to know that if they buy or value something they or others call an "inscription", they can rely on those trade-offs and guarantees. Another NFT protocol named "inscriptions" would make this very difficult. 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. Sorry to belabor this point! Inscriptions have already proven very popular for a nascent protocol, beyond my expectations, and the terminology and naming is still new, so it's a critical phase in terms of understanding and education. If others are interested in developing ordinals further, a great first step would be to provide review and feedback on the BIP PR: https://github.com/bitcoin/bips/pull/1408 I have never written a BIP, so style and content feedback is especially welcome. Inscriptions themselves have no BIP, although at least one alternative implementation of the inscription parser has been written: https://ordinals.com/content/6f46a2a830a90e406245b188631cd15ffea31b8be146255ec39d4d46bbe15663i0 I hope to write a BIP for inscriptions as the implementation and protocol mature. In general, although I do love the ordinals protocol, it has many downsides, which I hope people will consider when considering it for alternative colored coin schemes. These include the fact that divisibility is limited, both by the use of real sats and the dust limit, that cardinal satoshis must be used to pay fees, the general insanity of ordinal-aware transaction construction[0], and difficult in lifting ordinals onto an L2. I consider ordinals ideal for art projects like inscriptions and ordinal-theory-powered satoshi numismatics, where aesthetic and technical considerations are nearly equally important. Please feel free to contact me privately by email, or on the ordinals project GitHub[1] if you'd like to respond! My intention with this message is not to spark debate, since I consider it mostly off-topic for this list. Best regards, Casey Rodarmor [0] https://github.com/casey/ord/blob/master/src/subcommand/wallet/transaction_builder.rs [1] https://github.com/casey/ord --0000000000000cac6705f3c5f1c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good evening list,

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. Als= o, apologies for the HTML mail, but I don't have my email client config= ured correctly. And finally, also apologies if this breaks the thread, I wa= s subscribed but not receiving mail, so I can't respond to the original= message.

AJ Towns write= s:

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

Actually, = my initial sketch for Ordinal NFTs worked in a similar fashion, with off-ch= ain messages pointing to an ordinal, which could be tracked by following th= e chain of custody of that particular sat. I= gave a workshop last year where I handed out paper wallets to participants= with a private key that controlled some sats, which could both be assigned= NFTs and used to sign messages as a form of provenance:

https://www.youtube.com/watch?v=3Dj5V33kV3iqo

Ultimately, I= decided against this design, and Peter provided an excellent explanation o= f some of the trade-offs of such a design in his mail, but to at least part= ially recap and explain my own thinking:

NFT collectors have a strong revealed preference for on-ch= ain content. The content of high-value NFTs is often stored partially or co= mpletely on chain, even if details of the NFT protocol involved actually pr= events that content from being what you see when you view the NFT on a webs= ite or marketplace.

User protection= when off-chain content is involved is fraught. Users are not equipped, due= to lack of technical knowledge, easily available, user-friendly tools, and= education, to protect themselves when they buy a collectable whose content= is stored off-chain. When a user buys an NFT with off-chain content, they = now have the primary economic incentive to preserve that content, so that t= heir NFT retains value and can be enjoyed or sold. Many existing NFT market= places that sell off-chain content do not explain this to users, or give us= ers tools that the average, non-technical person can understand or use, whi= ch enables them to protect themselves. Even if they did give users these to= ols, there are tricky considerations involved. IPFS functions much like Bit= Torrent, so even if users were provided with an IPFS application that could= persist their off-chain NFT content automatically, they might reveal their= IP address, which would then be linked to ownership of their NFT, which wo= uld have privacy and safety considerations.

An= other issue is salience and scarcity, as has been mentioned. Off-chain cont= ent is unbounded, and thus less scarce. Usually, we design for efficiency, = volume, and scale. For NFT designs, which are intended to be collectable, t= his is in some ways counterproductive.

The abo= ve issues also make the specification and implementation=C2=A0of NFTs with = off-chain content much more difficult. Ordinals is a project largely writte= n by a single developer, me, with the assistance of two part time interns. = It is very intentionally the simplest thing that could possibly work, much = like Bitcoin itself. Sometimes I refer to it as "cave-man technology&q= uot;. If I was designing an off-chain NFT protocol, I would likely have had= to raise money and recruit a large team, which I have not done, or be at r= isk of never launching anything at all.

I woul= d absolutely love for the ordinals protocol, that is, the numbering and tra= nsfer of individual satoshis, be used as the basis for alternative, off-cha= in NFT and colored coin schemes, with proper consideration given to the iss= ues above.

However, I would request that, to avoid confus= ion, these alternative schemes never be called inscriptions.

=
I'm a dev, not a cop, but fine distinctions are hard to prop= erly explain and understand. Inscriptions, that is, the NFT protocol which = embeds content in transaction witnesses, has a particular set of trade-offs= and guarantees. I want users to know that if they buy or value something t= hey or others call an "inscription", they can rely on those trade= -offs and guarantees. Another NFT protocol named "inscriptions" w= ould make this very difficult.

Additionally, I= think the term "inscription" which has a connotation of permanen= ce, and of an indelible association with a particular satoshi, is inappropr= iate for an off-chain NFT protocol.

Sorry to b= elabor this point! Inscriptions have already proven very popular for a nasc= ent protocol, beyond my expectations, and the terminology and naming is sti= ll new, so it's a critical phase in terms of understanding and educatio= n.

If others are interested in developing ordi= nals further, a great first step would be to provide review and feedback on= the BIP PR:


I have never written a BIP, so style and content= feedback is especially welcome.

Inscriptions them= selves have no BIP, although at least one alternative implementation of the= inscription parser has been written:


=
I hope to write a BIP for inscriptions as the implementation and proto= col mature.

In general, althou= gh I do love the ordinals protocol, it has many downsides, which I hope peo= ple will consider when considering it for alternative colored coin schemes.= These include the fact that divisibility is limited, both by the use of re= al sats and the dust limit, that cardinal satoshis must be used to pay fees= , the general insanity of ordinal-aware transaction construction[0], and di= fficult in lifting ordinals onto an L2. I consider ordinals ideal for art p= rojects like inscriptions and ordinal-theory-powered satoshi numismatics, w= here aesthetic and technical considerations are nearly equally important.

Please feel free to contact me privately by ema= il, or on the ordinals project GitHub[1] if you'd like to respond! My i= ntention with this message is not to spark debate, since I consider it most= ly off-topic for this list.

Best regards,
<= /div>
Casey Rodarmor

<= /div>
--0000000000000cac6705f3c5f1c1--