Bitcoin Cemetery

this is the gitbook introduces how Bitcoin Cemetery works.

Bitcoin Cemetery is a cyber cemetery built on Bitcoin based on the Ordinals theory, providing a place where memories can be permanently preserved alongside Bitcoin. The technical implementation leverages recursive ordinals, utilizing endpoints provided by Ordinals to add a mutable aspect to inscriptions, which are otherwise immutable.

Why Build a Cemetery on Bitcoin?

In the 21st century, we lack reliable methods for commemorating things. No matter where we store what we want to remember, there is no way to ensure its truly permanent preservation. Bitcoin provides a promising solution to this problem. As the consensus around Bitcoin grows stronger, the most powerful consensus network in human history has been established. This decentralized network, where information is guaranteed to be tamper-proof, allows us to freely store the information we wish to record on the blockchain. Against this backdrop, creating a cemetery on Bitcoin as a foundational structure offers an interesting application for Bitcoin inscriptions.

By using r/children, we can ensure all the tombs can be seen in one single inscription.

Sturcture and implementation logic of Bitcoin Cemetery

Before explaining the implementation logic and structure of the entire cemetery, I need to introduce two important endpoints. The first endpoint is /r/content, and the second is /r/children.

Firstly, /r/content is the endpoint used to retrieve the content of an inscription, while /r/children is used to obtain the IDs of an inscription's child inscriptions. Using these two endpoints, we have designed the following structure for the cemetery:

1. Cemetery and Tombs

Above is the structural diagram of the cemetery tombstones.

The cemetery will have a grandmother inscription, which serves as the parent inscription for the cemetery and the cemetery will be presented in the following format:

• add a cemetery

{
    "cemetery_name": "test cemetery",
    "farview_picture": "df36b54ed247dd0f6752cec04ec835e1700376b0ce0cc94cb50891d547a697fdi0",
    "introduction": "This is a test cemetery, we are doing some test works.",
    "tombpicture1": "2bb25b9a4d82df3e4e98b05d31cb4eb54d43445e0a83ce5785a49c4f4621d3dai0",
    "tombpicture2": "48bd1d044a70db8ea0d7ab21b8e14f1c4c4e79cd1addb64d620e13c855b45ddbi0",
    "tombview_settings": "232d1d044a70db8ea0d7ab21b8e14f1c4c4e79cd1addb64d620e13c855b45ddbi0",
    "upside":"4e29bf22812ce3bcb27c75865dba20654f7b5bbf20256419818d242d843a2da0i0",
    "middle":"95f260aa0e654e7a61b91b83d7fbf6ca101785683f7a7e2314d478cfc15d18c9i0",
    "downside":"3aec2d439cdcdff3c6074d49e4e6302a76c8c3c5dcba26a05725f5a62ecca774i0",
    "blockrange": "1-1200",
    "scroll_background": "a49839bda3a23a9ec98cc5c21ec542f8b6c27ce108d7554c04259f2a7dd1b1aai0",
    "tombbackgroud_grass": "d468ab14e204c040b314a3551b1b01848b5cdb5656f8c1d19c95c9e849d7b744i0"
}

This format includes all the information required for the cemetery. With this structure, we can freely expand the cemetery.

The cemetery and tombstones contain a block field, which is tied to a specific Bitcoin block. Each tombstone corresponds to a specific block on the Bitcoin blockchain, meaning that the number of tombstones in the Bitcoin Cemetery is equal to the number of Bitcoin blocks. Each cemetery selects a block range before being deployed, and the block ranges of different cemeteries cannot overlap. Each cemetery can only have a fixed number of tombstones, with each block being used only once. The cemetery continuously retrieves the current Bitcoin block height to ensure that the maximum number of tombstones in the cemetery is in sync with the Bitcoin blockchain. Meanwhile, there is a field that includes "upside," "middle," and "downside," which correspond to inscriptions displayed as three scroll images, divided into upper, middle, and lower sections. These three assets are used for the view that appears when a tombstone is clicked. Upon clicking a tombstone, a modal window will appear. This modal is designed with a three-part scroll layout, enabling the webpage to seamlessly handle varying amounts of tombstone information. Whether the story is extensive or minimal, the modal can dynamically allocate a different number of middle sections to accommodate the content.

Our tombs are svgs. They are combinations that are from some patterns. The tombview_settings is telling where those patterns are and the background color.

And each cemetery will have different art style. They will have unique looks of surroundings and tombs.

{
  "background_color": "#94b91f",
  "type": "1",
  "tombpicture1": {
    "size": 650,
    "x": 300,
    "y": -40,
    "elements": {
      "photo": {
        "size": 80,
        "x": 290,
        "y": 150
      },
      "name": {
        "color": #81776e,
        "size": 26,
        "x": 290,
        "y": 260,
        "color": "#81776e"
      },
      "dates": {
        "size": 26,
        "x": 290,
        "y": 300,
        "color": "#81776e"
      }
    }
  }
}

• add a tomb

{
    "tombstoneType": "1",
    "ownerName": "Vincent van Gogh",
    "dates": "March 30, 1853 – July 29, 1890",
    "story":"Vincent van Gogh (March 30, 1853 – July 29, 1890) lived a life as brilliant and fleeting as a shooting star. Though poverty-stricken and mentally tormented, he transformed his pain into vibrant masterpieces, each stroke a cry of emotion, every hue a blaze of his soul’s fire.

The story unfolds on the last day of his life. It was a tranquil summer afternoon when he carried his easel to a golden wheat field. The wind gently rustled through the stalks, creating a ripple of whispers in nature's voice. Standing in the heart of the field, he gazed intently at the endless expanse of yellow, as if finding an elusive peace.

He began to paint, his brush moving with fervent urgency. He captured the boundless wheat field, the dark crows circling ominously in the sky, and the farewell of his innermost feelings. As the sun dipped lower on the horizon, he laid down his brush and looked upon his work, a faint smile touching his lips.

The next day, he was found near the wheat field, his painting tools still in his hands. His life had ended in the golden embrace of that summer landscape, but his art lived on, immortal.

The painting, later titled Wheatfield with Crows, became his haunting farewell, a vivid testament to his love for art, life, and the world, even in the shadow of despair."
    "imageInscriptionId": "0581cb37c665d6b24e0a01a72f260b8998fb0fcffc1fab261c10854c9d41c34ci0",
    "storyInscriptionId": "",
    "block": 1
}

This JSON structure is similar to that of the cemetery, containing all the necessary information for a tombstone. Through this structure, we can freely add corresponding tombstones to the cemetery.

2. Module Loading and Flexible Expansion for JS and Tombs

The modular design of this project allows for dynamic loading and management of pluggable features within the cemetery. For instance, the ModuleLoader class is used to initialize module loading, retrieve information about JavaScript modules, and display them accordingly. This design ensures that the functionality of the cemetery can adapt to changes flexibly, such as dynamically adding new modules or removing existing ones.

The module loader manages modules using two sets: modulesToAdd and modulesToDelete. It first retrieves all the child inscriptions using the /r/children endpoint and then determines, based on each inscription's type, whether the corresponding JavaScript module should be added or deleted.

The child inscription formats are as follows:

• Adding a Module:

// add js
{
    "type": "add",
    "jsname": "butterflyneww.js",
    "js_id": "55d9aee590c64745aadbc2d6eaa396dcedcfbeee036607e7793dd6b18401b013i0"
}

Here, type indicates that the operation is an addition (add), jsname is the name of the JavaScript file to be loaded, and js_id points to the inscription ID that contains the code.

• Deleting a Module:

// delete an existing js
{
    "type": "delete",
    "js_id": "55d9aee590c64745aadbc2d6eaa396dcedcfbeee036607e7793dd6b18401b013i0"
}

Here, type indicates that the operation is a deletion (delete), and js_id is the ID of the JavaScript module to be removed.

In ModuleLoader, these child inscriptions are processed and added to either the modulesToAdd or modulesToDelete set, ensuring that the system effectively manages which modules need to be loaded and which ones should be removed.

It is important to note that the functionality for adding or deleting tombstones is implemented through other functions, not by the ModuleLoader class.

Through this logic, we have implemented pluggable JavaScript animation loading.

At the same time, our tombstones have a similar error correction mechanism, which is used to remove maliciously uploaded tombstone information (e.g., someone maliciously uploading information about a living person or uploading discriminatory and offensive content through the cemetery).

The structure of the deletion mechanism is as follows:

• delete a tomb

{
    "cemeteryid": "757d6dbadd3a6d15dbd562de6eb9cfdc718a27023d1ab259b181036d77a91edei0",
    "deletetombid": "dce8d1137ca0e68c6061244c7e7876ed860bfc0a4109bed2cbfb1c7e08c3c224i0"
}

This JSON contains two identifiers: the cemetery ID and the tombstone ID. With this structure, every time the webpage is loaded, it also loads information about deleted tombstones. Whenever a user opens the cemetery, it iterates through the tombstones and removes the corresponding ones to ensure they are not displayed in the cemetery.

Summary of Bitcoin Cemetery Structure and Implementation

The Bitcoin Cemetery project leverages the Bitcoin blockchain to create a digital, immutable cemetery that stores memories and commemorative messages. Using the three-layer structure of grandmother inscriptions, cemetery inscriptions, and tombstones, the system ensures that the cemetery information is organized, expandable, and securely preserved on the blockchain.

The project incorporates key endpoints like /r/content and /r/children to manage inscriptions and their relationships. The block field ties each tombstone to a specific Bitcoin block, providing a one-to-one connection between the blockchain's growth and the number of tombstones, making the Bitcoin Cemetery truly unique. The modular design of the project, supported by the ModuleLoader class, allows for flexible addition and removal of JavaScript modules, enhancing the interactivity of the cemetery without compromising data integrity.

The cemetery also features an error correction mechanism to handle malicious content, ensuring that the information stored remains respectful and appropriate. This thoughtful approach to preserving memories ensures that the Bitcoin Cemetery will continue to evolve alongside the blockchain, creating a space that grows as Bitcoin does.