path: root/a1/31bc38abce5eac8cadc1a4febdb13e0d33c582

Return-Path: <rot13maxi@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AA930C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 13:46:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 7E95D418CC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 13:46:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7E95D418CC
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=jhDPAed/
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4G5BopELw2YS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 13:46:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 19C7541529
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 19C7541529
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Feb 2023 13:46:51 +0000 (UTC)
Date: Thu, 02 Feb 2023 13:46:35 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1675345608; x=1675604808;
 bh=TgBzPhIabTz8lOU7xAOs4OHS20LzVnPDBOkgtwTkfuw=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=jhDPAed/3O90IRNnhA333hWPkhZwE0fm3Vi9gqVhvkRSy88NfIUK21rH+7szrm90D
 OxOby+9eUgDLyDGsjDbKwXP4GsNgHYzHkHJWV3mL2c4PiZtJdQ7LQZ/B7+zTDP+3E9
 eArE1R8cU1E66xvqE1cSjSXUh62XnnDy9GS14gTXSkNCy1razWwO4GVTm6nAuc2SI5
 Gg49QgkR5zLgzP1tXnlgSpwMwncFlI9d/KZNKN7FBPT9nydO7ZsI2zFPHXmRtWZ6ZH
 Z50fJMITWIevfGre4IxW1TgquE6oHSU/piHGmtDFM4WYQkq++uUoVbyFc6EvdkV0K0
 rVVuHq0gvuDGw==
To: bitcoin-dev@lists.linuxfoundation.org
From: Rijndael <rot13maxi@protonmail.com>
Message-ID: <72f76cbc-c62f-743f-71e9-3ae61f3fdc33@protonmail.com>
In-Reply-To: <Y9t/NcgRzv1w//Fx@erisian.com.au>
References: <Y9t/NcgRzv1w//Fx@erisian.com.au>
Feedback-ID: 41648937:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 02 Feb 2023 14:23:46 +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 13:46:53 -0000

Hi AJ and List,

This reminds me of a series of blog posts Peter Todd wrote a few years
ago about using "single use seals" for tracking (fungible) assets
anchored to Bitcoin[0]. I believe that the RBG Protocol Project and Taro
are both using the same underlying principle.

Having the actual application data offchain, but with a commitment to a
UTXO and then using Bitcoin only as a proof-of-publication system to
prevent double-spends seems like a really good idea. As you point out,
in addition to being cheaper and more scalable, it means that not
everyone on the network has to know that there's an asset involved. It
just looks like plain old bitcoin transfers.

A lot of people have written about or are (I think) working on
implementations of this idea. I really like your suggestion of using
nostr. Clients can keep the asset metadata chains locally in their
client and (re)broadcast them to application-specific nostr relays, or
to general public relays depending on application needs. Maybe there's a
marketplace application that has its own relays and also broadcasts
asset metadata to relays used by popular gallery systems. Or maybe your
client just sends to any relay it sees that doesnt have the event. Big
design space there.

- rijndael

0: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer


On 2/2/23 4:15 AM, Anthony Towns via bitcoin-dev wrote:
> 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; presumin=
g
> 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-Septemb=
er/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 you=
r
> 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