path: root/6c/57e168192a50f27d7f4b9bdf09d2f26854ca3a

Return-Path: <aymeric@peersm.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AB9B9C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 11:37:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 874C440231
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 11:37:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 874C440231
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 1mS_-nYZItQb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 11:37:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9DDCA40225
Received: from 8.mo548.mail-out.ovh.net (8.mo548.mail-out.ovh.net
 [46.105.45.231])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 9DDCA40225
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Feb 2023 11:36:59 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.108.16.148])
 by mo548.mail-out.ovh.net (Postfix) with ESMTPS id 1DBD120734;
 Sat,  4 Feb 2023 11:36:56 +0000 (UTC)
Received: from peersm.com (37.59.142.109) 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; Sat, 4 Feb
 2023 12:36:55 +0100
Authentication-Results: garm.ovh; auth=pass
 (GARM-109S003a51b32de-e3ae-4ac6-8014-0cd58d06bcc6,
 83B9442A37C74570B8CB15ECCD3A86C2760700E6) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.100.10
To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>, Casey Rodarmor <casey@rodarmor.com>
References: <CANLPe+Pa-D=JB8N5Qeokoyp=mRA3LLM=mtvvwPkpbHvV_bmEXQ@mail.gmail.com>
 <Y941vsOOsZJHdnKT@erisian.com.au>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <1ebd4888-dc24-f423-b97b-fadba922bf00@peersm.com>
Date: Sat, 4 Feb 2023 12:36:54 +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: <Y941vsOOsZJHdnKT@erisian.com.au>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [37.59.142.109]
X-ClientProxiedBy: DAG2EX1.mxp6.local (172.16.2.11) To DAG6EX2.mxp6.local
 (172.16.2.52)
X-Ovh-Tracer-GUID: cd95d549-aebb-4b91-a908-2f840add1dce
X-Ovh-Tracer-Id: 4852628602624631773
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudegvddgfedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfhisehtqhertddtfeehnecuhfhrohhmpeethihmvghrihgtucggihhtthgvuceorgihmhgvrhhitgesphgvvghrshhmrdgtohhmqeenucggtffrrghtthgvrhhnpeeihedtfeegledtteegffeukeelueejudetffdtueekudejjeelkeffieeghfehhfenucffohhmrghinhepohhrughinhgrlhhsrdhnvghtpdhgihhthhhusgdrtghomhdplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphgvvghrshhmrdgtohhmpdhlihhnkhgvughinhdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtoheptggrshgvhiesrhhouggrrhhmohhrrdgtohhmpdgsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdgrjhesvghrihhsihgrnhdrtghomhdrrghupdfovfetjfhoshhtpehmohehgeekpdhmohguvgepshhmth
 hpohhuth
X-Mailman-Approved-At: Sat, 04 Feb 2023 15:46:20 +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: Sat, 04 Feb 2023 11:37:02 -0000

I still don't see in both proposals how you avoid that someone steals
your NFT, double mint it or sell it several time, because the thief can
do the very same that what your are describing, a hash of the content is
not enough, you can slightly modify an image or a document and it gives
another hash, as far as I know in all existing systems today there are
zero protection against this, I am quoting also Moxie's experience in my
proposals

That's why I am proposing the third party with a timestamp and a double
hash not related to the content itself, and the secret NFT, I don't see
the point to buy millions some electronic art that everyone can get for f=
ree

Anyway, I mostly consider that a NFT is a real good that you buy in the
metaverse, not only an electronic thing


Le 04/02/2023 =E0 11:38, Anthony Towns via bitcoin-dev a =E9crit :
> On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-de=
v wrote:
>> 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.
> Anything that potentially uses up a large percentage of blockspace seem=
s
> pretty relevant to general Bitcoin development to me...
>
>> AJ Towns writes:
>>> 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.
> I guess I should have explained why I think moving things off-chain is
> a worthwhile goal. Riffing off:
>
>> Another issue is salience and scarcity, as has been mentioned. Off-cha=
in
>> content is unbounded, and thus less scarce. Usually, we design for
>> efficiency, volume, and scale. For NFT designs, which are intended to =
be
>> collectable, this is in some ways counterproductive.
> "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 consistentl=
y
> underpriced and unavailable even for people who'd pay more, but that
> hopefully doesn't apply).
>
> 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 valuabl=
e,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.
>
> 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=
=2E
>
> 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.
>
> If you keep jpegs on-chain, as far as I can see, there's three outcomes=
:
>
>  * 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
>
>  * blockspace becomes filled with jpegs, driving up costs for everyone,=

>    making jpeg collectors happy, but transactors sad
>
>  * 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.
>
> I'd guess the first of these is the most likely, personally.
>
> As far as salience/notability goes, personally, I'd see ownership of
> inscriptions as a negative indicator; "hey, when I was young and foolis=
h I
> wasted x-thousand bytes on the bitcoin blockchain, pointlessly creating=
 a
> permanent cost for everyone trying to use bitcoin in future". That's no=
t
> unforgivable; people do all sorts of foolish things, and bitcoin's mean=
t
> 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 bitc=
oin
> to be a monetary network that's usable in practice by many/most people.=

