From 4f4c8a46eabd934033433450c90160b74cd73f32 Mon Sep 17 00:00:00 2001 From: jwinterm Date: Fri, 4 Sep 2026 09:57:32 -0400 Subject: [PATCH] chore: adopt grinburn.html, which existed only on the server An interactive explainer on verifiably burning Grin has been served from wownero.org for some time and was never committed. It is untracked on the box, so nothing outside that filesystem knew it existed and a rebuild of the host would have taken it with no trace. Self-contained: no local assets, and nothing on the site links to it, so it is reachable only by its URL. Committing it as served, without editing it; whether it should be linked from the wallets or resources sections is a separate question. Claude-Session: https://claude.ai/code/session_0163TepHAxDp8WQe7hyoTPi3 --- grinburn.html | 510 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 510 insertions(+) create mode 100644 grinburn.html diff --git a/grinburn.html b/grinburn.html new file mode 100644 index 0000000..cc767e3 --- /dev/null +++ b/grinburn.html @@ -0,0 +1,510 @@ + + + + + + Interactive Explainer: Verifiable Grin Coin Burning + + + + + + + + + + + + + + + +
+ +
+ +
+
+
+

Verifiably Burning Grin

+

How do you prove something was destroyed in a system designed for privacy? This interactive report explores the technical and cryptographic challenges of coin burning in Grin.

+
+
+ +
+
+
+

The Privacy vs. Verifiability Dilemma

+

+ Coin burning requires public proof that coins are permanently unspendable. Grin's core features—confidential amounts and no addresses—make this uniquely difficult. A burn event must be a deliberate, verifiable exception in a system where all other transactions are designed to be indistinguishable and private. +

+
+
+
+

Typical Blockchain (e.g., Bitcoin)

+
Amounts and addresses are public.
+
+
🔍 On-Chain Data
+
+

FROM: 1A1zP1... (Address)

+

TO: 1BvBM... (Burn Address)

+

AMOUNT: 10.0 Coins

+
+
+
Verification is simple: the amount sent to the public burn address is visible to all.
+
+
+

Grin (Mimblewimble)

+
No addresses, amounts are confidential.
+
+
🤫 On-Chain Data
+
+
IN
+
→
+
OUT
+
+
+
Verification is hard: how do you prove the amount in the "OUT" commitment is burned if it's hidden?
+
+
+
+
+ +
+
+
+

Grin's Cryptographic Core

+

To understand the solution, we must first understand the building blocks of a Grin transaction.

+
+
+
+

1. Pedersen Commitments: The "Black Box" Output

+

Every Grin output is a cryptographic commitment, not a plain number. It hides the value while binding the creator to it.

+
C = r·G + v·H
+
    +
  • C: The commitment (public on-chain data).
    • +
  • r: The blinding factor (a secret private key). Knowledge of 'r' proves ownership.
    • +
  • v: The value or amount (a secret).
    • +
  • G, H: Elliptic curve generator points.
    • +
+

To "burn" Grin, we must create a commitment `C` where its private key `r` is verifiably destroyed or unknowable.

+
+
+

2. Transaction Integrity: The Zero-Sum Game

+

While values are hidden, the protocol ensures no coins are created from thin air by checking that `Σ(inputs) = Σ(outputs)`. This is done with clever math on the commitments.

+
+

Σ(Output Commitments) - Σ(Input Commitments) =

+

Σ(r_out·G + v_out·H) - Σ(r_in·G + v_in·H) =

+

(Σr_out - Σr_in)·G + (Σv_out - Σv_in)·H

+
+

For a valid transaction, `Σv_out - Σv_in` must be 0. This makes the `H` term cancel out. The transaction is then signed with the excess blinding factor `k = (Σr_out - Σr_in)`, proving everything balanced without revealing amounts.

+
+
+
+
+ +
+
+
+

Exploring Potential Burn Mechanisms

+

Three methods were analyzed. Click the tabs to learn about each one and use the buttons to compare them visually.

+
+ +
+
+ +
+
+
+

Method 1: Blackhole Commitment (Recommended)

+

This method creates a provably unspendable output by using a public, standardized "destroyed" private key. It's the most robust and practical approach.

+
+
+

How it Works

+
    +
  1. Define a public constant key `r_burn` by hashing a string like `"grin-burn-commitment-v1"`. Since the hash function is one-way, no one knows the pre-image (the true private key).
    2. +
  2. Create a burn output `C_burn = r_burn·G + V_burn·H`. This output is unspendable because its key `r_burn` is unknowable.
    3. +
  3. Publish an off-chain "proof-of-burn" message containing `(C_burn, V_burn)`.
    4. +
  4. Anyone can verify that `C_burn - (V_burn·H)` equals the public `r_burn·G`, confirming the burned amount.
    5. +
+
+
+

Analysis

+
    +
  • ✓ Permanent: Yes. The key is cryptographically destroyed.
    • +
  • ✓ Verifiable: Yes, via a simple off-chain proof.
    • +
  • ~ Protocol Impact: Minimal. Adds one permanent UTXO.
    • +
  • ~ Complexity: Low-to-Medium. Needs a community standard (RFC).
    • +
+
+
+
+ + +
+
+ +
+

Interactive Comparison

+

Click a criterion to see how the methods stack up.

+
+ + + + +
+
+ +
+
+ +
+
+ +
+
+
+

The Recommended Path Forward

+

The "Blackhole Commitment" is the clear winner. Here's an interactive look at how it works and how it could be implemented.

+
+ +
+

Burn Simulator: The Blackhole Method

+

See the process step-by-step. Enter an amount and follow the flow.

+ +
+ + + +
+ +
+ +
+
+ +
+

Path to Implementation: The Grin RFC Process

+

A burn mechanism is only useful if everyone agrees on it. The formal Request for Comments (RFC) process is essential for standardizing the "Blackhole" method.

+
+
+
1
+

Pre-RFC Discussion

+

Propose the idea on the Grin forum to gather community feedback.

+
+
+
2
+

Draft RFC

+

Create a formal document detailing the technical specification.

+
+
+
3
+

Community Review

+

The community debates and refines the proposal for robustness.

+
+
+
4
+

Adoption

+

Once accepted, wallets and services can implement the standard.

+
+
+
+
+
+ +
+ + + + + + + +