Add option to inscribe BitTorrent (V1) infohashes #1805
Conversation
This only makes the on-chain inscriptions more valuable and I am not sure if 'inscription' would be the right term for link to off-chain things.
Vulnerable because of SHA1: https://www.bittorrent.org/beps/bep_0052.html
Unnecessary complexity and dependencies.
This makes no sense because:
|
As mentioned in the PR description, one of the reasons I included the SHA-256 alongside the infohash was to avoid relying solely on SHA-128. Once the user finishes downloading the file from BitTorrent using the committed infohash, they can verify that it also matches the committed SHA-256.
Well I guess it depends on what your goals are :) I would say that the tracker/dht are pretty straightforward to setup and require relatively little resources. The web seed, however, is more complicated and resource-intensive (storage mainly, although its not really that different than full nodes storing files inscribed on the blockchain). But it seems to me that enough people care about ordinals inscriptions so that someone out there would like to auto-seed inscribed infohashes and provide a public mirror/archive. It doesn't have to be official.
Using Nostr is just an option, which can be used alongside BitTorrent as a backup. Sort of like a web seed.
For some use cases, the contents could be small enough to fit within the limits.
Well, even if your assumptions are true, users might still want to inscribe something that was already published (and paid for) on a Nostr relay for a different purpose. For example some people were NFTing tweets awhile back. |
shesek
force-pushed
the
202302-btih
branch
2 times, most recently
from
ade2499
to
50a47d4
Compare
Actually, thinking about this some more, assuming the user knows the filename and piece size used to create the torrent (in this PR the piece size is static), they can deterministically reproduce the This is however quite cumbersome, having the SHA-256 directly does make it much easier. And SHA-256 is still preferable over the SHA-128 infohash for security reasons. |
|
NACK The incentive model for people to seed BitTorrent content is that the data itself is valuable. This is not clearly the case with Ordinals, which represent ownership of something. Thus relying on BitTorrent is likely to result in data loss. |
Well to be fair there isn't really an incentive model for seeding on BitTorrent. You have an incentive to obtain the data for yourself, but not to make it available for others. (private trackers and peer download/upload statistics do provide some incentive -- but these no longer have significant usage nowadays.) It can be argued that the incentive here is stronger:
If the original creator, current owner, the platforms and the community all lose interest in keeping a copy of some file, would it really be such a great loss?
Even if your arguments are all correct, what's the harm in making this available as an option and have users choose? |
You're using the word "incentive" in a very narrow way here, only referring to selfish economic incentives. People have other incentives too, such as doing good for their community. In that sense of the term, there is a clear incentive to running BitTorrent seeds, as a wide community of people benefit from them. That incentive is missing for ordinal data.
The high chance it breaks of course. It does not make sense for Ordinals to ship features that are likely to break and harm the user experience. Additionally, every feature we add imposes a UI/UX cost, which further harms adoption. A good question really is what is your incentive for proposing this feature? Are you actually part of the ordinals community? Or are you proposing it because you want that community to do something that benefits some other community? |
This doesn't seem true to me. I can imagine applications built on top, which could have features like automatically seeding content that users have liked, content owned by other users that a user follows, and so on. It doesn't need to be something a user is explicitly making a decision on, which is, of course, how most software generally works.
This can be explained to the user and backups can be made. These arguments would preclude Bitcoin itself if applied to things like seed phrases. Users somehow manage to deal with it in those cases.
How would being able to make cheaper, larger NFTs that have a different, easily explainable, persistence tradeoff be something that isn't a valid topic? 🤨 It's even been discussed in prior issues: https://github.com/casey/ord/issues/801, https://github.com/casey/ord/issues/887, https://github.com/casey/ord/issues/624 |
A clear advantage of on-chain inscriptions is that a one-time backup of a seed phrase is sufficient to recover all your assets in the future, with an appropriately designed wallet. That is a huge advantage over any scheme that requires on-going backups to avoid losing assets. We already have systems like RGB's NFT's that have made the trade-off of requiring on-going backups in exchange for scalability. Similarly, Lightning's problems with backups are a notorious problem that is widely recognized as such.
It's a valid topic in general. But BitTorrent (and nostr) are clearly not very robust ways to do so. Actually writing up a quick patch to do that looks more like an attempt to shame Ordinals into getting rid of on-chain inscriptions rather than a bonafide new feature. |
I see zero evidence in this thread of any shaming of on-chain inscriptions. In fact, supporting BitTorrent fundamentally requires on-chain inscriptions to work. It could be viewed as a "quick patch", because it's a simple feature to add, but that doesn't make it a bad feature. |
Why doesn't the Ordinal community have that same incentive too? And 'selfish economic incentives' aren't a bad thing, if there are platforms that benefit from Ordinal NFTs and seed them then everyone benefits from it.
Is this a good question really? Making this about me and my motives rather than about the merits of the proposal/implementation seems unnecessarily hostile and unproductive. I expected better from you. But to answer your question anyway: I'm not hiding the fact that I personally find NFTs to be unexciting and prefer block space to be conserved for payment activities. But I'm not trying to stop anyone from using bitcoin in whatever way they want, and in fact I haven't even voiced an opinion or wrote anything on Twitter about Oridnal inscriptions at all prior to tweeting about this PR. I sent this contribution in good faith because I believe it can benefit both the Ordinal and Bitcoin communities -- or at least some parts of them, or of people that that may join the Ordinal community in the future because they feel more comfortable with block-space efficiency. It's an opt-in feature that no one is forced to use. I really don't get why you're reacting to it with such hostility. |
The tradeoffs with RGB/Taro are quite different. They require off-chain storage and client-side validation for the token transfers themselves, not just for the inscription data. Also, the backup data needed by the user to restore funds is dynamic and has to be backed-up after every transfer, unlike the torrent data which is static and can be backed up more easily by anyone just once. |
|
Rebased on top of master. Thinking about this some more, it may be better to include the hashes under a new tag type rather than as the content type. The content type tag can then be used for the 'real' mime type of the file, which may be useful to have accessible without having to download the torrent (for example it makes it easier for the explorer to know how to embed external resources for display, using It can be a single tag with current format this PR is using (32 bytes SHA-256 + 20 bytes SHA-128 infohash, perhaps with the infohash made optional?), or as two tags for each hash type. Another option is multihash. However, its standard only appears to cover cryptographic hash function types and not application-specific hashes (so it has no representation for BitTorrent infohashes and is probably unlikely to accept a PR for it), and it might be better to KISS and not over complicate this. It's also interesting to note that the multihash Happy to implement this change if that approach seems preferable. |
|
seems like the whole point of ordinals is to avoid linkrot, and this introduces the possibility of this. if a file stops being 'torrented', then the link points to nothing. seems to ruin the simplicity and availability assurance that ordinals currently provides |
Different people can value different things about Ordinals. One could be excited about the ordinal numbers theory and digital token ownership on Bitcoin, but not feel too emotionally attached to the idea of on-chain storage for attached files. We can see that the vast majority of Ethereum NFTs aren't stored on-chain and people still seem to value them, so this is not some wild idea. Even if on-chain storage is generally preferred, there are still some cases where you still wouldn't use it. For example:
It's an opt-in feature for these that prefer the tradeoffs if offers, how does it ruin anything? |
Token transfers mean that tokens are moving from one party to another. So yes, in the inscriptions model if inscription data is not on chain every token transfer also requires a backup of that data by the new owner. That is fundamentally no different than RGB/Taro. With RGB/Taro the community can also elect to backup transaction data. Though unlike ordinals, the owners are not forced to make that data public. There's no reason for Ordinal's to implement a bad copy of RGB/Taro's approach. They should do their own thing. |
RGB/Taro requires backup of a new piece of data after each transfer, and if that fails to happen for any reason then the user can no longer prove ownership and cannot transfer the asset. In the inscription case the file can be archived just once initially after the inscription, for example to a slow cheap large disk that you can bury in a time capsule somewhere and revive years later, no matter how many times the token changed hands in the meanwhile. I think this is fundamentally quite different. |
|
On February 24, 2023 3:02:52 PM GMT+01:00, Nadav Ivgi ***@***.***> wrote:
> So yes, in the inscriptions model if inscription data is not on chain every token transfer also requires a backup of that data by the new owner.
It requires backup *of a new piece of data* after each transfer, and if that fails to happen for any reason then the user can no longer prove ownership and cannot transfer the asset.
In the inscription case it can be archived just once initially after the inscription, for example to a slow cheap large disk that you can bury in a time capsule somewhere and revive years later, no matter how many times the token changed hands in the meanwhile.
Again you are missing my point... The new owner has to make a backup of their new asset. Pretty much exactly the same model as RGB.
|
|
On February 24, 2023 11:14:52 AM GMT+01:00, Nadav Ivgi ***@***.***> wrote:
> seems like the whole point of ordinals
Different people can value different things about Ordinals. One could be excited about the ordinal numbers theory and digital token ownership on Bitcoin, but not feel too emotionally attached to the idea of on-chain storage for attached files. We can see that the vast majority of Ethereum NFTs aren't stored on-chain and people still seem to value them, so this is not some wild idea.
Even if on-chain storage is generally preferred, there are still some cases where you still wouldn't use it:
- It might be a big multi-gigabyte file that cannot realistically be stored on-chain.
- The inscribed file may be meant to be shared privately and not made available to the whole world.
- It may become too expensive to inscribe on-chain, at least for some use-cases and some people.
If it becomes too expensive to inscribe on chain old inscriptions might become even more valuable than they otherwise would. Merging this pull-req requires hard thought about those economics.
> ruin the simplicity and availability assurance
It's an opt-in feature for these that prefer the tradeoffs if offers, how does it ruin anything?
Ordinals are basically an art project. Art is usually less than 100% rational and efficient.
|
|
NACK-ish You can already inscribe a BitTorrent infohash if you want, and there will be people that understand that doing so isn't really the same as putting the content iteself on-chain as it's less durable, adds indirection, and the meaning of 'owning' it is weakened (you own a pointer to the content, not the content itself) -- but also I don't think it should be encouraged (to me adding native support to Appealing to authority, if widely adopted this would push Ordinal Inscriptions closer towards the janky shitcoin-style NFTs where almost all of them are just pointers to out-of-band content and not the actual asset, which is something Casey has explicitly given as motivation for making ord as a better way. (edit: this is how I interpreted Casey on Odell's and NVK's podcasts, giving resons for why Eth NFTs suck. @tyjvazum validly points out Casey may not mind Ordinals being pointers by referencing #801, #887, #624) Also at the moment, if two people inscribe exactly the same file, then there are two copies of it that can be separately owned. The one that came first (or the one inscribed on a rarer sat) would be the more valuable, and it's easy to see "who owns what". If two people inscribe the same infohash, and we treat torrents as 'legit' out-of-band/off-chain storage, now you've got two pointers to the exact same thing, and they're both making a claim on that same thing -- this adds some new murkiness about "who owns what" |
Correct, if it isn't added here, then it's easy for alternative clients to add support for it.
Actually, Casey has explicitly suggested, as recently as this year, adding support for off-chain content in multiple issues: https://github.com/casey/ord/issues/801, https://github.com/casey/ord/issues/887, https://github.com/casey/ord/issues/624 Regarding "janky shitcoin-style NFTs", I think the main issue is they don't even serve as pointers to their content, since it's uncommon for any hash-addressed content to be used. That difference allows the content to be changed, without any solid record of what it was originally supposed to be. There are no potential problems like that with BitTorrent-based content.
It's not necessarily true the first, or "rarer sat", would be more valuable in all cases, and in both situations, on-chain and off-chain, the ordering would be the same so there would be no difference from the perspective of ownership. As far as on-chain content goes, it's very inefficient to replicate content, so when identical, the content of the second inscription should ideally be a pointer to the content of the first inscription anyway. These are all, of course, simply implementation details, leaving users to think about the concepts however they choose to. |
|
Concept ACK. I don't understand the weird gatekeeping. |
Gatekeeping is done by owners or maintainers of repository. Example: Luke Dashjr in bips repo. All comments in this PR are by reviewers who can have opinions same as you. |
To be clear, I'm not at all opposed to I'm NACK on treating inscribed torrents as a special case, as-if the inscription is of the content pointed to by the torrent, and not the actual torrent file itself — but not against inscribed torrent files or other pointers to out-of-band storage being inscribed (e.g. IPFS, plain old URLs, pointers to things on other blockchains, etc) A practical reason to not treat torrents as special is simply that you don't know what the inscriber intended – are they making their torrent file really permanent so you can download a 50GB 4K pirate of some film if you want it; or are they doing it because they don't want to pay to inscribe their jpeg monkey actually on-chain but would like us to treat the inscription like a jpeg monkey and not a text file/infohash? |
How?
It could be argued that with on-chain inscriptions you also own a pointer - the ordinal sat associated with the inscription - and not the data itself, which is readily and freely available to everyone. But I guess that's more of a philosophical question really.
Why would it be bad for explorers to make a copy of torrents available for users, similarly to how they make a copy of on-chain inscribed files? I think it would actually be pretty neat (and also not too technically complicated, I can perhaps even help implement this). But IMO it could also be sufficient if the explorer simply rendered a magnet link (as implemented in this PR). Users can then use instant.io to download/preview it right in their browser.
Well, if it does get widely adopted by the Ordinal community, wouldn't it be evidence that this feature has merit and is wanted by users?
Couldn't you simply also treat the first/rarest-satoshi-associated torrent inscription as the 'legit' one, exactly like how you described you would solve it with on-chain inscriptions?
Using an alternative client to make the torrent inscription could be alright and not too cumbersome, but it would be great if the block explorer at least rendered it by showing the hash in hex and with a magnet link. Users having to go to (and trust) a separate ordinal block explorer just for that doesn't seem very practical. |
You can write anything and inscribe a text file |
|
A thriving block space market, being necessary to the security of a decentralized Bitcoin, the right of the people to inscribe data on-chain, shall not be infringed. |
Yes, it'd be great if the block explorer supported it, so hopefully that happens. However, I don't think separate block explorers should be avoided, and I don't think any should be treated as canonical. Imagine if that had happened with Bitcoin, and how much of a centralizing force it could have become. Ideally, users wouldn't even use a mere centralized website to begin with, but in practice that will likely require substantial work on some type of light client mode, or at the very least a better version of a local explorer. |
Fair point, current release doesn't, but PR #1482 adds arbitrary MIME type support, or as @1440000bytes says you can inscribe it as a text file though that's not ideal |
Because pholosophically I don't see an inscribed torrent as being the same thing as an actually inscribed file. It lets you 'get away with' cheaping out and inscribing a small pointer rather than 'comitting' and paying to put your content on-chain. If it's treated as a special case on-par with actually inscribed content we end up closer at the current state of NFTs on altcoins where most people won't understand the distinction, caveats and detail, and then be upset and confused when one day their 'inscription' goes away because no-one seeds the torrent anymore. |
|
I hope this gets merged 🙏 |
|
This is a massive change, and not something I want to think about at this time. GLHF! |
|
Also, thank you for the effort and time that you put into this PR! I appreciate the thought and care that went into it. However, this change is not something that is suitable for a PR. A large change like this should be discussed before code is written, otherwise contributors will waste time writing code that does not have a change to be merged. I eventually hope to consider some form of BitTorrent support, but:
Eventually, when other, higher priority issues have been fixed, I hope that this receives the attention that it deserves, but there are too many high priority bugs, issues, and features that need to be addressed, and a large change like this requires much more bandwidth than I think we have at the moment. |
This adds a new
--torrentCLI flag (plus some related--torrent-xxxoptions) toord wallet inscribe, which automatically creates a torrent for the given file (by default, in the same directory with a.torrentextension) and inscribes its SHA-128 infohash alongside the file's (regular) SHA-256 using thesha2,btihcontent type.The explorer was also adapted to render torrent inscriptions with the infohash/sha256 hex and a magnet link.
With this, files can be stored off-chain on the BitTorrent P2P network while the Bitcoin blockchain is used to commit to the file and to provide its
infohash, which acts as a locator for obtaining the file from BitTorrent (using DHT or trackers).Why not IPFS?
I haven't really found a compelling reason to prefer IPFS. It can work better for files that are duplicated across multiple torrents but it should rarely be the case here. Also bittorrent has a more mature ecosystem, better tooling, and more people already have a client installed.
Why not BitTorrent V2?
I couldn't find a Rust library that supports it. Also it appears that many bittorrent clients don't support V2 yet, including webtorrent (which is pretty neat and worth supporting imo).
Why inscribe the SHA-256 too?
Mainly to have an easy way for users to verify the file if they get it through some other non-torrent means (and therefore don't have the torrent metadata, which is necessary to confirm the infohash matches the file -- edit: not quite true) and to avoid relying solely on the SHA-128 used by BitTorrent V1. This also enables the Nostr storage mentioned below.
It's possible to improve file availability and download speeds by providing some centrally managed services:
A tracker. Having a tracker specifically for ordinal/inscription users could help improve peer discovery. The tracker could be set to only accept infohashes that were inscribed on the blockchain, so that it couldn't be used as a free-for-all tracker (with webtorrent/bittorrent-tracker, the
filtercallback can be used to check with an external database/api).A DHT bootstrap node. Having ordinal users connect to it can similarly help improve connectivity. (some possible options are bittorrent/bootstrap-dht and webtorrent/bittorrent-dht)
A WebSeed mirror. BEP 19 defines a standard for adding HTTP mirrors to torrents, which can be used in addition to normal peers or as a fallback if there are none.
The ordinals.com server (or whoever else is interested in providing a mirror) would need to run a daemon that: (1) Listens for infohash inscriptions, (2) Downloads the torrents associated with them (probably with some size limit), and (3) Makes them available for download over HTTP.
It appears that webtorrent can be used to achieve this quite easily. It even includes a built-in http server that could be used as the webseed server [0].
This PR assumes that such services exists (on
tracker.ordinals.com/dht.ordinals.com/webseed.ordinals.com), and embeds them into the generated.torrentfiles and magnet links. If you'd like me to, I can remove this.[0] I submitted webtorrent/webtorrent#2487 to add support for serving the
.torrentfile, which this PR assumes to be available on the webseed server at<WEBSEED_URL>/<INFOHASH>.torrent. This makes magnet links work even when there are no p2p seeds.Using Nostr for storage
This can be achieved with this PR by inscribing an
event.jsonfile with the Nostr event in the JSON serialization format used for event IDs. For example:This will inscribe the Nostr event ID as the committed SHA-256, which can then be looked up on Nostr relays. The inscribed torrent can be used as a backup, or ignored.
Possible future work:
Display file previews directly in the browser, either via a webseed http mirror [1] or using an in-browser webtorrent client (its pretty neat that the torrent can be downloaded right in the browser! -- although with the caveat that it can only connect to other WebRTC-enabled peers. See instant.io for a cool demonstration of it.)
Because the inscriptions here are pretty small, this could theoretically use
OP_RETURN, which would avoid the complexities of the two commit/reveal transactions.[1] I submitted webtorrent/webtorrent#2488 to make embedding files from the webseed slightly easier.