# 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](https://unisat.io/search) 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

```javascript
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.