CIP 26 - STAMP Protocol

jdogresorg · April 19, 2023, 4:20pm

A few weeks ago @mikeinspace posted a document outlining how users could “stamp” an image to a token, and also laid out the basic guidelines and rules for the “Bitcoin Stamps” project. This project has seen a bunch of attention lately, over 32k+ items have been “stamped” to tokens on Counterparty, and people are even “stamping” over on Dogeparty. Also “Bitcoin Stamps” has resulted in a bunch of new users and developers interested in learning more about Counterparty. We all owe @mikeinspace a thank you for coming up with this “stamp” process and generating a bunch of new eyes on Counterparty.

Here is the Bitcoin Stamps Document to which I refer:

github.com

mikeinspace/stamps/blob/main/BitcoinStamps.md


# Bitcoin Stamps

Storing "Art on the Blockchain" as a method of achieving permanence is often a misnomer in the NFT world. Most NFTs are merely image pointers to centralized hosting or stored on-chain in prunable witness data. We propose a method of embedding base64-formatted image data using transaction outputs in a novel fashion.

The means by which this is achieved is encoding an image's binary content to a base64 string, placing this string as a suffix to `STAMP:` in a transaction's description key, and then broadcasting it using the Counterparty protocol onto the Bitcoin ledger. The length of the string means that Counterparty defaults to bare multisig, thereby chunking the data into outputs rather than using the limited (and prunable) OP_RETURN. By doing so, the data is preserved in such a manner that is impossible to prune from a fullnode, preserving the data immutably forever.

Given the cost of preserving data in this manner, we suggest the following guidance: 24x24 pixel, 8-colour-depth PNG or GIF. The constraints of this "canvas" are ideal for pixel art. In particular, the CryptoPunks use a native resolution of 24x24 pixels. While the technical specifications are open to interpretation and reinvention, inclusion within the Bitcoin Stamps directory will rely on a number of consensus rules on Bitcoin Stamps which are distinct from any other cases of using P2SH to encode data in this manner.

Bitcoin Stamps will be numbered based on the transaction timestamp. This is to ensure that the Bitcoin Stamps directory is ordered chronologically. The first Bitcoin Stamp will be the first transaction to include the `STAMP:` string with a valid base64 string appended in the description key, and so on. A transaction with an invalid or indecipherable base64 string will not be considered a Bitcoin Stamp. The Bitcoin Stamp number will begin at zero and continue indefinitely.

## What Makes a Bitcoin Stamp?

A Bitcoin Stamp is a Counterparty transaction which contains a valid `STAMP:base64` string in the description key. STAMPS can be decoded directly from the original Bitcoin transaction. In order for speed of processing and to eliminate needs for indexing, we are utilizing Counterparty API to decode the original Bitcoin transactions. Once the decoding is complete, we upload the images to stampchain.io for consumption via web applications as a convenience. It is intended that anyone may decode these transactions and interpret the underlying image data for rendering on any application. 

## Bitcoin Stamps abide by the following rules:


- A Bitcoin Stamp must be a numerical asset, for example: [A1997663462583877600]
- A Bitcoin Stamp can be created from a previously existing numerical asset which was not previously a STAMP. This is accomplished by updating the asset to include the `stamp:base64` string in a new transaction.

This file has been truncated. show original

The purpose of this post, and the forthcoming “STAMP Protocol” CIP I am currently writing is to clarify the technical process of how to “stamp” a token with a file, separate it from any project-specific rules (numerics only, stamp must use multisig outputs, stamp must live in utxos, etc.)

I will post a link to the STAMP Protocol CIP pull request shortly.

jdogresorg · April 19, 2023, 6:13pm

Here is the proposed “STAMP Protocol” CIP

github.com

jdogresorg/cips/blob/master/cip-0026.md

        CIP: 26
        Title: STAMP Protocol
        Author: MikeInSpace & Jeremy Johnson (J-Dog)
        Discussions-To: https://forums.counterparty.io/t/cip-26-stamp-protocol/6563
        Status: Draft
        Type: Process
        Created: 2023-04-20

