Re: [bitcoin-dev] Purely off-chain coin colouring
> Sign-to-contract looks like: Nice! I think it should be standardized as some informational BIP. This is a similar case as with Silent Payments: it is possible to let users make their own commitments as they please, but if it will be officially standardized, then it will be possible to build more protocols on top of that, in a way which will be understood properly by other nodes. Before, I thought about interpreting signature R-value just as a Taproot-based public key, and forming a commitment as a valid input, that would allow moving coins on such address, but maybe we could standardize it in a simpler way than that. In general, if a commitment would allow pushing any data, it could be always extended when needed, because future commitments could be always nested in the old ones, 32 bytes is enough to do that. Also, I thought about including OP_RETURN at the beginning of each commitment, to make sure it will be never pushed on-chain, but only stored and processed off-chain. Another thing is that r-value is always expressed as some 256-bit number, even in DER encoding, which means we can always assume 02 public key prefix in all commitments, and simply convert it directly into a proper Taproot address.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Purely off-chain coin colouring
On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote: > > 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 more > > > thought, I think pushing things even further off-chain would be plausible. Oh, you could also do inscriptions minimally on-chain. Rather than posting the inscription on-chain per se, take a hash of the data you want to inscribe, and then do a sign-to-contract commitment of that hash. That reduces your on-chain overhead for creating an inscription to approximately zero (you're just signing a transaction), so can be much cheaper, and also can't be blocked or front run by mempool observers. But obviously means the inscription must be announced off-chain for anyone to know about it. Of course, that could be seen as a benefit: you can now have a private inscription, that's still transferable via the regular ordinals protocol. OTOH, there's no way to definitvely say "this tx is the Nth inscription that matches pattern X", as there may be many earlier sign-to-contract inscriptions that match that pattern that simply haven't been publicly revealed yet. So that wouldn't be compatible with "inscription numbers" or "first X inscripts count as minting token Y". If you go one step further and allow the sign-to-contract to be the merkle root of many inscriptions, then you've effectively reinvented timestamping. (You can't outsource inscriptions to a timestamp server, because you'd fail to own the ordinal that indicates "ownership" of the inscription, however you could provide timestamping services as a value-add while creating inscriptions) Sign-to-contract looks like: * generate a secret random nonce r0 * calculate the public version R0 = r0*G * calculate a derived nonce r = r0 + SHA256(R0, data), where "data" is what you want to commit to * generate your signature using public nonce R=r*G as usual To be able to verify sign-to-contract, you reveal R0 and data, and the verification is just checking that R=R0+SHA256(R0, data)*G. That works with both ecdsa and schnorr signatures, so doesn't require any advance preparation. While it's not widely supported, sign-to-contract is a useful feature in general for anti-exfil (eg, preventing a malicious hardware wallet from leaking your secret key when signing txs). Some references: https://www.reddit.com/r/Bitcoin/comments/d3lffo/technical_paytocontract_and_signtocontract/ https://github.com/BlockstreamResearch/secp256k1-zkp/blob/d22774e248c703a191049b78f8d04f37d6fcfa05/include/secp256k1_ecdsa_s2c.h https://github.com/bitcoin-core/secp256k1/pull/1140 https://wally.readthedocs.io/en/release_0.8.9/anti_exfil_protocol/ https://github.com/opentimestamps/python-opentimestamps/pull/14 Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Purely off-chain coin colouring
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. 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 scarcity is your goal, there's two very easy ways to make your own scarcity. 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. > 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 depend on the content or intent of any bitcoin transaction. It is a permissionless network and users can decide how to use money and blockspace. Campaigns to censor such transactions or other efforts to move them off-chain are creating a slippery slope that could affect bitcoin more than some inscriptions. If Casey is harassed enough on social media and ord project moves 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 wrote: > On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev > 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 seems > 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 more > > > thought, I think pushing things even further off-chain would be plausible. > > > 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-chain > > 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 consistently > 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 valuable, > 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. > > 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;
Re: [bitcoin-dev] Purely off-chain coin colouring
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 free 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 à 11:38, Anthony Towns via bitcoin-dev a écrit : > On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev > 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 seems > 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 more >>> thought, I think pushing things even further off-chain would be plausible. > 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-chain >> 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 consistently > 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 valuable, > 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. > > 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 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. > > (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) > >> 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, > 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
Re: [bitcoin-dev] Purely off-chain coin colouring
On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote: > 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. We certainly do want blockspace to be valuable, as transaction fees have to both be in constant demand, and rise enough to replace the inflation subsidy if Bitcoin is to remain secure in the future. In fact at the moment, the inflation subsidy pays miners about 50x more than fees do. Ordinals and other publication mechanisms are of course ways that we can drive consistent demand for block space, keeping Bitcoin secure. Are you arguing that we should change the inflation subsidy phase-out, eg by introducing tail emission(1) or demurrage? 1) https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Purely off-chain coin colouring
On Thu, Feb 02, 2023 at 10:39:21PM -0800, Casey Rodarmor via bitcoin-dev 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 seems 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 more > > thought, I think pushing things even further off-chain would be plausible. 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-chain > 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 consistently 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 valuable, 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. 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 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. (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) > 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, 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 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. > When a user buys an NFT with > off-chain content, they now have the primary economic incentive to preserve > that content, so that their NFT retains value and can be enjoyed or sold. 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 explain >
Re: [bitcoin-dev] Purely off-chain coin colouring
Good evening list, 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. Also, apologies for the HTML mail, but I don't have my email client configured correctly. And finally, also apologies if this breaks the thread, I was subscribed but not receiving mail, so I can't respond to the original message. 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 more thought, I think pushing things even further off-chain would be plausible. Actually, my initial sketch for Ordinal NFTs worked in a similar fashion, with off-chain messages pointing to an ordinal, which could be tracked by following the chain of custody of that particular sat. I gave a workshop last year where I handed out paper wallets to participants with a private key that controlled some sats, which could both be assigned NFTs and used to sign messages as a form of provenance: https://www.youtube.com/watch?v=j5V33kV3iqo Ultimately, I decided against this design, and Peter provided an excellent explanation of some of the trade-offs of such a design in his mail, but to at least partially recap and explain my own thinking: 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, even if details of the NFT protocol involved actually prevents that content from being what you see when you view the NFT on a website or marketplace. User protection when off-chain content is involved is fraught. Users are not equipped, due to lack of technical knowledge, easily available, user-friendly tools, and education, to protect themselves when they buy a collectable whose content is stored off-chain. When a user buys an NFT with off-chain content, they now have the primary economic incentive to preserve that content, so that their NFT retains value and can be enjoyed or sold. Many existing NFT marketplaces that sell off-chain content do not explain this to users, or give users tools that the average, non-technical person can understand or use, which enables them to protect themselves. Even if they did give users these tools, there are tricky considerations involved. IPFS functions much like BitTorrent, so even if users were provided with an IPFS application that could persist their off-chain NFT content automatically, they might reveal their IP address, which would then be linked to ownership of their NFT, which would have privacy and safety considerations. Another issue is salience and scarcity, as has been mentioned. Off-chain 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. The above issues also make the specification and implementation of NFTs with off-chain content much more difficult. Ordinals is a project largely written by a single developer, me, with the assistance of two part time interns. It is very intentionally the simplest thing that could possibly work, much like Bitcoin itself. Sometimes I refer to it as "cave-man technology". If I was designing an off-chain NFT protocol, I would likely have had to raise money and recruit a large team, which I have not done, or be at risk of never launching anything at all. I would absolutely love for the ordinals protocol, that is, the numbering and transfer of individual satoshis, be used as the basis for alternative, off-chain NFT and colored coin schemes, with proper consideration given to the issues above. However, I would request that, to avoid confusion, these alternative schemes never be called inscriptions. I'm a dev, not a cop, but fine distinctions are hard to properly explain and understand. Inscriptions, that is, the NFT protocol which embeds content in transaction witnesses, has a particular set of trade-offs and guarantees. I want users to know that if they buy or value something they or others call an "inscription", they can rely on those trade-offs and guarantees. Another NFT protocol named "inscriptions" would make this very difficult. 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. Sorry to belabor this point! Inscriptions have already proven very popular for a nascent protocol, beyond my expectations, and the terminology and naming is still new, so it's a critical phase in terms of understanding and education. If others are interested in developing ordinals further, a great first step would be to provide review and feedback on the BIP PR: https://github.com/bitcoin/bips/pull/1408 I have never written a BIP, so style and content feedback is especially welcome. Inscriptions themselves have
Re: [bitcoin-dev] Purely off-chain coin colouring
I am not an expert with RGB, but it looks limited (only bitcoin chains
from the github repo, apparently on hold), distributed over the
"lightning network" or LN nodes (what is it?), or Bifrost extension,
with a dubious token floating around, like ethereum mess as RGB docs
describe Ethereum (and myself also), layer2 or layer3, certainly not
decentralized (like still Bitcoin and Ethereum)
It's of course useless to trust IPFS or Bittorrent to store things
because you cannot control the seeders who have zero incentive to seed
such things
That's why in my much more simple proposals a well known third party is
there, wayback machine, github, twitter, etc, if they disappear then
probably internet has disappeared too, if they get censored you can
still get a snapshot of what you did
The intent is certainly not to store NFTs in Bitcoin, only hashes,
signatures and addresses, same for the third party proof, the NFT
content if not real is stored elsewhere (up to people to decide where)
Additionally you can store in the third party the proof that something
exists (the secret NFT), for example a small copy of the NFT electronic
art, the buyer will get the full version once the deal is done and once
he gets the decryption key, having the NFT for himself only
My proposals are not addressing wider D-stuff topics, supposedly
decentralized, but no
So I don't think that it's a waste of time to change the OP_RETURN max
size, currently it cannot even store +
, probably it's logical to align it to the script size limit
(520B)
Or as I said previously deviant practices can happen, not expensive and
just burning satoshis, which is not a super idea
I don't get why on bitcoin all proposals must always be super
complicate, mine are simple, then take 5mn to read them
Le 02/02/2023 à 15:30, Peter Todd via bitcoin-dev a écrit :
> On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
>> Hi *,
>>
>> Casey Rodarmor's ordinals use the technique of tracking the identity of
>> individual satoshis throughout their lifetime:
>
>
>> 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.
> On the FAQ of the Ordinals website they discuss off-chain data storage and
> reject the idea:
>
> "Some Ethereum NFT content is on-chain, but much is off-chain, and is
> stored on
> platforms like IPFS or Arweave, or on traditional, fully centralized web
> servers. Content on IPFS is not guaranteed to continue to be available,
> and
> some NFT content stored on IPFS has already been lost. Platforms like
> Arweave
> rely on weak economic assumptions, and will likely fail catastrophically
> when
> these economic assumptions are no longer met. Centralized web servers may
> disappear at any time."
>
> https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
>
> That same FAQ also mention RGB and Taro, which already implements an off-chain
> data model based on my Proofmarshal work. The Ordinals community is well aware
> of the trade-offs and have chosen to publish their data on chain. This is a
> collectables market based on artificial scarcity after all, so some
> conspicuous
> consumption isn't going to be a deterrent.
>
> Frankly, I think further discussion of this on the bitcoin-dev mailing list,
> with the aim of getting Ordinals and others to do something else, is a waste
> of
> everyones' time. The fact that publishing data on chain lets you take
> advantage of the very large network of archival Bitcoin nodes to publish and
> store your data indefinitely is a clear benefit that people will always be
> willing to pay for. The only realistic thing Bitcoin can do to discourage this
> is tweaks to the blocksize and segwit discount, which of course has well-known
> downsides.
>
> There's a clear social/economic benefit to the Ordinals community that the
> complete set of Ordinalds - and their inscriptions - is easy to extract and
> will be available as long as Bitcoin block data itself will be available.
> That's not going away and we should acknowledge that benefit honestly.
>
>> 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":
>> "kind": 0,
>> "tags": [
>> ["ord", "txid:vout:sat"]
>> ],
>> "content": [jpeg goes here],
>> "id":
>> "sig":
>> }
> nostr doesn't even have a clear data persistence model. As you know, nostr
> messages are passed around by relays that make no enforceable promise of
> actually keeping those messages or making them available. nostr doesn't have
> any kind of blockchain, making it diffcult for others to
Re: [bitcoin-dev] Purely off-chain coin colouring
On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
> 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.
On the FAQ of the Ordinals website they discuss off-chain data storage and
reject the idea:
"Some Ethereum NFT content is on-chain, but much is off-chain, and is
stored on
platforms like IPFS or Arweave, or on traditional, fully centralized web
servers. Content on IPFS is not guaranteed to continue to be available, and
some NFT content stored on IPFS has already been lost. Platforms like
Arweave
rely on weak economic assumptions, and will likely fail catastrophically
when
these economic assumptions are no longer met. Centralized web servers may
disappear at any time."
https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
That same FAQ also mention RGB and Taro, which already implements an off-chain
data model based on my Proofmarshal work. The Ordinals community is well aware
of the trade-offs and have chosen to publish their data on chain. This is a
collectables market based on artificial scarcity after all, so some conspicuous
consumption isn't going to be a deterrent.
Frankly, I think further discussion of this on the bitcoin-dev mailing list,
with the aim of getting Ordinals and others to do something else, is a waste of
everyones' time. The fact that publishing data on chain lets you take
advantage of the very large network of archival Bitcoin nodes to publish and
store your data indefinitely is a clear benefit that people will always be
willing to pay for. The only realistic thing Bitcoin can do to discourage this
is tweaks to the blocksize and segwit discount, which of course has well-known
downsides.
There's a clear social/economic benefit to the Ordinals community that the
complete set of Ordinalds - and their inscriptions - is easy to extract and
will be available as long as Bitcoin block data itself will be available.
That's not going away and we should acknowledge that benefit honestly.
> 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":
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id":
> "sig":
> }
nostr doesn't even have a clear data persistence model. As you know, nostr
messages are passed around by relays that make no enforceable promise of
actually keeping those messages or making them available. nostr doesn't have
any kind of blockchain, making it diffcult for others to archive messages
completely. Advocating for its use in a protocol designed to support valuable
collectables expected to be owned for a significant amount of time is reckless.
You know, we've been through all this before, years ago when colored coins were
first being discussed. Bitcoin Core devs who knew better would try to
discourage use of the Bitcoin chain for purposes they didn't approve of, by
suggesting solutions that they knew full well didn't really work. Solutions
like using OpenTimestamps inappropriately, alternative publication methods that
failed to provide the same level of security as Bitcoin, etc. It was dishonest
then, and it's disappointing to see a new generation of Bitcoin devs continue
this pattern of dishonesty.
> 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.
The RGB protocol already does off-chain custody proofs, and implements NFTs.
You can already use this for real with Iris Wallet - the ownership chain of a
RGB asset is _not_ visible on the blockchain, as ownership does not follow
satoshis. With more work, digital assets can even be transferred with
O(log_2(n)) scaling allowing billions of transfers per second:
https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
This of course is irrelevant to Ordinals, which will never have such a large
market.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
___
Re: [bitcoin-dev] Purely off-chain coin colouring
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 your
sats so this approach goes against the concept and what makes them interesting
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
rendering 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 care
about as bitcoin will have no value without censorship resistance.
Lastly, I would add that inscriptions involve "financial" transactions,
associating sats with image is freedom and got historical reasons for it.
Writing something on paper or drawing an image on copper is not same as doing
it on gold.
Disclaimer: My opinion on inscriptions can be biased because I am working on 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
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":
>
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id":
>
> "sig":
>
> }
>
> 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
Re: [bitcoin-dev] Purely off-chain coin colouring
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":
> "kind": 0,
> "tags": [
>["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id":
> "sig":
>}
>
> 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
Re: [bitcoin-dev] Purely off-chain coin colouring
In your system what is the off-chain mechanism? And what prevent a thief
to steal your NFT?
I have submitted several time "A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
It's more simple, the NFT (whether real or electronic) is referenced by
a initial hash (which is not the hash for example of your jpeg file
because easy to fake) and then get a final reference which is the hash
of the initial hash
The idea is that the real owner must prove that he has the knowledge of
the initial hash (for example luxury bag, you print the double hash on
it, and give the initial hash to the buyer, if the owner/seller can't
prove that he knows the inital hash, the bag is stolen or counterfeit
(with the double hash))
The NFT owner references the NFT signed by him in some trusted third
party allowing a timestanp (wayback machine for example), it proves that
he is the first one to have the knowledge of the double hash, so a thief
cannot intercept the "minting" transaction (if any because not really
necessary since the public key of the owner is known from the third
party) and steal the NFT for himself or do/replay a transaction with
this NFT, minting it or selling it several time
A third party is involved but it remains decentralized
Then the NFT owner and buyer exchange some information like for
lightning and do one transaction on Bitcoin storing the deal, see the
details in the proposals depending on what kind of deal occur between
the buyer and the seller, like lightning, if someone cheats, then he
loses his bitcoin
It's minimal, understandable, secured, decentralized and not expensive,
that's why I don't see very well why to complicate with ordinals
The proposal envisions the concept of "secret" NFTs also
The continuation of this proposal is "A Universal Coin Swap system based
on Bitcoin" https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
It's simple also, you go from Decentraland to the Sandbox but don't have
SAND and want to pay with MANA, you agree on a MANA/SAND deal with the
seller which is stored in Bitcoin signed by both, then you pay with
MANA, other use cases are described in the proposal
Note: both proposals need to be modified since I thought OP_RETURN max
size was 512B and it is in fact 80B, which does not work for all cases
Le 02/02/2023 à 10:15, Anthony Towns via bitcoin-dev a écrit :
> 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":
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
>
