I am not an expert with RGB, but it looks limited (only bitcoin chains from the github repo, apparently on hold), distributed over the "lightning network" or LN nodes (what is it?), or Bifrost extension, with a dubious token floating around, like ethereum mess as RGB docs describe Ethereum (and myself also), layer2 or layer3, certainly not decentralized (like still Bitcoin and Ethereum)

It's of course useless to trust IPFS or Bittorrent to store things because you cannot control the seeders who have zero incentive to seed such things

That's why in my much more simple proposals a well known third party is there, wayback machine, github, twitter, etc, if they disappear then probably internet has disappeared too, if they get censored you can still get a snapshot of what you did

The intent is certainly not to store NFTs in Bitcoin, only hashes, signatures and addresses, same for the third party proof, the NFT content if not real is stored elsewhere (up to people to decide where)

Additionally you can store in the third party the proof that something exists (the secret NFT), for example a small copy of the NFT electronic art, the buyer will get the full version once the deal is done and once he gets the decryption key, having the NFT for himself only

My proposals are not addressing wider D-stuff topics, supposedly decentralized, but no

So I don't think that it's a waste of time to change the OP_RETURN max size, currently it cannot even store <short message and/or hash> + <signature>, probably it's logical to align it to the script size limit (520B)

Or as I said previously deviant practices can happen, not expensive and just burning satoshis, which is not a super idea

I don't get why on bitcoin all proposals must always be super complicate, mine are simple, then take 5mn to read them


Le 02/02/2023 à 15:30, Peter Todd via bitcoin-dev a écrit :
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.



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com