Date: Sat, 04 Feb 2023 13:02:44 +0000
To: Anthony Towns <aj@erisian.com.au>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <Chw5YOIKGnaIB-wcu3CLdNyfT4JoMmrqMmT68jtG4nv75N_SchnB7MPQ_hmRgz2MK-tuIPBqmYp0qA13VQUHevmsjDzKE_2XY0WK2qhlL4c=@protonmail.com>
In-Reply-To: <Y941vsOOsZJHdnKT@erisian.com.au>
References: <CANLPe+Pa-D=JB8N5Qeokoyp=mRA3LLM=mtvvwPkpbHvV_bmEXQ@mail.gmail.com>
 <Y941vsOOsZJHdnKT@erisian.com.au>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Precedence: list

Hi Anthony,

> As far as salience/notability goes, personally, I'd see ownership of
inscriptions as a negative indicator; "hey, when I was young and foolish I
wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
permanent cost for everyone trying to use bitcoin in future". That's not
unforgivable; people do all sorts of foolish things, and bitcoin's meant
to survive attacks, not just foolish pranks. But it doesn't seem like
something to brag about or encourage, either, at least if you want bitcoin
to be a monetary network that's usable in practice by many/most people.

Moving transactions off-chain because of emotions or personal opinions does=
 not make sense.=20
Everyone running a bitcoin node is aware of block limits and they could be =
filled with different type of transactions including [non-inscription txs][=
0] that use witness for complex scripts.

> And if
a public site like ordinals.net is willing to store all the inscriptions
that might be on the blockchain, they could just as easily store the
same amount of off-chain digital assets.

[Ord explorer][1] is open source and gets inscriptions from blockchain.

> Obviously blockchains aren't the only "scarce" good out there. If scarcit=
y
is your goal, there's two very easy ways to make your own scarcity.=20

Using pow doesn't make nostr relays "scarce". Its mainly used to avoid spam=
 but some spammers on nostr have proved it isn't enough.=20

> then in the off-chain world, they would look like two events:

Nostr relays do not guarantee that these events will be stored [forever][2]=
.

> As I've said above, the off-chain approach seems
much better aligned with incentives to me, with the people who gain the
benefit from that association paying the cost of preserving it.

Cost for running bitcoin node do not change with inscriptions and do not de=
pend on the content or intent of any bitcoin transaction. It is a permissio=
nless network and users can decide how to use money and blockspace.

Campaigns to censor such transactions or other efforts to move them off-cha=
in are creating a slippery slope that could affect bitcoin more than some i=
nscriptions. If Casey is harassed enough on social media and ord project mo=
ves inscriptions off-chain, there would be forks of it doing it on-chain.


[0]: https://twitter.com/mononautical/status/1621663167582437376
[1]: https://github.com/casey/ord
[2]: https://twitter.com/damusapp/status/1621431556048035841


dev/fd0
floppy disc guy

Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, February 4th, 2023 at 4:08 PM, Anthony Towns via bitcoin-dev <=
bitcoin-dev@lists.linuxfoundation.org> wrote:


