From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1882FC002B for ; Thu, 2 Feb 2023 17:22:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id F3A76611BE for ; Thu, 2 Feb 2023 17:22:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F3A76611BE 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeeuXXlx76dc for ; Thu, 2 Feb 2023 17:22:54 +0000 (UTC) X-Greylist: delayed 00:40:00 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A7CC5611B8 Received: from 7.mo548.mail-out.ovh.net (7.mo548.mail-out.ovh.net [46.105.33.25]) by smtp3.osuosl.org (Postfix) with ESMTPS id A7CC5611B8 for ; Thu, 2 Feb 2023 17:22:53 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.108.4.102]) by mo548.mail-out.ovh.net (Postfix) with ESMTPS id D5ED620EEF; Thu, 2 Feb 2023 16:06:03 +0000 (UTC) Received: from peersm.com (37.59.142.102) by DAG6EX2.mxp6.local (172.16.2.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Thu, 2 Feb 2023 17:06:03 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-102R0043125a7d4-5784-47e4-8bbf-bc27141f9d1b, 6AA1D679F834A14CBEAA49266E816969C7C1CEBF) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.100.16 To: Peter Todd , Bitcoin Protocol Discussion , Anthony Towns References: From: Aymeric Vitte Message-ID: <43ea2d30-182a-5c8b-4c86-93679659183d@peersm.com> Date: Thu, 2 Feb 2023 17:06:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EBACC1FAB75D205DC55762A8" X-Originating-IP: [37.59.142.102] X-ClientProxiedBy: DAG4EX1.mxp6.local (172.16.2.31) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: bbb4a308-8ebd-4a9d-8db2-8a6e9cf92430 X-Ovh-Tracer-Id: 16098961295877563357 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedgjeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepieffueejffdthfekkedtgfejgeethefhheelheeghfektdeivdffveffieeikeevnecuffhomhgrihhnpegrrhgthhhivhgvrdhorhhgpdhorhguihhnrghlshdrtghomhdpphgvthgvrhhtohguugdrohhrghdplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphgvvghrshhmrdgtohhmpdhlihhnkhgvughinhdrtghomhdpghhithhhuhgsrdgtohhmnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeorgihmhgvrhhitgesphgvvghrshhmrdgtohhmqedpnhgspghrtghpthhtohepuddprhgtphhtthhopegrjhesvghrihhsihgrnhdrtghomhdrrghupdgsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvghtvgesphgvthgvrhhtohguugdroh hrghdpoffvtefjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht X-Mailman-Approved-At: Thu, 02 Feb 2023 17:45:20 +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: Thu, 02 Feb 2023 17:22:56 -0000 --------------EBACC1FAB75D205DC55762A8 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit 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 + , 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: > > >> 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": >> "kind": 0, >> "tags": [ >> ["ord", "txid:vout:sat"] >> ], >> "content": [jpeg goes here], >> "id": >> "sig": >> } > 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 --------------EBACC1FAB75D205DC55762A8 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

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