From: Peter Todd <pete@petertodd•org>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Date: Thu, 2 Feb 2023 09:30:11 -0500 [thread overview]
Message-ID: <Y9vI8x6JcqdrvawF@petertodd.org> (raw)
In-Reply-To: <Y9t/NcgRzv1w//Fx@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 5072 bytes --]
On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
> Hi *,
>
> 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 stored 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 Arweave
rely on weak economic assumptions, and will likely fail catastrophically when
these economic assumptions are no longer met. Centralized web servers may
disappear at any time."
https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
That same FAQ also mention RGB and Taro, which already implements an off-chain
data model based on my Proofmarshal work. The Ordinals community is well aware
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 conspicuous
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 waste 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 this
is tweaks to the blocksize and segwit discount, which of course has well-known
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:
>
> {
> "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 valuable
collectables expected to be owned for a significant amount of time is reckless.
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 dishonest
then, and it's disappointing to see a new generation of Bitcoin devs continue
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-02-02 14:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 9:15 Anthony Towns
2023-02-02 12:19 ` Aymeric Vitte
2023-02-02 13:46 ` Rijndael
2023-02-02 14:22 ` alicexbt
2023-02-02 14:30 ` Peter Todd [this message]
2023-02-02 16:06 ` Aymeric Vitte
2023-02-03 6:39 Casey Rodarmor
2023-02-04 10:38 ` Anthony Towns
2023-02-04 11:36 ` Aymeric Vitte
2023-02-04 13:02 ` alicexbt
2023-02-04 13:06 ` Peter Todd
2023-11-17 7:58 ` Anthony Towns
2023-11-20 19:47 vjudeu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9vI8x6JcqdrvawF@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox