STAMP File Storage

Development Counterparty
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.