> On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev =
wrote:
>=20
> > Apologies for posting! I've tried to keep discussion of ordinals and
> > inscriptions off-list, because I consider it to be of little relevance =
to
> > general Bitcoin development.
>=20
>=20
> Anything that potentially uses up a large percentage of blockspace seems
> pretty relevant to general Bitcoin development to me...
>=20
> > AJ Towns writes:
> >=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 m=
ore
> > > thought, I think pushing things even further off-chain would be plaus=
ible.
>=20
>=20
> I guess I should have explained why I think moving things off-chain is
> a worthwhile goal. Riffing off:
>=20
> > Another issue is salience and scarcity, as has been mentioned. Off-chai=
n
> > content is unbounded, and thus less scarce. Usually, we design for
> > efficiency, volume, and scale. For NFT designs, which are intended to b=
e
> > collectable, this is in some ways counterproductive.
>=20
>=20
> "scarce" has two meanings -- one is that there's not much of it, the
> other is that it's highly valued (or a third, where it's is consistently
> underpriced and unavailable even for people who'd pay more, but that
> hopefully doesn't apply).
>=20
> I think for bitcoin's blockspace, we ideally only want the first of
> these to be true. We want small blocks because that makes it cheap to
> verify bitcoin, which reduces the need to trust third parties and aids in
> decentralisation. But we don't want blockspace to be especially valuable,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.
>=20
> Moving things off-chain helps with both these goals: it doesn't make it
> harder to validate bitcoin, and it also decreases demand for blockspace,
> making it cheaper for those cases where things can't be moved off-chain.
>=20
> As a result of this approach, bitcoin blockspace is currently quite
> cheap -- so inscribing at 100kB jpeg at 25kvB might cost perhaps $60 in
> a peak period, or $6 if you wait for 1sat/vb to confirm. Not exactly a
> luxury purchase.
>=20
> If you keep jpegs on-chain, as far as I can see, there's three outcomes:
>=20
> * blockspace stays relatively cheap, and there's no "scarcity" benefit to
> minting via on-chain inscriptions; it's cheap enough to just mint
> any random meme, and there's no prestige to doing so
>=20
> * blockspace becomes filled with jpegs, driving up costs for everyone,
> making jpeg collectors happy, but transactors sad
>=20
> * the amount of blockspace is increased, keeping prices low, and
> reducing "scarcity" in both senses, so also making it harder to
> validate bitcoin. no one really wins.
>=20
> I'd guess the first of these is the most likely, personally.
>=20
> As far as salience/notability goes, personally, I'd see ownership of
> inscriptions as a negative indicator; "hey, when I was young and foolish =
I
> wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating a
> permanent cost for everyone trying to use bitcoin in future". That's not
> unforgivable; people do all sorts of foolish things, and bitcoin's meant
> to survive attacks, not just foolish pranks. But it doesn't seem like
> something to brag about or encourage, either, at least if you want bitcoi=
n
> to be a monetary network that's usable in practice by many/most people.
>=20
> (Even if one day that goes the other way, and there is real (and
> transferable) social value in being able to say "I donated x sats to fees
> to help secure bitcoin", such a claim is more charitable/admirable/value
> with a smaller on-chain footprint, both in that it again keeps
> validation easier, but also in that it makes it easier for others to
> also simultaneously make the same charitable contribution)
>=20
> > NFT collectors have a strong revealed preference for on-chain content. =
The
> > content of high-value NFTs is often stored partially or completely on
> > chain,
>=20
>=20
> When you identify an NFT by a url that points at someone else's server,
> that's an obvious vulnerability, as Moxie demonstrated pretty well.
>=20
> But solving that by saying "okay, we'll just externalise the storage
> costs to the public, while privatising all the benefits" isn't a good
> approach either.
>=20
> > User protection when off-chain content is involved is fraught.
>=20
>=20
> I mean, that seems trivially solvable? Users already have to store the
> private key that controls ownership of these digital assets; storing the
> asset as well, which doesn't need to be private, isn't a big ask. And if
> a public site like ordinals.net is willing to store all the inscriptions
> that might be on the blockchain, they could just as easily store the
> same amount of off-chain digital assets.
>=20
> > When a user buys an NFT with
> > off-chain content, they now have the primary economic incentive to pres=
erve
> > that content, so that their NFT retains value and can be enjoyed or sol=
d.
>=20
>=20
> Yes -- the people who potentially benefit from the NFT should be the
> ones paying the costs of preserving that NFT.
>=20
> > Many existing NFT marketplaces that sell off-chain content do not expla=
in
> > this to users, or give users tools that the average, non-technical pers=
on
> > can understand or use, which enables them to protect themselves. Even i=
f
> > they did give users these tools, there are tricky considerations involv=
ed.
> > IPFS functions much like BitTorrent,
>=20
>=20
> Externalising the costs to some different network while privatising the
> benefits isn't any better than doing it to bitcoin; except in that maybe
> you're inconveniencing fewer people.
>=20
> Going back to this:
>=20
> > Another issue is salience and scarcity, as has been mentioned. Off-chai=
n
> > content is unbounded, and thus less scarce. Usually, we design for
> > efficiency, volume, and scale. For NFT designs, which are intended to b=
e
> > collectable, this is in some ways counterproductive.
>=20
>=20
> Obviously blockchains aren't the only "scarce" good out there. If scarcit=
y
> is your goal, there's two very easy ways to make your own scarcity.
>=20
> One is requiring proof of work -- you could have a digital
> asset marketplace that only allows works that have a hash with
> at least 32 leading zero-bits [0] and use timestamping [1] (or a
> certificate-transparency approach) to ensure that as proof-of-work
> techonology improves, it can't be used to backdate mints.
>=20
> [0] https://github.com/nostr-protocol/nips/blob/master/13.md
> [1] https://github.com/nostr-protocol/nips/blob/master/03.md
>=20
> Or the other approach is you just require people to pay you some sats
> over lightning to host an NFT. That way you're the one collecting the
> fees, not miners; and you're (perhaps) the one incurring an obligation
> to preserve the NFT on behalf of its owners, rather than random bitcoin
> node operators.
>=20
> > The above issues also make the specification and implementation of NFTs
> > with off-chain content much more difficult.
>=20
>=20
> I'm not meaning to criticise you for doing what you think's interesting,
> so if it's coming off that way I apologise in advance. I think it's
> interesting, too. I just think that, when possible, off-chain is always
> better than on-chain, and it's worth exploring that idea further.
>=20
> In particular, I don't think it is actually much more difficult? Here's
> how I'd change what you've done to turn ordinals.net into an off-chain
> digital asset site:
>=20
> - setup a nostr relay, with submissions gated by proof of work, and
> no expiry. maybe https://github.com/Cameri/nostream ?
>=20
> - for any event that includes an "ordinal" tag, treat it as a digital
> asset, and add it to your digital asset database, just like you do now
> for inscriptions. either have your own nostr client that subscribes
> to your relay, or just query your relay's db directly.
>=20
> - have a regular proof of work adjustment targeting say 200MB worth of
> events per day (vs the 576MB per day of possible witness data).
>=20
> - update the ord tool to be able to encode digital artifacts into a nostr
> event, apply proof of work to it, and send it to (by default)
> your relay.
>=20
> That would let nostr clients immediately just add your relay and get a
> feed of minted digital artifacts, that's already spam-free due to the
> proof of work requirement. They could follow all of them, or just follow
> a particular artist by pubkey, too. An artist could publish a collection
> by publishing an event defining the collection, then linking each artwork
> to the collection as a "reply", making it pretty easy for nostr clients
> to follow a collection, while still having each artwork linked to its
> own ordinal, and I think without requiring any work on your behalf.
>=20
> You don't need to change the way ordinals are spent at all for any of
> this, I think; all you're doing is replacing the initial two transactions
> that link the digital artifact with the ordinal with an off-chain message
> achieving the same thing.
>=20
> Then to go beyond what you've got you could:
>=20
> - add some support for the current owner of an ordinal to link that
> back to their nostr profile -- eg, sign a message with the pubkey
> based on the current utxo holding the ordinal, referencing the digial
> asset; you could perhaps use NIP-2 "following" messages for this.
> if you've already using an open social network, might as well take
> advantage of it.
>=20
> - add some support for the "social legitimacy" aspect -- eg linking
> all the assets created by the same public key as an artist's portfolio;
> make it easy to go from their nft-related pubkey to their regular
> nostr profile or similar.
>=20
> - let creators that have already somehow demonstrated "social legitimacy"
> bypass the proof of work requirement, since "great art" is already
> naturally scarce. creators who've demonstrated their quality shouldn't
> need to waste time or money doing proof of work or paying blockchain
> fees
>=20
> Adding a lightning based patreon-type setup could be awesome there --
> content creators post content to a closed relay, patrons pay a fee
> over lightning to be able to receive events, and 90%+ of those fees
> are passed on to creators. If creators are happy with subscriptions,
> they just do that; if they want to auction off NFTs, they can do that;
> if they want both, that works too...
>=20
> > Additionally, I think the term "inscription" which has a connotation of
> > permanence, and of an indelible association with a particular satoshi, =
is
> > inappropriate for an off-chain NFT protocol.
>=20
>=20
> No objections about the "inscription" definition, but I'm not sure if the
> above means you're misunderstanding what I'm saying. In the off-chain
> scheme I'm talking about, the "digital asset" includes the ordinal
> that controls ownership, and is identified by the hash of its contents,
> including that ordinal's identity -- so there is an indelible association
> with a particular satoshi, despite it being an off-chain NFT protocol.
>=20
> For example if you take two identical digital assets, such as:
>=20
> https://ordinals.net/inscription/8ed2594cecbd43e5673168ff160ba00a6d8953fe=
a7ab6b15a112f3bc94adc2f8i0
>=20
> https://ordinals.net/inscription/31e9577f9af1d1823bc00539291f061e4ac9ba72=
7162a8e0d8d7b80512966561i0
>=20
> then in the off-chain world, they would look like two events:
>=20
> {
> pubkey: <Alice>
>=20
> kind: 0
> tags: [
> ord: "8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94adc2f8:0:=
0"
> ]
> content: <av1.jpeg>
>=20
> id: <XXXX - hash of the above>
>=20
> sig: <sig by alice of XXXX>
>=20
> }
>=20
> and
>=20
> {
> pubkey: <Alice>
>=20
> kind: 0
> tags: [
> ord: "31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b80512966561:0:=
0"
> ]
> content: <av1.jpeg>
>=20
> id: <YYYY =3D hash of the above>
>=20
> sig: <sig by alice of YYYY>
>=20
> }
>=20
> ie two unique digital assets, with two unique identifiers (XXXX and YYYY)
> that are each indelibly linked with particular satoshis.
>=20
> Obviously there's nothing stopping Alice minting the exact same content
> to two different ordinals -- presumably that's what happened with
> the two inscriptions above -- nor is there anything stopping Bob from
> right-click-save-as and doing the same; but as above, that's obviously
> true for inscriptions as well. The only truly unique thing is the specifi=
c
> hash and the specific content that generated the hash.
>=20
> The relationship does go the other way compared to inscriptions --
> here you keep the association so long as you remember the asset; with
> inscriptions you keep the association so long as you have bitcoin's
> historical blocks. As I've said above, the off-chain approach seems
> much better aligned with incentives to me, with the people who gain the
> benefit from that association paying the cost of preserving it.
>=20
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev