path: root/76/76a7fb7abf9eeffa17adc99f64c65e1c645143

Return-Path: <aymeric@peersm.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F1A55C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 12:19:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id DA2DA40A09
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 12:19:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DA2DA40A09
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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id PH3DGFv2M5az
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 12:19:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7A211403F8
Received: from smtpout3.mo529.mail-out.ovh.net
 (smtpout3.mo529.mail-out.ovh.net [46.105.54.81])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 7A211403F8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 12:19:32 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.108.20.243])
 by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 9625E215B2;
 Thu,  2 Feb 2023 12:19:29 +0000 (UTC)
Received: from peersm.com (37.59.142.99) 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 13:19:28 +0100
Authentication-Results: garm.ovh; auth=pass
 (GARM-99G0030fab4cc4-d417-4d81-a105-38c51a9d08da,
 6AA1D679F834A14CBEAA49266E816969C7C1CEBF) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.100.16
To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
References: <Y9t/NcgRzv1w//Fx@erisian.com.au>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <b20268b5-839c-1939-528c-0504b64860b1@peersm.com>
Date: Thu, 2 Feb 2023 13:19:28 +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: <Y9t/NcgRzv1w//Fx@erisian.com.au>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [37.59.142.99]
X-ClientProxiedBy: DAG1EX2.mxp6.local (172.16.2.2) To DAG6EX2.mxp6.local
 (172.16.2.52)
X-Ovh-Tracer-GUID: 9388ff0d-1dbf-4c5d-83af-2c23d9d2a15f
X-Ovh-Tracer-Id: 12272590463256126362
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedgfeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgihesthekredttdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnheptedtkefgheelveeukeekvefffeeflefgffekvdekleefjeejteelvdehfffgieegnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpohhrughinhgrlhhsrdgtohhmpdhtfihithhtvghrrdgtohhmpdgvshhpnhdrtghomhdplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphgvvghrshhmrdgtohhmpdhlihhnkhgvughinhdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeorgihmhgvrhhitgesphgvvghrshhmrdgtohhmqedpnhgspghrtghpthhtohepuddprhgtphhtthhopegsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdgrjhesvghrihhsihgrnhdrtghomhdrrghupdfovfetjfhoshhtpehmohehvdelpdhmohguvgepshhmthhpohhuth
X-Mailman-Approved-At: Thu, 02 Feb 2023 13:02:30 +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 12:19:35 -0000

In your system what is the off-chain mechanism? And what prevent a thief
to steal your NFT?

I have submitted several time "A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7

It's more simple, the NFT (whether real or electronic) is referenced by
a initial hash (which is not the hash for example of your jpeg file
because easy to fake) and then get a final reference which is the hash
of the initial hash

The idea is that the real owner must prove that he has the knowledge of
the initial hash (for example luxury bag, you print the double hash on
it, and give the initial hash to the buyer, if the owner/seller can't
prove that he knows the inital hash, the bag is stolen or counterfeit
(with the double hash))

The NFT owner references the NFT signed by him in some trusted third
party allowing a timestanp (wayback machine for example), it proves that
he is the first one to have the knowledge of the double hash, so a thief
cannot intercept the "minting" transaction (if any because not really
necessary since the public key of the owner is known from the third
party) and steal the NFT for himself or do/replay a transaction with
this NFT, minting it or selling it several time

A third party is involved but it remains decentralized

Then the NFT owner and buyer exchange some information like for
lightning and do one transaction on Bitcoin storing the deal, see the
details in the proposals depending on what kind of deal occur between
the buyer and the seller, like lightning, if someone cheats, then he
loses his bitcoin

It's minimal, understandable, secured, decentralized and not expensive,
that's why I don't see very well why to complicate with ordinals

The proposal envisions the concept of "secret" NFTs also


The continuation of this proposal is "A Universal Coin Swap system based
on Bitcoin" https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7

It's simple also, you go from Decentraland to the Sandbox but don't have
SAND and want to pay with MANA, you agree on a MANA/SAND deal with the
seller which is stored in Bitcoin signed by both, then you pay with
MANA, other use cases are described in the proposal

