From 712ffafc637c9c27304b8629982eeaeb6d43ffde Mon Sep 17 00:00:00 2001 From: Melvin Carvalho Date: Sun, 11 Jan 2026 08:50:50 +0100 Subject: [PATCH 1/4] BIP-XX: MRK On-Chain Marking Protocol Introduces a compact protocol for timestamping and attributing content references using OP_RETURN transactions. Supports: URL, Address, Content, Nostr, Git Commit, Document types. See: https://github.com/project-bitmark/BIP/issues/5 --- bip-xx-mrk-protocol.mediawiki | 159 ++++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 bip-xx-mrk-protocol.mediawiki diff --git a/bip-xx-mrk-protocol.mediawiki b/bip-xx-mrk-protocol.mediawiki new file mode 100644 index 0000000..e4dc65c --- /dev/null +++ b/bip-xx-mrk-protocol.mediawiki @@ -0,0 +1,159 @@ +
+  BIP: XX
+  Title: MRK On-Chain Marking Protocol
+  Author: Bitmark Development Team
+  Status: Draft
+  Type: Standards Track
+  Created: 2025-01-11
+  License: MIT
+
+ +==Abstract== + +This document specifies MRK, a protocol for timestamping and attributing content references on the Bitmark blockchain using OP_RETURN transactions. Marks provide a permanent, verifiable record linking on-chain transactions to off-chain content, enabling proof-of-existence, creator attribution, and value-bearing endorsements. + +==Motivation== + +Every day, billions of interactions signal value—likes, shares, upvotes—yet none of it accrues to creators or persists beyond platform lifetimes. These signals exist at the pleasure of intermediaries who harvest attention while the underlying value evaporates. + +A mark is different. A mark is a like that costs something and lasts forever. + +When you mark content, you commit real value to a permanent record. The transaction fee becomes the weight of your endorsement—not a cost extracted by a platform, but a signal embedded in an immutable ledger. Creators accumulate provable reputation. Curators build track records. The web grows a memory. + +MRK provides the minimal primitive needed: a compact, extensible format for anchoring references on-chain. What gets built on top—reputation systems, content discovery, attribution markets—emerges from this foundation. + +==Specification== + +===Transaction Structure=== + +A mark transaction is a standard Bitmark transaction with: +* '''Input(s)''': UTXO(s) controlled by the marker +* '''Output 0''': OP_RETURN containing mark data (37 bytes) +* '''Output 1''': Change back to marker (or recipient for Type 2) + +===OP_RETURN Format=== + +
+OP_RETURN  
+
+| Field       | Size   | Description           |
+|-------------|--------|-----------------------|
+| OP_RETURN   | 1 byte | 0x6a                  |
+| Push opcode | 1 byte | 0x25 (37 decimal)     |
+| Mark data   | 37 bytes | See below           |
+
+ +===Mark Data Structure (37 bytes)=== + +
+| Offset | Size     | Field          | Description                    |
+|--------|----------|----------------|--------------------------------|
+| 0-2    | 3 bytes  | Magic          | 0x4d524b ("MRK" in ASCII)      |
+| 3      | 1 byte   | Version        | Protocol version (0x01)        |
+| 4      | 1 byte   | Type           | Mark type (see below)          |
+| 5-36   | 32 bytes | Reference Hash | SHA256 of the reference        |
+
+ +Visual layout: +
+4d524b   01   01   <32-byte-sha256-hash>
+│││││    │    │    └── Reference hash
+│││││    │    └─────── Type
+│││││    └──────────── Version
+└────────────────────── Magic ("MRK")
+
+ +===Mark Types=== + +
+| Code   | Name       | Reference Format | Description                              |
+|--------|------------|------------------|------------------------------------------|
+| 0x01   | URL        | UTF-8 string     | Web URL (article, video, post)           |
+| 0x02   | Address    | UTF-8 string     | Bitmark address (creator attribution)    |
+| 0x03   | Content    | UTF-8 string     | Content identifier or hash               |
+| 0x04   | Nostr      | UTF-8 string     | Nostr identifier (npub, note, nevent)    |
+| 0x05   | Git Commit | UTF-8 string     | Git commit hash or repo URL              |
+| 0x06   | Document   | Raw bytes        | SHA256 of document (proof of existence)  |
+
+ +===Reference Hash Computation=== + +For types 0x01-0x05, the reference hash is computed as: +
+reference_hash = SHA256(UTF8_ENCODE(reference_string))
+
+ +For type 0x06 (Document), the hash is computed directly from file bytes: +
+reference_hash = SHA256(file_bytes)
+
+ +This enables proof-of-existence without revealing content. + +===Mark Weight=== + +The transaction fee serves as "mark weight"—a measure of commitment to the endorsement. Higher fees indicate stronger signals. + +Recommended minimum: 0.01 BTM + +==Example== + +Marking the URL https://example.com/article: + +
+Reference: "https://example.com/article"
+SHA256:    a1b2c3d4...  (32 bytes)
+
+Mark data (hex):
+4d524b 01 01 a1b2c3d4...
+│      │  │  └── SHA256 of reference
+│      │  └───── Type: 0x01 (URL)
+│      └──────── Version: 0x01
+└─────────────── Magic: "MRK"
+
+Full scriptPubKey:
+6a 25 4d524b0101a1b2c3d4...
+│  │  └── Mark data (37 bytes)
+│  └───── Push opcode (37 = 0x25)
+└──────── OP_RETURN (0x6a)
+
+ +==Verification== + +To verify a mark: + +# Parse the OP_RETURN output +# Verify magic bytes are 0x4d524b ("MRK") +# Check version is supported (0x01) +# Extract type and reference hash +# If original reference is known, verify: SHA256(reference) == reference_hash + +==Reference Storage== + +The blockchain stores only the hash. Original references should be stored off-chain and linked by hash. Implementations may provide: +* POST /reference - Store reference with its hash +* GET /reference/:hash - Retrieve reference by hash + +==Rationale== + +'''Why 37 bytes?''' Compact enough for minimal chain bloat while providing sufficient structure for versioning and type extensibility. + +'''Why hash the reference?''' Fixed-size output regardless of reference length. Privacy for document proofs. Efficient on-chain storage. + +'''Why fee as weight?''' Sybil resistance without introducing new token mechanics. Aligns incentives—marking costs something, making spam expensive and genuine signals valuable. + +==Future Considerations== + +* '''Type extensions''': New reference types via new type codes +* '''Version upgrades''': Breaking changes require version increment +* '''Multi-mark''': Multiple marks in single transaction +* '''Recipient marks''': Type 2 (Address) may include recipient output for direct attribution payments + +==References== + +* Bitcoin OP_RETURN: https://en.bitcoin.it/wiki/OP_RETURN +* SHA-256: FIPS 180-4 + +==Copyright== + +This document is licensed under the MIT License. From 6622e213011ebe2107656c3e4520d87845a3f09d Mon Sep 17 00:00:00 2001 From: Melvin Carvalho Date: Sun, 11 Jan 2026 09:05:39 +0100 Subject: [PATCH 2/4] Add Timestamp type (0x07) for cross-chain OTS attestation --- bip-xx-mrk-protocol.mediawiki | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/bip-xx-mrk-protocol.mediawiki b/bip-xx-mrk-protocol.mediawiki index e4dc65c..0f372f0 100644 --- a/bip-xx-mrk-protocol.mediawiki +++ b/bip-xx-mrk-protocol.mediawiki @@ -74,6 +74,7 @@ Visual layout: | 0x04 | Nostr | UTF-8 string | Nostr identifier (npub, note, nevent) | | 0x05 | Git Commit | UTF-8 string | Git commit hash or repo URL | | 0x06 | Document | Raw bytes | SHA256 of document (proof of existence) | +| 0x07 | Timestamp | Raw bytes | SHA256 of timestamped content (OTS, etc) | ===Reference Hash Computation=== @@ -83,11 +84,13 @@ For types 0x01-0x05, the reference hash is computed as: reference_hash = SHA256(UTF8_ENCODE(reference_string)) -For type 0x06 (Document), the hash is computed directly from file bytes: +For types 0x06 (Document) and 0x07 (Timestamp), the hash is the SHA256 of the content: 
 reference_hash = SHA256(file_bytes)
