STAMP File Storage

Development Counterparty
1

Here’s a suggestion to how Counterparty can handle on-chain file storage better:

Add a special rule that when asset description or broadcast begins with BLOB:, assume the following format; BLOB:{filename},{blob}

The blob is the file’s binary data.

Counterparty will then generate the sha256 hash of {blob} and save the following text to the DB; FILE:{filename},{sha256_hex_encoded}

Notes:

  1. The blob (file) itself is stored inside the BTC transaction but won’t be saved to the Counterparty DB. Storing files should be an optional add-on.
  2. Applying this rule to both broadascts and asset description adds flexibility. For example, someone might want to add a zip file with all subasset files in a broadcast.
  3. It could make sense to limit the length for non-BLOB broadcasts/descriptions to ~500 bytes to reduce database bloat.
  4. I suggest not using the STAMP keyword as it would conflict with the current Stamp standard.
2

Having had the idea mature a bit, I think the best would be a more general rule:

Asset description or broadcast text of the following format
BLOB "{text}" {blob}

… will be saved in the Counterparty DB as
BLOB "{text}" {blob_sha_256}

A wrongly formatted BLOB will save as BLOB invalid.

The protocol shall also be updated to limit the length for broadcasts/descriptions to 500 bytes.

Counterparty has a history of using special keywords. Broadcast with keywords OPTIONS 0 or OPTIONS 1 toggles on/off receiving non-memo sends, if I remember correctly. The keyword LOCK in an issuance locks the supply.

Advantages

  • minimal core protocol change.

  • reduces DB growth.

  • enables any kind of standard for file storage to emerge. STAMPs can easily adapt to this, e.g. by updating the standard to using text STAMP:gif or STAMP.jpeg or STAMP.png with the blob itself as the file.

  • blob data is perfectly efficient. Unlike base64 which only encodes 6 bit per byte, blob contains 8 bit per byte.

  • the blob is saved inside the Bitcoin transaction. Anyone with the file can verify it against the Counterparty database OR recreate the blob data from the bitcoin transaction if they don’t have a copy of the file.

I will write a formal CIP if there is support for this proposal. If this is implemented, CIP26 must be modified and CIP27 will be redundant.