The text below can be translated into any language using the Google Translate button directly above.
In 2010 discussions started on how to put a DNS System on bitcoin which eventually led to Namecoin in 2013, but because of concerns with blockchain bloat, it forked to a special purpose blockchain from bitcoin.
This started the whole discussion on how to connect off chain assets to bitcoin transactions and the term “Colored Coins” was attached to the technology idea but bloated the UTXOs.
Counterparty in 2014 improved the Colored Coins by adding their own scripting language to manipulate the assets.
To counter the bloat on the blockchain with all the Colored Coins bitcoin introduced the OP_RETURN in 2014. It was proposed at 80 bytes but limited to 40 bytes when released in version 9 2015 then later increased to 80 bytes in version 11. The unique part of the OP_RETURN is that it can never be spent, therefore full nodes can ignore them as transactions speeding processing time. They are simply DATA and not part of the UTXOs.
This led to many other blockchains and altcoins like Ethereum in 2015 that built blockchains that had more room for the Data and integrate it with the smart contracts. But bloated and expensive because of the storage.
I was very active during this time in personal discussions stating I could do everything the other blockchains were doing without bloating the blockchain with data and smart contract code by using the OP_RETURN.
This was an interesting period because everyone wanted to tie real world assets to transactions but could not afford to bloat the blockchains. The OP_RETURN was new, and wallets did not exist. Programming required running your own full node and playing with RAW transactions.
After months of fiddling with the code, just trying to get stuff in and out of the OP_RETURN the HlyGrail Algorithm was first used in January 2016 as a demonstratable product.
The process was simple. Use a known bitcoin address and put the ADDRESS in the media (Intellectual Property File IPF) you want to protect, then hash the file and store the proof of the real-world asset in the OP_RETURN.
The HlyGrail Algorithm was protected with the HlyGrail Algorithm. Within a month, the main project that started this mission, to secure a PDF version of the entire 900 pages of the Authorized King James Version Pure Cambridge Edition was recorded as an IPF on the bitcoin blockchain. Provably unchangeable.
The process improved over a few months and was determined the best process would be to use the NEW receiving bitcoin ADDRESS as proof of the real-world asset because no one knows it until the transaction is complete. The IPF could always be identified as the FIRST transaction into that ADDRESS. The IPF could be identified by the Transaction Number. To add security if wanted the IPF could be encrypted by the ADDRESS then the hash stored. Now you need the bitcoin address and the encrypted IPF to get the information.
Some media was not easy to protect because it was in the market already or it was not easy to put the ADDRESS in the media. To protect that data a separate file (IPF) would contain the ADDRESS and all necessary information such as owner, links to other media and their hash, and other contract data or asset information that may exist prior to creating the IPF.
Most new media can easily have the ADDRESS embedded and for images, you can watermark the ADDRESS to be virtually invisible or in metadata. Or encode the address in pixels using color codes and known spacing.
For the next few years I created HlyGrail Patents / copyrights for myself and others. Everyone I spoke with for programming bitcoin was worried about mass adoption and bloating the blockchain so I never actively promoted the algorithm other than on the HlyGrail and Bitcoin Word of God websites. I exposed the MyCryptoPatent website and sold Patent / Copyrights using the algorithm. Most were private, secured and did not want anyone to know what information was protected.
I eventually created software to create standard IPFs by allowing others to enter data such as owner, titles, descriptions, files, hashes etc. by drag and drop then creating the IPF in JSON programmatically.
One of the early challenges was due to the limited 40 bytes of the OP_RETURN, there was not enough storage to identify both the hash of the file 32 bytes and the location. This was semi solved by using HlyGrail as a pretend to the Hash. There were enough possible combinations in those eight hex to identify four billion locations. The challenge is you would need to have a trusted website to identify the location of the file. This was not a real problem because it does not matter where the IPF is stored because the hash is always the same. To solve that problem the location of the files are often added to the IPF but it does not solve finding the initial IPF. That is solve by making a IPF smart contract computer program with the storage locations built in.
As the Interplanetary File System (IPFS) developed and the OP_RETURN allowed 80 bytes, the storage can now possibly be on IPFS while using the CID in the OP_RETURN for location of the IPF.
Today with Taproot and Ordinals there is a potential of really damaging the bitcoin blockchain with not only bloat but legal issues. Who wants to store pornography on their full node and worry about being arrested?
The HlyGrail Algorithm (IPF) solves this issue because NONE of the data, or assets are stored on the blockchain. Only the verification code for the assets. The IPF is NOT stored on the blockchain.
The HlyGrail Algorithm is complimentary to Lightning and would probably accelerate adoption.
The HlyGrail Algorithm keeps bitcoin fungible. You are truly transacting the value of Satoshi’s but identifying the real-world assets which could be fungible or non-fungible off-chain. With Ordinals, you risk storing non-fungible assets ON the blockchain which could impact larger legal issues besides bloat. Did I mention bloat?
The HlyGrail Algorithm allows ANY smart contract in ANY programming language to read the blockchain and create RAW transactions on the blockchain. The algorithm can identify safe programs and data. The programs and data can be loaded and run in parallel around the world with little impact on the blockchain other than posting financial transactions. All code, data retrieval, and storage is done off-chain.
The next step would be for bitcoin core to add a BIP that uses the algorithm as needed such as storing verified versions of the blockchain off-chain for easy download when starting a new node, adding wallets that will read and display image NFTs identified with the algorithm, and simple IPF / NFT creation by dragging a file to the wallet.
Check the License. Bitcoin Core bitcoin.org is authorized to use the algorithm with no license fee. Other blockchains and forks must have a license. Others developing wallets, and other applications that use the algorithm for gain must get a license.
It is time for the bitcoin community to embrace the HlyGrail Algorithm to nullify blockchain bloat by Ordinals and excessive profit and control by others building competing inefficient chains.
Let your imagination run. You can build anything with this.
You can do your own high quality NFTs, even video and register them for a dollar or less. (I just paid $0.15 to register the HlyGrail2 Update. Yes, there is $11 in the coin but that is because I chose to leave cash to be able to chain it later.)
You could sell your house for a car and vacation home and transfer all the titles for under a dollar.
An important point of the HlyGrail Algorithm is you can decide any level of ownership in your IPF. Not only can it cover complete intellectual property ownership but patent and copyright protection. Even if someone stole your idea and you lost a patent case in court you still control the copyright to any media can and prevent them from marketing it.
Visit MyCryptoPatent and see some example IPFs. Remember all this stuff is off the blockchain. Get ready for a system to integrate and barter virtually everything via the IPF.
Copyright 2023: Genus Enterprises LLLP All Rights Reserved.