Note: both proposals need to be modified since I thought OP_RETURN max
size was 512B and it is in fact 80B, which does not work for all cases


Le 02/02/2023 à 10:15, Anthony Towns via bitcoin-dev a écrit :
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
>
> On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
>> Briefly, newly mined satoshis are sequentially numbered in the order in
>> which they are mined. These numbers are called "ordinal numbers" or
>> "ordinals". When satoshis are spent in a transaction, the input satoshi
>> ordinal numbers are assigned to output satoshis using a simple
>> first-in-first-out algorithm.
> This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408
>
> When accompanied by a standard for associating some data or right with
> such an identity, this allows the creation of non-fungible tokens (or
> semi-fungible tokens) whose ownership can be transferred by a bitcoin
> transaction.
>
> The proposed BIP doesn't document any method for associating data or a
> right with an ordinal, but the "ord" tool defines "inscriptions" to fill
> this gap [0], providing a way of including mime-encoded data in a taproot
> witness. To make such an inscription, two transactions are required:
> one paying some sats to a special scriptPubKey that commits to the
> inscribed data, and a second that spends those sats to the owner of the
> newly inscribed ordinal, and in so doing revealing the full inscription.
>
> [0] https://docs.ordinals.com/inscriptions.html
>
> 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.
>
> [1] https://twitter.com/ajtowns/status/1619554871166013441
>
> In particular, rather than looking at it as being the owner of the sats
> that inscribes some content on those sats (analogously to signing a $100
> bill [2]), you could look at it as saying "the owner of this thing is
> whoever owns this particular sat" (eg instead of "whoever owns this
> share certificate is a shareholder", it's "whoever owns the $1 bill with
> serial number X is a shareholder").
>
> [2] https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph-cleveland-browns-qb-johnny-manziel-getting-offers
>
> 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>
>   }
>
> 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.
>
> [3] If the satoshi was lost to fees at some point, you could continue to
>     follow ownership by including an entire block in the custody chain.
>     But seems better to just consider it as "abandoned" or "lost to the
>     public domain" at that point.
>
> This approach allows all the "inscription" data to be entirely off-chain,
> the only thing that requires a transaction on-chain is transferring
> ownership to someone else. That allows the NFT's existance can be kept
> entirely private if desired; it also makes it cheap to create a new NFT
> (you don't need to pay any on-chain fees at all); and it doesn't impose
> an outsized overhead on people who aren't interested in your inscriptions,
> but may be interested either in bitcoin per se, or in other inscriptions.
>
> For things that have real intrinsic value -- equity rights in a company,
> bragging rights for supporting an artist, etc -- this seems like it's
> probably a viable approach: owners can "self-custody" all the information
> about the things they own without having to rely on third parties,
> transfers are no more censorable than any other bitcoin transaction
> (especially if the association of the NFT with some particular sat is
> not widely known), etc.
>
> The "inscription" approach might still be desirable for broadcasting
> information that might otherwise be subject to heavy censorship; presuming
> that the censoring entity isn't also willing and able to censor bitcoin
> itself. It's not clear that there's any "rights" to be owned for such a
> case -- you can't buy the right to be the person that first published
> it, and the point of widely broadcasting the information is so it's
> not a secret only known to a few anymore. Also, claiming ownership of
> such information would presumably make you a target for the censor,
> even if just as an example for others. So I'm dubious of the value of
> associating an inscription with an ordinal for that use case.
>
> It's also possible that the perceived value of the NFT isn't due to
> the inscription, but rather due to the scarcity of the blockspace it
> was inscribed in (eg [4]). This is different from Bitcoin's scarcity
> -- by 2100 or so there'll be a total of 2100T satoshis available,
> but in that same time there will only have been about 4T vbytes of
> blockspace available, and perhaps it could make sense to value spent
> vbytes proportionally, so 4 spent vbytes is worth 2100 sats. In that
> case if you spent 50kvb inscribing a jpeg, perhaps the "rights" to that
> jpeg should be worth the same as 50k/4*2100 sats or 0.26 BTC. Doesn't
> seem like a sound argument to me -- there's always more blockspace being
> created, by fewer and fewer sats being created, and ordinals are far more
> awkward to deal with, but I suppose it's still conceivable, and people
> at least claim to believe it. If it were true, this argument suggests
> the price for blockspace today should be around 2488sat/vB (19.28MBTC /
> 774700 MvB), rather than 1sat/vB.
>
> [4] https://twitter.com/vnprc/status/1619876888687820801
>
> Anyway, comparisons to ordinal inscriptions aside, I think there's
> another interesting point from all this.
>
> Presume you have a tool that implements the nostr ordinal assignment
> suggested above: that is, a small modification of the "ord" tool that
> can track a chain of custody for an ordinal specified in a nostr event
> like the above. That allows you to do NFTs completely unobservably --
> you don't have to publish anything to the blockchain apart from ordinary
> looking transactions to transfer ownership of your NFT. To your benefit,
> that makes it hard for anyone to censor you; but to bitcoin more broadly,
> I think it means that the possibility of coloured bitcoins is largely
> unavoidable and simply something that must be dealt with, rather than
> something we should spend time trying to prevent/avoid. Compare with:
>
>> My personal, and possibly controversial, opinion is that colored coin
>> protocols have no business being on the Bitcoin chain, possibly beyond
>> committing to an occasional batched state update or so. Both because
>> there is little benefit for tokens with a trusted issuer already, and
>> because it competes with using Bitcoin for BTC - the token that pays
>> for its security (at least as long as the subsidy doesn't run out).
>>
>> Of course, personal opinions are no reason to dictate what people should
>> or can use the chain for, but I do think it's reason to voice hesitancy
>> to worsening the system's scalability properties only to benefit what
>> I consider misguided use.
>  -- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019500.html
>
> I don't think this actually results in majorly misaligned incentives
> though: in the nostr-nfts-on-btc world, everyone is still optimising
> bitcoin transactions for the same thing -- transfer of value. It's just
> that in some cases some sats are valued differently than others --
> perhaps my uninscribed sats are worth 0.025 cents each, but you have
> a particular inscribed sat that's worth $100k. But we're both dealing
> just spending utxos and creating new utxos, doing signatures and maybe
> some timelocks or hash reveals. And it's always been possible that
> your transaction transferring $100k won't get charged higher fees than
> my transfer of $50 -- we care about transaction size, not value after
> all. How much does it matter if your tx matters more to your because
> someone wants your particular sat, rather than what could happen today
> where you have a utxo with 4 BTC while my utxo only has 0.002 BTC?
>
> I think the only way to prevent that sort of NFT structure would be
> to have every transaction use fancy zero-knowledge proofs that make it
> impossible to associate who received bitcoin with who spent it -- *even
> if* both the sender and recipient were willing to cooperate to reveal
> that information. I think it would be hard to achieve that while still
> making it easy to audit bitcoin's total supply, but I might be wrong.
>
> Note that off-chain colouring here means that someone can create an NFT
> that you don't want it, and just assign it to a sat that's already in your
> wallet. However, they can do this anyway, by first creating the NFT, then
> sending it to your wallet address. A difference though is that they could
> create an NFT and assign it to the same ordinal/sat as some existing NFT
> that you do value, at which point it's (presumably) impossible to discard
> one without discarding both. But again, this is simply something they
> can do, just be writing a patch to ord and composing a nostr message;
> it's not something you can actually prevent even if you dislike it.
>
> Particularly for semi-fungible tokens, this is perhaps inferior to
> Liquid's multi-asset model -- here if you have a utxo with 1M sats, 500
> of which are inscribed to each represent rights to $1 worth of USDT,
> then rather than acting like a stable coin and being worth $500; it's
> actually worth $500+0.01BTC, which is more like $750, and changes as
> the value of bitcoin changes.
>
> Cheers,
> aj
> _______________________________________________
> 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