path: root/83/7eaccd503da65dfee8498bce113012f408a258

Return-Path: <aymeric@peersm.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1882FC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <pete@petertodd.org>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>, Anthony Towns <aj@erisian.com.au>
References: <Y9t/NcgRzv1w//Fx@erisian.com.au> <Y9vI8x6JcqdrvawF@petertodd.org>
From: Aymeric Vitte <aymeric@peersm.com>
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: <Y9vI8x6JcqdrvawF@petertodd.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>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)<br>
      <br>
      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<br>
      <br>
      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<br>
      <br>
      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)<br>
      <br>
      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 <br>
      <br>
      My proposals are not addressing wider D-stuff topics, supposedly
      decentralized, but no<br>
      <br>
      So I don't think that it's a waste of time to change the OP_RETURN
      max size, currently it cannot even store &lt;short message and/or
      hash&gt; + &lt;signature&gt;, probably it's logical to align it to
      the script size limit (520B)<br>
      <br>
      Or as I said previously deviant practices can happen, not
      expensive and just burning satoshis, which is not a super idea<br>
      <br>
      I don't get why on bitcoin all proposals must always be super
      complicate, mine are simple, then take 5mn to read them<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 02/02/2023 à 15:30, Peter Todd via
      bitcoin-dev a écrit :<br>
    </div>
    <blockquote cite="mid:Y9vI8x6JcqdrvawF@petertodd.org" type="cite">
      <pre wrap="">On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hi *,

Casey Rodarmor's ordinals use the technique of tracking the identity of
individual satoshis throughout their lifetime:
</pre>
      </blockquote>
      <pre wrap="">
&lt;snip&gt;

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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."
    <a class="moz-txt-link-freetext" href="https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html">https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html</a>

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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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": &lt;creator's pubkey&gt;
    "kind": 0,
    "tags": [
      ["ord", "txid:vout:sat"]
    ],
    "content": [jpeg goes here],
    "id": &lt;hash of the above&gt;
    "sig": &lt;signature of id by creator's pubkey&gt;
  }
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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:

    <a class="moz-txt-link-freetext" href="https://petertodd.org/2017/scalable-single-use-seal-asset-transfer">https://petertodd.org/2017/scalable-single-use-seal-asset-transfer</a>

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

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Sophia-Antipolis, France
CV: <a class="moz-txt-link-freetext" href="https://www.peersm.com/CVAV.pdf">https://www.peersm.com/CVAV.pdf</a>
LinkedIn: <a class="moz-txt-link-freetext" href="https://fr.linkedin.com/in/aymeric-vitte-05855b26">https://fr.linkedin.com/in/aymeric-vitte-05855b26</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a>
A Universal Coin Swap system based on Bitcoin: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a>
A bitcoin NFT system: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7">https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a>
Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" href="https://peersm.com/wallet">https://peersm.com/wallet</a>
Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.peersm.com">http://torrent-live.peersm.com</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a></pre>
  </body>
</html>

--------------EBACC1FAB75D205DC55762A8--