CIP: 27 Stamps Protocol Clarification and File Storage

[hydren-crypto]

This is for clarification on this CIP 27 and the differences between Bitcoin Stamps and the general Stamps protocol indicated in the CIP.

Bitcoin Stamps are based upon the messages table (original bitcoin transaction) which cannot be changed (without removing the mirror of the btc trx anyway) , and is what makes stamps immutable. The proposal to have a Counterpary Stamps protocol on the issuances table is flawed based upon the immutability of stamps, and the original design.

Since the issuances table description field is changeable based on future transactions any potential file storage should be based upon the decoding of the messages table instead - as any future data in the issuances may or may not be a stamp for that asset.

Specifications for Bitcoin Stamps

messages table:
command = insert
category = issuances
the first occurrence (transaction) of a valid numeric asset in the table with a valid stamp: prefix at the start of the description field followed by valid base64 string (as decoded by python - Node gives different results on valid/invalid base64) - along with the exclusion of base64 that decodes to binary or various other non-image formats or additional data.

[jotapea]

@hydren-crypto FYI:

#84

The CIP has been withdrawn, but I can understand that by staying in the list it can still cause confusion / issues. Some of these last CIPs should have not been there in the first place.

The author himself seems to agree.