BRC-420–69 Ordinal Inscriptions:

A Standard for Secure File Storage, Authentication, and Management on the Bitcoin Blockchain

LawyerCat42069

13 min readMay 15, 2023

TL:DR

The BRC-420/69 standard opens up possibilities for Ordinal authentication and a web3 environment that relies less on web2 infrastructure and enables various applications, including decentralized readers and browsers, inscribed APIs, and even a Bitcoin Computer/Bitcoin Virtual Machine, of sorts.

What!?

We start with the boring stuff. Please entertain yourself with a thought experiment. What if most of our Ordinals looked like this (metadata embedded in an attached file):

BRC-69
BRC-741 wallet address:

Collection Name: Collection of Ordinals

Collection Image Satoshi number: XXXXXXXXXXXXXXXXX

Item: Item No. / Collection Size

Parent wallet address: bc1qqah90veaaxrcee3hwlxfgucha8npcgp0nzruse 
 
  Parent Token Designation: BRC-420

  Parent Satoshi Number: XXXXXXXXXXXXXXXXX
  Parent Satoshi genesis txid/io:

Child Satoshi Number:XXXXXXXXXXXXXXXXX

    Child file type: JPEG
    
    Compression & Method: .zip

File Password Cipher: LjuGDb4MyvrCeSVj4Ia2LftJpT5wq51pkSqKKwjEm5I= [if desired]

Terms and Conditions txid/io [if applicable]:
    
    Terms and Conditions Satoshi Number [if applicable]:  
    
    Terms and Conditions Auth Wallet Address [if applicable]:
    
**Ordinal.filetype or Ordinal.zip**

The Parent Ordinal would be a JSON consisting of the following metadata:

BRC-420
BRC-741 wallet address:

Collection Name: Collection of Ordinals
    
     Collection Description: This is a collection of Ordinals.
    
     Collection Image Satoshi Number: XXXXXXXXXXXXXXXXX

Collection Image txid/io: XXXXXXXXXXXXXXXXX

Parent Wallet Address: bc1qqah90veaaxrcee3hwlxfgucha8npcgp0nzruse
    
       Parent Satoshi Number: XXXXXXXXXXXXXXXXX
       
    
    Cipher Key [optional if child has encrypted pw]: Purrivate123456!
    
    
    Child File Extension: .jpg
       Children Compression file type [if needed]: .zip
       Is Child Software?: No  
     
     
    Terms and Conditions Auth Wallet Address [if applicable]:
      
      Terms and Conditions txid/io [if applicable]:
    
      Terms and Conditions Satoshi Number [if applicable]:  
     
     
    **Table of collection metadata with references to each child satoshi by satoshi number as well as txid/io (the most immutable data point for an inscription).**

What is that supposed to mean?

BRC-420–69 is a new protocol for Ordinal Inscriptions on the Bitcoin blockchain. This protocol provides a method of storing files with embedded metadata as an Ordinal that is potentially private, immutable, secure, takes up less block space, allows for delayed reveals of ordinals after minting, and contains verifiable metadata associated between the child file and the parent collection metadata — ensuring long term provenance. This is also a standard that theoretically allows for onchain indexing between the parent and children ordinals, possibly allowing for fully permissionless Ordinals marketplace protocols that still authenticate & display collection information and metadata.

The 420

The protocol involves a parent inscription (BRC-420) that contains a public JSON file. This JSON file indexes all of the child Ordinals by a combination of transaction ID and first-output as the most immutable data point for the indexing of Ordinals, and describes all of their other metadata, collection information, an AES encryption key [if applicable] of the password for the compressed ordinal on the child satoshi (if compressed), and the collection owner wallet(s). Credit to DAnTer for teaching me how this is immutable & can be reproduced with API calls.

The 69

The child inscription (BRC-69) consists of the necessary metadata specified above steganogrpahically embedded into both the file itself and a compressed/zip file (if used, depending on the needs and desires of the inscriber). Because the transaction ID and first output cannot be known for the parent at the time of the child inscription creation, children will cross-reference the parent Ordinal by satoshi number, parent genesis txid/io, and parent wallet address as the best available data point for the indexing within children ordinals.

NOTE: Bitcoin Core API does not currently support RPC to call the parent satoshi by number, full onchain automation may require this. Really without an API to fetch inscription data associated with a txid/io, this may not exist yet. In the meantime a collection can only be validated onchain if the collection owner submits the parent BRC-420 file to a marketplace. Maybe that is fine, and could simplify the protocol. Possibly something using the parent genesis txid/io, so that has been included. A script could be written and inscribed to number satoshis based on genesis txid/io and that index could be stored either offchain or in multiple chained tables onchain. Ordinals API works in the meantime, but is not fully onchain indexing.

