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.

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