+Type 0x07 enables cross-chain attestation: the same document hash can be timestamped via OpenTimestamps (Bitcoin) and marked on Bitmark, creating dual-chain proof of existence. + This enables proof-of-existence without revealing content. ===Mark Weight=== From 96987f9e1999e38fad97f1afd934b31ded06bfd1 Mon Sep 17 00:00:00 2001 From: Melvin Carvalho Date: Sun, 11 Jan 2026 09:56:22 +0100 Subject: [PATCH 3/4] Split Nostr into Profile (0x04) and Event (0x08) types - Type 0x04: Nostr Profile - raw 32-byte pubkey (no hashing) - Type 0x08: Nostr Event - raw 32-byte event id (no hashing) Nostr identifiers are already 32 bytes, so they're stored directly without SHA256 hashing unlike URL/Content types. --- bip-xx-mrk-protocol.mediawiki | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/bip-xx-mrk-protocol.mediawiki b/bip-xx-mrk-protocol.mediawiki index 0f372f0..b6717ef 100644 --- a/bip-xx-mrk-protocol.mediawiki +++ b/bip-xx-mrk-protocol.mediawiki @@ -66,32 +66,37 @@ Visual layout: ===Mark Types=== 
-| Code   | Name       | Reference Format | Description                              |
-|--------|------------|------------------|------------------------------------------|
-| 0x01   | URL        | UTF-8 string     | Web URL (article, video, post)           |
-| 0x02   | Address    | UTF-8 string     | Bitmark address (creator attribution)    |
-| 0x03   | Content    | UTF-8 string     | Content identifier or hash               |
-| 0x04   | Nostr      | UTF-8 string     | Nostr identifier (npub, note, nevent)    |
-| 0x05   | Git Commit | UTF-8 string     | Git commit hash or repo URL              |
-| 0x06   | Document   | Raw bytes        | SHA256 of document (proof of existence)  |
-| 0x07   | Timestamp  | Raw bytes        | SHA256 of timestamped content (OTS, etc) |
+| Code   | Name          | Reference Format | Description                              |
+|--------|---------------|------------------|------------------------------------------|
+| 0x01   | URL           | SHA256(UTF-8)    | Web URL (article, video, post)           |
+| 0x02   | Address       | SHA256(UTF-8)    | Bitmark address (creator attribution)    |
+| 0x03   | Content       | SHA256(UTF-8)    | Content identifier or hash               |
+| 0x04   | Nostr Profile | Raw 32 bytes     | Nostr pubkey (hex, not npub)             |
+| 0x05   | Git Commit    | SHA256(UTF-8)    | Git commit hash or repo URL              |
+| 0x06   | Document      | SHA256(bytes)    | Document proof of existence              |
+| 0x07   | Timestamp     | SHA256(bytes)    | Cross-chain timestamp (OTS compatible)   |
+| 0x08   | Nostr Event   | Raw 32 bytes     | Nostr event id (hex, not nevent)         |
===Reference Hash Computation=== -For types 0x01-0x05, the reference hash is computed as: +For types 0x01-0x03 and 0x05, the reference hash is computed as: 
 reference_hash = SHA256(UTF8_ENCODE(reference_string))