Why Compress?

The significance of using compression is two-fold: It allows us to inscribe more bytes of information into a single inscription, enabling significantly larger file inscriptions, and it also enables us to readily password protect the data in a way that is harder to externally discern without unlocking the file.

Why Ciphers?

Don’t you want to be a crypto-punk? Ciphers most securely allow for delayed reveal, while still allowing the reveal password to appear in the child collection metadata. If password protected, with the key you can decrypt the cipher, which gives you the password for the compressed file. The strings are further decoded into file and metadata, and the metadata is then steganographically embedded into the output file. Collections could use individualized passwords/keys creatively in order to enable fun, interactive minting processes. Ciphers and inscriptions, all the way down. Could be a very fun game.

The delayed reveal functionality allows for fair minting of ordinals to happen entirely and natively on the Bitcoin blockchain. Ordinals can be listed on marketplaces sight unseen, and they can revealed (upon parent inscription) after sellout. Only the holder of the parent information (and others with access to that information) would know the underlying files before the parent inscription was made and the key publicized.

How can this enable permissionless Ordinals interactions?

The vision is that a marketplace/wallet/app Ordinals reader will automatically pull the key from the submitted BRC-420, then have the ability to decrypt any cipher, unlock the underlying files, extract only the specified file type, and save it in the appropriate file type (designated in the BRC-420), in a sandbox environment used for display/ux. The 420 reader would need to be designed carefully to prevent unwanted injection of malicious information by ensuring that the included information met security standards. This could apply to a multitude of file types. So long as the process for ensuring provenance of the parent/child pair is legitimate, and a properly constructed environment is used for the sandbox application, the underlying files should be safe to extract and use in this way.

NOTE: TESTING IS REQUIRED TO DETERMINE THE EXTENT TO WHICH BYTES CAN BE EMBEDDED IN YOUR PARTICULAR FILE WITHOUT ALTERING COMPRESSED FILE CONTENTS. THE SECURITY OF OF ANY ENCRYPTED PASSWORD IS IN LARGE PART DEPENDENT ON THE LENGTH OF THE ENCRYPTED PASSWORD. PASSWORDS OF FILES ON THE BLOCKCHAIN ARE SUSCEPTIBLE TO BRUTE FORCE ATTACKS, SO ANY EFFORTS AT TRUE SECRECY MUST TAKE THIS INTO ACCOUNT.

Adhering to Protocol:

Once inscribed, the parent inscription must remain in a designated owner wallet, or be sent to Satoshi’s wallet to “renounce” the collection.

This BRC-420 inscription can technically be inscribed in an encrypted manner as well, to allow for less decentralized but more private decryption, or could even remain uninscribed to maintain more secrecy of the underlying inscription data, but those are not supported by this protocol. However the privacy implications could be significant for any types of document that an individual might want inscribed onto the blockchain without it being publicly visible or known.

INSCRIBER PROTOCOL:

Assemble Parent (BRC-420) Collection JSON with all desired metadata and files for the collection.
Identify target satoshi of parent ordinal using a satoshi indexer, add that information to BRC-420 and individual child metadata.
OPTIONAL: Choose a secure password for compressed files (delayed reveal, secrecy/privacy).
OPTIONAL: Encrypt password using AES Encryption, note encryption key in BRC-420 table. Insert cipher into child ordinal metadata table.
Steganographically embed the metadata into the files (automated ideally).
OPTIONAL: Compress the Child Ordinal files.
OPTIONAL: Lock the Zip file using the chosen password.
OPTIONAL: Then, you will need to steganogrpahically embed the Child Ordinal metadata onto the compressed files (also automated, same process).
Inscribe all of the child ordinal files first, noting each satoshi number and txid/io.
Complete the BRC-420 metadata table with the information from step 9, ensure completeness of metadata.
Inscribe BRC-420 JSON file onto target parent ordinal.
Ensure accuracy and validity of all metadata, send parent ordinal to Satoshi’s wallet if there is a desire to renounce the metadata.
Make marketplace aware by sending txid/io of the BRC-420 (or the inscribed file) to marketplace.

READER PROTOCOL:

