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 40AC1C002B for ; Thu, 2 Feb 2023 14:22:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 15C62608B7 for ; Thu, 2 Feb 2023 14:22:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 15C62608B7 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=qikRApmy X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 COPlpg8BTqEw for ; Thu, 2 Feb 2023 14:22:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 98CCD6072A Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp3.osuosl.org (Postfix) with ESMTPS id 98CCD6072A for ; Thu, 2 Feb 2023 14:22:26 +0000 (UTC) Date: Thu, 02 Feb 2023 14:22:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1675347743; x=1675606943; bh=l0Wo3uhJmDZosmLiHG/4BW1XOMkJTuBZIWkLF6zmkYs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=qikRApmydawlBDgGEW6zjJRbpG397Oh33acyD7V4v2JQHiyjqMxpZ9a4kLKj63OWM ng2VjOGBtej/Pjd+6/GRdfDH8VBCJav/C7h3eWwO5vEJ6ygGHUdFzc8yymWAtpIMYR 9BQz04YtVzV90cyDusQP4NI8UB3Qjp7z54ttuTzj8oyo5kmfcynywypO16Ca29OlI5 lJJ8XPBNsZoBrOZuv8BoF3MVknyAVSI0mc8KvnPfDOGoUhZ+jzl7SYeitWsprzqZXg kDQeRhiqK2+l7jZ7uV7NiJsaOysV3qBa6ohY8tGPGq8Z5yJeU8re8hgMg9NbPUiHNQ UuNc+Uo6HQ/WA== To: Anthony Towns From: alicexbt Message-ID: In-Reply-To: References: Feedback-ID: 40602938: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 Cc: Bitcoin Protocol Discussion 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 14:22:28 -0000 Hi Anthony, > 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. Whole point of inscriptions is to keep something on-chain associated with y= our sats so this approach goes against the concept and what makes them inte= resting in the first place. > 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: All events may not be permanently stored by Nostr relays. In addition to re= ndering inscriptions meaningless, this creates a dependency. > 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. If bitcoin transactions can be censored then we have bigger problems to car= e about as bitcoin will have no value without censorship resistance. Lastly, I would add that inscriptions involve "financial" transactions, ass= ociating sats with image is freedom and got historical reasons for it. Writ= ing something on paper or drawing an image on copper is not same as doing i= t on gold. Disclaimer: My opinion on inscriptions can be biased because I am working o= n a startup that will use inscriptions and satscard(coinkite) /dev/fd0 floppy disc guy Sent with Proton Mail secure email. ------- Original Message ------- On Thursday, February 2nd, 2023 at 2:45 PM, Anthony Towns via bitcoin-dev <= bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi *, >=20 > Casey Rodarmor's ordinals use the technique of tracking the identity of > individual satoshis throughout their lifetime: >=20 > On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev = wrote: >=20 > > 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. >=20 >=20 > This is proposed as a BIP at https://github.com/bitcoin/bips/pull/1408 >=20 > 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. >=20 > 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. >=20 > [0] https://docs.ordinals.com/inscriptions.html >=20 > 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= . >=20 > [1] https://twitter.com/ajtowns/status/1619554871166013441 >=20 > 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"). >=20 > [2] https://www.espn.com/nfl/story/_/id/14375536/owner-100-bill-autograph= -cleveland-browns-qb-johnny-manziel-getting-offers >=20 > 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: >=20 > { > "pubkey": >=20 > "kind": 0, > "tags": [ > ["ord", "txid:vout:sat"] > ], > "content": [jpeg goes here], > "id": >=20 > "sig": >=20 > } >=20 > 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. >=20 > [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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > [4] https://twitter.com/vnprc/status/1619876888687820801 >=20 > Anyway, comparisons to ordinal inscriptions aside, I think there's > another interesting point from all this. >=20 > 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: >=20 > > 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). > >=20 > > Of course, personal opinions are no reason to dictate what people shoul= d > > 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. >=20 >=20 > -- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September= /019500.html >=20 > 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? >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Cheers, > aj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev