The Protocol

1. Lot ID Generation

To generate the Lot ID, follow these steps:

• Pass a secret, transaction hash, vbyte size, and project name to the generateLotId function.

• The generateLotId function combines the provided values into a combinedString in the format: {secret}_{txHash}

• The combinedString is hashed using the SHA-256 algorithm.

• The hash is encoded into encodedHash using the Base58 encoding scheme.

• The encodedHash is shortened by taking the last 6 characters.

• The sizeLabel is assigned based on the vByte size of the transaction. "estate" | "large" | "medium" | "small"

• The vbyte size, size label, project name, and ".lot" extension are appended to form the final Lot ID: {shortened}_${vbyteSize}_${sizeLabel}_${projectName}.lot

• The Lot ID is returned as the unique identifier for the fractionalized lot of land in the metaverse.

2. Lot ID Usage

The resulting Lot ID serves as the unique identifier for the fractionalized lot of land in the metaverse. It can be used as a land title/deed for the specific lot. The Lot ID should be inscribed as a text inscription. An example would look like this:

gQWu7U_187_small_cool-project.lot

We can tell a lot about this string in a glance. It's by "Cool Project" and it's a small lot with 187 vm². This also gives owners a way to determine if their project namespace is already being used. While project name collisions wouldn't technically matter because of the unique identifier that prepends it, we think owners would prefer to start with a clean slate. In this example, you could search "cool-project.lot" on something like Unisat to determine if the project name was already being widely used.

What is nice about this approach, is that an owner could inscribe all transactions within their Bitmap block at once, or inscribe them ad-hoc over time without the fear of a rogue inscriber claiming the provable identifier. ie Only the original landowner has the secret and can produce the unique ids.

Example Code

import { sha256 } from "js-sha256";
import bs58 from "bs58";

const generateLotId = (secret, txHash, vbyteSize, projectName) => {
  const combinedString = `${secret}_${txHash}`;
  const hash = sha256(combinedString);
  const encodedHash = bs58.encode(Buffer.from(hash, "hex"));
  const shortened = encodedHash.slice(-6);
  const sizeLabel =
    vbyteSize >= 5000
      ? "estate"
      : vbyteSize >= 1000
      ? "large"
      : vbyteSize >= 250
      ? "medium"
      : "small";
  const lotId = `${shortened}_${vbyteSize}_${sizeLabel}_${projectName
    .toLowerCase()
    .replace(" ", "-")
    .trim()}.lot`;
  return lotId;
};

const projectName = "Cool Project";
const secret = "password123!";

// The vBytes for these txs are fake for demo purposes
const blockTransactions = [
  {
    id: "12a736139936b556436b30909738923f6e89f3eddc0ee243a8b4c44418431ae6",
    vBytes: 187,
  },
  {
    id: "a6d9ed33af05dd0d57b7260e233b2b9e3784e6c9dc781c15a271f881c0c763a5",
    vBytes: 275,
  },
  {
    id: "4a83a74324f398d53cb3c8d56c77eb7732f12a3f4998e57647d1669db397d123",
    vBytes: 2343,
  },
  {
    id: "ed16e145735ce241a9f5e19f9c24f6325e6c6060fb95ccf04603a6fe01ab2392",
    vBytes: 7342,
  },
];

blockTransactions.forEach((tx) => {
  const lotId = generateLotId(secret, tx.id, tx.vBytes, projectName);
  console.log(lotId);
});

// Result:
// gQWu7U_187_small_cool-project.lot
// JCacfC_275_medium_cool-project.lot
// x4GiW4_2343_large_cool-project.lot
// R6w67y_7342_estate_cool-project.lot

** Like anything else, nothing is stopping inscribers from inscribing the same text once the first inscription is out there, thus, owners and buyers should always use inscriptionIds as the final source of truth when buying/selling/trading. This protocol gives Bitmap landowners a simple way of ensuring the public doesn't inscribe a valid identifier for their land under the "first-is-first" principle. In other words, the BLIS protocol reasonably ensures the original Bitmap land owner is first.