Re: [bitcoin-dev] Purely off-chain coin colouring

[Aymeric Vitte <aymeric@peersm.com>]

[-- Attachment #1: Type: text/plain, Size: 7844 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 10270 bytes --]