Feedback-ID: i525146e8:Fastmail
Date: Thu, 2 Feb 2023 09:30:11 -0500
From: Peter Todd <pete@petertodd.org>
To: Anthony Towns <aj@erisian.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y9vI8x6JcqdrvawF@petertodd.org>
References: <Y9t/NcgRzv1w//Fx@erisian.com.au>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="+Z5FCfXWuQtsGO06"
Content-Disposition: inline
In-Reply-To: <Y9t/NcgRzv1w//Fx@erisian.com.au>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Precedence: list


--+Z5FCfXWuQtsGO06
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wro=
te:
> Hi *,
>=20
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:

<snip>

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

On the FAQ of the Ordinals website they discuss off-chain data storage and
reject the idea:

    "Some Ethereum NFT content is on-chain, but much is off-chain, and is s=
tored on
    platforms like IPFS or Arweave, or on traditional, fully centralized web
    servers. Content on IPFS is not guaranteed to continue to be available,=
 and
    some NFT content stored on IPFS has already been lost. Platforms like A=
rweave
    rely on weak economic assumptions, and will likely fail catastrophicall=
y when
    these economic assumptions are no longer met. Centralized web servers m=
ay
    disappear at any time."
    https://web.archive.org/web/20230130012343/https://docs.ordinals.com/fa=
q.html

That same FAQ also mention RGB and Taro, which already implements an off-ch=
ain
data model based on my Proofmarshal work. The Ordinals community is well aw=
are
of the trade-offs and have chosen to publish their data on chain. This is a
collectables market based on artificial scarcity after all, so some conspic=
uous
consumption isn't going to be a deterrent.

Frankly, I think further discussion of this on the bitcoin-dev mailing list,
with the aim of getting Ordinals and others to do something else, is a wast=
e of
everyones' time. The fact that publishing data on chain lets you take
advantage of the very large network of archival Bitcoin nodes to publish and
store your data indefinitely is a clear benefit that people will always be
willing to pay for. The only realistic thing Bitcoin can do to discourage t=
his
is tweaks to the blocksize and segwit discount, which of course has well-kn=
own
downsides.

There's a clear social/economic benefit to the Ordinals community that the
complete set of Ordinalds - and their inscriptions - is easy to extract and
will be available as long as Bitcoin block data itself will be available.
That's not going away and we should acknowledge that benefit honestly.

> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>=20
>   {
>     "pubkey": <creator's pubkey>
>     "kind": 0,
>     "tags": [
>       ["ord", "txid:vout:sat"]
>     ],
>     "content": [jpeg goes here],
>     "id": <hash of the above>
>     "sig": <signature of id by creator's pubkey>
>   }

nostr doesn't even have a clear data persistence model. As you know, nostr
messages are passed around by relays that make no enforceable promise of
actually keeping those messages or making them available. nostr doesn't have
any kind of blockchain, making it diffcult for others to archive messages
completely.  Advocating for its use in a protocol designed to support valua=
ble
collectables expected to be owned for a significant amount of time is reckl=
ess.

You know, we've been through all this before, years ago when colored coins =
were
first being discussed. Bitcoin Core devs who knew better would try to
discourage use of the Bitcoin chain for purposes they didn't approve of, by
suggesting solutions that they knew full well didn't really work. Solutions
like using OpenTimestamps inappropriately, alternative publication methods =
that
failed to provide the same level of security as Bitcoin, etc. It was dishon=
est
then, and it's disappointing to see a new generation of Bitcoin devs contin=
ue
this pattern of dishonesty.

> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.

The RGB protocol already does off-chain custody proofs, and implements NFTs.
You can already use this for real with Iris Wallet - the ownership chain of=
 a
RGB asset is _not_ visible on the blockchain, as ownership does not follow
satoshis. With more work, digital assets can even be transferred with
O(log_2(n)) scaling allowing billions of transfers per second:

    https://petertodd.org/2017/scalable-single-use-seal-asset-transfer

This of course is irrelevant to Ordinals, which will never have such a large
market.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--+Z5FCfXWuQtsGO06
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmPbyOkACgkQLly11TVR
LzcEpg/8CH7Zj4tf6XEYgYQZvYIEicIhnqEEfsKGzwI+1mGm8Yodz2QndIeeFg6F
hIZFLZxFPxYWn1BpXFSxZZUm7A9erzXX7j40G4Z0Rp1XCaARGu0t4FY+jGa49VRr
DKIpho3lXnfgkt+OFcO4TdQd2cfQg7J8zdUaCTy2li8UpUMrb15HuBU/9aRFCWOW
D1Ok0EMS7D/0x1tzfPeTemOXRP6joFeftSM1Iz6M3vU/EZvQGtyG+DL7NJF6SARv
QdRlVzx1me+TD0fSnYDuu6Jo9fYC4jlpfGyRfslBGtVAiNEQJ51vp+A+guR8N0hU
vdFjPu7/O4nz0AM/ZoyybmTxyPYTUurluhNqwrWaIDyLlfzBspfZtH1+d0ugFQcM
eRrm/aXUFvI3L4t6H9V2RYm6QwDzFLUyx0NXtfI/4mCsJ+l/RPFVqIljKx9YBK38
+DbnRhS2DaN3SPrHlx2kwr8xOVhVpTgWOqucBZWaVTirftpd87Sfxb5zAFhfr5Rc
6YFeQ/2UrmpoxVV709soTAQzH0kQ/fkwc5agWeYN9qrajhITMQn0joe8XDj3MDTc
JEUZ4I8cVHs6buZhEfb/ntvxxdSHFdiYJDcuo+7uwrrDqEXY2mJ2sQlUTzCt1w1z
z2oxFfS06mSuoxFyInKCx+5QJMpznJ7SfKIfUbMYcxMOwdDUB3g=
=KuBk
-----END PGP SIGNATURE-----

--+Z5FCfXWuQtsGO06--