# Abstract
Enable linking of a `file` to an `asset` via a `stamp`.

# Motivation
Define a process for encoding a `file` into a transaction and associating the `file` with an `asset` via an `issuance`.

# Rationale
The [`Bitcoin Stamps`](https://github.com/mikeinspace/stamps/blob/main/BitcoinStamps.md) spec  first proposed the basic guidelines for how to create a `stamp`, as well as additional guidelines for the [`Bitcoin Stamps`](https://stampchain.io) project.

This CIP has been created to clarify the technical process to `stamp` a `file` to any `asset`, and remove any project-specific requirements from the protocol.

# Definitions

This file has been truncated. show original

and here is the pull request if anyone wants to comment on github directly

mikeinspace · April 19, 2023, 6:45pm

First of all I want to thank JDog for being so supportive of Stamps from the beginning. Honestly, native xchain support was probably integral to Stamps’ success, in my view.

Regarding titles, I’ve heard back from many in the community that its something they would love to have and I think it can be implemented in a very non-invasive way.

Following the method employed by xchain already for imgur and youtube links:

imgur/i08zbUH.png; Title Goes Here

Method for Stamps: stamp:iVBORw0KGgoAAAANSUhEUg==; Title Goes Here

mikeinspace · April 19, 2023, 6:48pm

We are also thinking through a method of adding titles to older stamps without requiring users to touch the asset description again. We believe this can be facilitated through a broadcast-type txn that references the asset name and the title. Formatting has not yet been finalized but something along these lines:

STAMP_TITLE:A9364494683859804778 = This is the title

It would be valid if broadcast from the issuance address of the asset.

sull · April 20, 2023, 5:22am

STAMP_TITLE:A9364494683859804778 = This is the title

I was thinking about this the other day too.
Broadcasts standardized for STAMPS is a clean approach for various purposes imo.

I might suggest this format:

STAMP:METADATA:A9364494683859804778;TITLE=;DESCRIPTION=;JSON=<JSON_DATA_URL>

And this sort of namespaced message prefix can be used for other things such as messaging your community or individual owner.

STAMP:MESSAGE:A9364494683859804778;CONTENT=<MESSAGE_CONTENT>

Messages can appear with STAMPS in marketplaces/wallets.

Or perhaps

STAMP:LINK:A9364494683859804778;URL=

A way to share official links related to project/artist etc.

jdogresorg · April 20, 2023, 2:43pm

After giving this “TITLE” topic a bit more thought… I feel that the “STAMP Protocol” should remain clean and only pertain to stamping files to the blockchain, and not be modified to fit in this “title” field.

If someone wants to include additional information about a STAMP, I think the most straightforward approach would be to stamp a second JSON file which contains additional information about the stamp. This will allow for inclusion of a bunch of additional information about a stamp, in a file format that is open… and maintains the “stamps only deal with files” rule (which is necessary to implement the next forthcoming “STAMP Filesystem” CIP, where stamps are compartmentalized and stamp data is removed from the CP/sqlite database and written to actual files)

Example JSON
{ "title": "This is a really long title for this artwork" }

IMAGE encoded into a STAMP file
image/png;iVBORw0KGgoAAAANSU...

JSON encoded into a STAMP file
application/json;eyAidGl0bGUiOiAiVG...

IMAGE and JSON Stamp
stamp:image/png;iVBORw0KGgoAAAANSU...;application/json;eyAidGl0bGUiOiAiVG...

As far as the “Stamp Title via Broadcast” method, I have no objections to this method, as it is completely external from the STAMP protocol.

Topic		Replies	Views
Counterparty Paper Wallet Design 3rd Party	2	1978	April 30, 2014
CIP27 - STAMP Filesystem Counterparty	2	265	June 9, 2023
'getrawtransaction' for counterparty Counterparty	1	677	October 21, 2014
[ANN] The Counterparty weekly blog is live! Announcements	6	802	March 2, 2014
Counterwalletd Preview thread Counterparty	72	1432	March 14, 2014

CIP 26 - STAMP Protocol

Related Topics