>
> (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 fe=
es
> to help secure bitcoin", such a claim is more charitable/admirable/valu=
e
> 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)
>
>> 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
> 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.
>
> 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.
>
>> User protection when off-chain content is involved is fraught.
> I mean, that seems trivially solvable? Users already have to store the
> private key that controls ownership of these digital assets; storing th=
e
> asset as well, which doesn't need to be private, isn't a big ask. And i=
f
> a public site like ordinals.net is willing to store all the inscription=
s
> that might be on the blockchain, they could just as easily store the
> same amount of off-chain digital assets.
>
>> When a user buys an NFT with
>> off-chain content, they now have the primary economic incentive to pre=
serve
>> that content, so that their NFT retains value and can be enjoyed or so=
ld.
> Yes -- the people who potentially benefit from the NFT should be the
> ones paying the costs of preserving that NFT.
>
>> Many existing NFT marketplaces that sell off-chain content do not expl=
ain
>> this to users, or give users tools that the average, non-technical per=
son
>> can understand or use, which enables them to protect themselves. Even =
if
>> they did give users these tools, there are tricky considerations invol=
ved.
>> IPFS functions much like BitTorrent,
> Externalising the costs to some different network while privatising the=

> benefits isn't any better than doing it to bitcoin; except in that mayb=
e
> you're inconveniencing fewer people.
>
> Going back to this:
>
>> Another issue is salience and scarcity, as has been mentioned. Off-cha=
in
>> content is unbounded, and thus less scarce. Usually, we design for
>> efficiency, volume, and scale. For NFT designs, which are intended to =
be
>> collectable, this is in some ways counterproductive.
> Obviously blockchains aren't the only "scarce" good out there. If scarc=
ity
> 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.
>
> [0] https://github.com/nostr-protocol/nips/blob/master/13.md
> [1] https://github.com/nostr-protocol/nips/blob/master/03.md
>
> 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.
>
>> The above issues also make the specification and implementation of NFT=
s
>> with off-chain content much more difficult.
> 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.
>
> 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:
>
>  - setup a nostr relay, with submissions gated by proof of work, and
>    no expiry. maybe https://github.com/Cameri/nostream ?
>
>  - 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 n=
ow
>    for inscriptions. either have your own nostr client that subscribes
>    to your relay, or just query your relay's db directly.
>
>  - have a regular proof of work adjustment targeting say 200MB worth of=

>    events per day (vs the 576MB per day of possible witness data).
>
>  - update the ord tool to be able to encode digital artifacts into a no=
str
>    event, apply proof of work to it, and send it to (by default)
>    your relay.
>
> 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 follo=
w
> a particular artist by pubkey, too. An artist could publish a collectio=
n
> by publishing an event defining the collection, then linking each artwo=
rk
> 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.
>
> 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 transactio=
ns
> that link the digital artifact with the ordinal with an off-chain messa=
ge
> achieving the same thing.
>
> Then to go beyond what you've got you could:
>
>  - 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 digia=
l
>    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.
>
>  - add some support for the "social legitimacy" aspect -- eg linking
>    all the assets created by the same public key as an artist's portfol=
io;
>    make it easy to go from their nft-related pubkey to their regular
>    nostr profile or similar.
>
>  - let creators that have already somehow demonstrated "social legitima=
cy"
>    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
>
> 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...
>
>> Additionally, I think the term "inscription" which has a connotation o=
f
>> permanence, and of an indelible association with a particular satoshi,=
 is
>> inappropriate for an off-chain NFT protocol.
> No objections about the "inscription" definition, but I'm not sure if t=
he
> 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 associati=
on
> with a particular satoshi, despite it being an off-chain NFT protocol.
>
> For example if you take two identical digital assets, such as:
>
>   https://ordinals.net/inscription/8ed2594cecbd43e5673168ff160ba00a6d89=
53fea7ab6b15a112f3bc94adc2f8i0
>
>   https://ordinals.net/inscription/31e9577f9af1d1823bc00539291f061e4ac9=
ba727162a8e0d8d7b80512966561i0
>
> then in the off-chain world, they would look like two events:
>
>   {
>     pubkey: <Alice>
>     kind: 0
>     tags: [
>       ord: "8ed2594cecbd43e5673168ff160ba00a6d8953fea7ab6b15a112f3bc94a=
dc2f8:0:0"
>     ]
>     content: <av1.jpeg>
>     id: <XXXX - hash of the above>
>     sig: <sig by alice of XXXX>
>   }
>
> and
>
>   {
>     pubkey: <Alice>
>     kind: 0
>     tags: [
>       ord: "31e9577f9af1d1823bc00539291f061e4ac9ba727162a8e0d8d7b805129=
66561:0:0"
>     ]
>     content: <av1.jpeg>
>     id: <YYYY =3D hash of the above>
>     sig: <sig by alice of YYYY>
>   }
>
> ie two unique digital assets, with two unique identifiers (XXXX and YYY=
Y)
> that are each indelibly linked with particular satoshis.
>
> 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 speci=
fic
> hash and the specific content that generated the hash.
>
> 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.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--=20
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/Ay=
ms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b=
eed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac=
tions
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.p=
eersm.com
Peersm : http://www.peersm.com