If centralized — review BRC-420 and child ordinals to ensure security and compatibility with marketplace standards.
If decentralized — Operate in a secure sandbox environment with access to bash/python/java/any other needed coding libraries and a basic web browser (or maybe one day, BitcoinBrowser), other file readers, any other security protocol deemed needed. Maybe the shell script could also be inscribed. Receive BRC-420 from owner wallet and store the data.
Always ensure provenance of parent/child pair, first check that parent is in an authorized wallet and that the satoshi numbers and file type metadata contained in both ordinals match the expected numbers and file types based on cross-referencing — compare txid/io to the child ordinal contents. If it does not match, delete file and display that “Ordinal cannot be displayed because it cannot be authenticated.”
Default display for any encrypted/compressed Orindal is the collection image as specified in the BRC-420. After ensuring provenance, check for compressed file. If yes, check for pw lock. If locked, check BRC-420 for line containing encryption key. If none, prompt user for Encryption Key.
Using Encryption Key, decrypt file password from metadata. Unlock file, check file type against parent ordinal metadata. If file type does not match, clear directory and immediately terminate shell.
Assuming file type matches, Check steganographically embedded metadata. If metadata does not match, clear directory and immediately terminate decoder.
Assuming metadata matches, perform any needed security checks, If the compressed file fails the security check, clear directory and terminate shell.
Extract/save the file to specified (temporary) directory for use, open appropriate reading application (ideally an authentic inscribed dApp), or opens the directory containing the downloaded file if no appropriate reader can be found within the shell. HOWEVER: if designated by the BRC-420 as software, the application should instead call the most current txid/io in order to call the most recent update.
Reading application picks up on and displays all Child Ordinal metadata alongside the Child Ordinal file in an aesthetically pleasing manner.
When application is terminated, optionally clear cache as well.

How Onchain Indexing?

By establishing a dApp and token inscription system that monitors the blockchain and keeps an onchain index of all BRC-420 inscriptions from the moment of their appearance on the blockchain by inscribing them in tables kept/sent to & in a single wallet, (Token designation BRC-741), along with their genesis txid/io and inscription txid/io, we can onchain index via triangulation between the child satoshi txid/io, the parent genesis txid/io, and the inscribed tables contained in the BRC-741 wallet address. The wallet address itself is the third immutable point, and with proper dApp structure the data inscribed. We can establish fully onchain authentication of Ordinals for a variety of use cases using two immutable points of data and inscribed tables all found in the same wallet.

Ideally this dApp is run alongside Bitcoin Core so that there is decentralized hosting. The keys to the wallet used by the dApp should be cryptographically generated upon its launch and either immediately forgotten after determining the wallet address or retained internally by the dApp (managed by multisig?) in order to deal with spam. The dApp can send updated tables or new tables as needed (either on a time-based interval or when a new full table is created) to dApp users by generating the new table as read-only output in their specified directory, and the inscription of those updated tables can be handled on a regular basis through other dApp protocols (multisig crowdfunding of the inscription of the new table, perhaps). Theoretically, after inscription, or once “perfect” operation has been achieved, the dApp inscription itself could be sent to the BRC-741 wallet to become fully autonomous and self-governing, though dependent upon users of the dApp to fund new inscriptions.

SWOT ANALYSIS

Strengths: I believe these are fairly indicated above. I think the greatest strength lies in the potential of onchain indexing. The compression and cryptography we can take or leave as desired.

Weaknesses: Disadvantages to this standard, especially currently, is that it’s a lot of work to get all of the pieces of a collection together, which could be discouraging for use of the protocol. Figuring out sat #s in advance and targeting them specifically in advance is no easy task — but that is the price that must be paid for provenance as far as I can tell.

Additionally another disadvantage of the compression/encryption is that the complication of decryption means that individuals will need to rely on readers in wallets, websites, marketplaces, and other applications in order to make the ordinal enjoyable in the traditional way. The complication of decompression of a strange file on the blockchain comes with security risks. The tools will need to be built, safely, and people will need to be convinced that this is worthwhile. However if these reader scripts and applications can be inscribed, they too could exist as dApps on the Bitcoin blockchain that can be easily accessed with the right starter data.

The next thing I would add is that this protocol is a tool with potential for positive or negative use cases, so I encourage any development on this protocol to keep in mind ways we can integrate best practices to mitigate any potential harm. I don’t see alternatives to that which are fully decentralized, but distributed authority systems could make those alternatives more trustworthy, or at least create a system of trusted resources by reference to their ordinal information such as dApps, websites, etc. People could rely on them or not as they chose, but I see value in a trustworthy source of information on which inscribed dApps and inscribed websites, in particular, are safe. Additionally could include an inscribed list (or multiple lists linked with metadata) of malicious or problematic inscriptions for decentralized protocols to optionally filter out such content.

Finally, a weakness realized late is that onchain indexing is challenging. Someone could overwhelm the BRC-741 wallet address with junk table inscriptions, and make it more challenging to triangulate using onchain data. Perhaps cryptography with a key known only to the dApp is the solution there. When I run into problems lately, the answers seem to be “more math” or cryptography.

