path: root/d6/b2d87c2b3cbc861b45134ff58a6cf54a4d23e9

Return-Path: <alicexbt@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 40AC1C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <aj@erisian.com.au>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <M7uxv9uqWUhcUJ4bLo-b8x0OrmUEfh-KOe2RXYdSJLkqcu2spT4vtU_2okLezW_BlbJTHn1OsgKbK1I1kjY8-MHjuzYraWZChn8LyRn4w1o=@protonmail.com>
In-Reply-To: <Y9t/NcgRzv1w//Fx@erisian.com.au>
References: <Y9t/NcgRzv1w//Fx@erisian.com.au>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 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": <creator's pubkey>
>=20
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id": <hash of the above>
>=20
> "sig": <signature of id by creator's pubkey>
>=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