-For types 0x06 (Document) and 0x07 (Timestamp), the hash is the SHA256 of the content: +For types 0x06 (Document) and 0x07 (Timestamp), the hash is the SHA256 of the file content: 
 reference_hash = SHA256(file_bytes)
-Type 0x07 enables cross-chain attestation: the same document hash can be timestamped via OpenTimestamps (Bitcoin) and marked on Bitmark, creating dual-chain proof of existence. +For types 0x04 (Nostr Profile) and 0x08 (Nostr Event), the reference hash IS the identifier directly—no hashing required since Nostr pubkeys and event IDs are already 32 bytes: +
+reference_hash = pubkey      // Type 0x04: 32-byte hex pubkey
+reference_hash = event_id    // Type 0x08: 32-byte hex event id
+
-This enables proof-of-existence without revealing content. +Type 0x07 enables cross-chain attestation: the same document hash can be timestamped via OpenTimestamps (Bitcoin) and marked on Bitmark, creating dual-chain proof of existence. ===Mark Weight=== From 591103e7a8aac1631c73a6044daedcb300351df5 Mon Sep 17 00:00:00 2001 From: Melvin Carvalho Date: Sun, 11 Jan 2026 09:59:30 +0100 Subject: [PATCH 4/4] Add URI type (0x09) for linked data identifiers --- bip-xx-mrk-protocol.mediawiki | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bip-xx-mrk-protocol.mediawiki b/bip-xx-mrk-protocol.mediawiki index b6717ef..88e19b3 100644 --- a/bip-xx-mrk-protocol.mediawiki +++ b/bip-xx-mrk-protocol.mediawiki @@ -76,11 +76,12 @@ Visual layout: | 0x06 | Document | SHA256(bytes) | Document proof of existence | | 0x07 | Timestamp | SHA256(bytes) | Cross-chain timestamp (OTS compatible) | | 0x08 | Nostr Event | Raw 32 bytes | Nostr event id (hex, not nevent) | +| 0x09 | URI | SHA256(UTF-8) | Linked data identifier (person, place, thing) | ===Reference Hash Computation=== -For types 0x01-0x03 and 0x05, the reference hash is computed as: +For types 0x01-0x03, 0x05, and 0x09, the reference hash is computed as: 
 reference_hash = SHA256(UTF8_ENCODE(reference_string))