Opportunities: It’s a wide open field right now with Ordinals just becoming popular. Now is the time to set a strong standard that takes into account security, decentralized protocols (onchain indexing), and other standards to ensure secure, optimal use cases for the technology moving forward. I think the time is right to publish some complete thoughts and keep moving the conversation forward.

Threats: Abuse of the protocol leading to a bad reputation is my primary concern here. Malware or other malicious/illegal files being inscribed and attempting to fool the protocol to create security or other threats to end users or the blockchain itself. Aside from that, the threats to this protocol are the same as the threats to Bitcoin itself.

I look forward to seeing what others have to say/think about these ideas.

Where does this go?

An actual web3. One that does not need to depend on web2 infrastructure other than the series of tubes itself to exist in any way, shape or form. Let’s look at it from the 30,000 foot perspective:

Any file that can be compressed and inscribed can be authenticated and viewed using information that is entirely onchain. All you need is the ordinal, the key/password (if needed) and the proper application to read the file, whatever it may be. You can put dApp pieces (including such a reader) into inscriptions that contain executable code and cross-reference them with each other, daisy chain them, using inscription metadata. You could also inscribe compressed/ protected webpages — securing your HTML code with the power of strong password security and the AES/MD5 hash (really, TLS is an option here too). By ensuring provenance, we can ensure security too.

You can inscribe html that calls to other inscriptions to display media or potentially even execute dApps, and can only be decompressed and read with the encryption key, which can be public or private. And once it is on the blockchain, it’s there forever. Webpages would likely require a different protocol entirely with their own provenance standards. The html can also call to data offchain. Permanent webhosting of plenty of data on the bitcoin blockchain, and on your satoshis. Updating the website only costs you inscription fees, and very small ones at that because HTML does not take up huge amounts of byte space. The server/site hosting is taken care of by the operation of the blockchain.

For normal Ordinals, I would like to get to the point where anyone with the script can take a file library and properly formatted JSON + metadata table in a folder, aim a bash command at the folder, generate the cipher and embed the metadata automatically, with minimal input. I believe the inscription of those ciphers could be further automated if the target satoshi information is known but that is beyond my current knowledge/skill. If anyone wants to help, please reach out!

Bitcoin Browser, On-Chain Internet

You can inscribe a BitcoinBrowser to make API calls to the blockchain and/or explore the internet. YOU CAN INSCRIBE APIs! By doing this in a sandbox environment with an amnesiac cache and using the BRC420–69 protocol to ensure that the ordinals in question reside in the owner wallet or satoshi’s wallet, this would be a very secure environment for the execution of dApps, viewing of inscribed websites, and many other applications. You can travel the world and access everything with nothing more than your seed phrases, any nonpublic encryption keys and a qualifying terminal.

The Bitcoin Computer

You could make it such that a terminal with bash, programming libraries with a full compliment, bitcoin core (w/ API), inscription wallets, and an internet connection is capable of executing all of this in a sandbox environment with an amnesiac cache (inscribable). You could inscribe and readily call a lightweight OS to be installed in the sandbox on an Ordinal or a series of Ordinals. Software updates can be pushed by inscribing new code on linked BRC 420–69 pairs (uncles and cousins, I suppose), or compressed code on the relevant satoshi (this may require a slightly different standard to manage for top-down ordinal relationships like software updates, but I have contemplated that some here). If re-inscription of satoshis is possible, the onchain hosting potential is limited only by the fees paid. There are surely limitations on size but the continued availability of off-chain internet can supplement by calling to secure sources of offchain data until we can compress even better. (NOTE: L2 development including on Stacks could facilitate onchain hosting of larger amounts of data, possibly?) You could do a lot in a short time starting off with a mostly empty computer, your wallet seed, and any nonpublic encryption keys. A neat thought.

Is this too complicated?

Possibly, definitely for some — but the complicated aspects can be automated and drastically simplified from the end-user/UX perspective. I am imagining a future where it doesn’t matter if the government “shuts off the internet” as long as the Bitcoin network is operational. Node servers, node hosts. No gods, no masters. I think at the end of the day, there will be some people who see value in this. It doesn’t take many to turn this into a reality.

Conclusion

The BRC-420/69 standard provides a robust method for taking file collections with associated metadata and inscribing them on the Bitcoin blockchain, potentially in a cryptographically secure manner, and ultimately decompressing & decoding those inscriptions publicly with the inscription of the encryption key as a part of the parent ordinal. This allows for unique, secure, identifiable, and verifiable inscriptions in the form of ordinals on the blockchain. The potential for this idea to expand to include a variety of use cases, I think, is significant. As many use cases as there are for a more secure & private internet, essentially.