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)
FROM: 1A1zP1... (Address)
TO: 1BvBM... (Burn Address)
AMOUNT: 10.0 Coins
Grin (Mimblewimble)
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: 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
- 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).
- Create a burn output `C_burn = r_burn·G + V_burn·H`. This output is unspendable because its key `r_burn` is unknowable.
- Publish an off-chain "proof-of-burn" message containing `(C_burn, V_burn)`.
- Anyone can verify that `C_burn - (V_burn·H)` equals the public `r_burn·G`, confirming the burned amount.
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).
Method 2: Scriptless Script Lock
This method uses advanced cryptography (adaptor signatures) to lock funds in a contract with impossible-to-meet conditions. While cryptographically elegant, it's not practical for this purpose.
How it Works
A user would create an output locked in a multi-signature contract. To spend it, a secret `t` must be revealed. This secret `t` is tied to solving an impossible problem (like finding the discrete log of H). The funds are thus permanently locked.
Analysis
- ✓ Permanent: Yes, if designed correctly.
- ✗ Verifiable: Poorly. Requires publishing and understanding a very complex off-chain proof. The on-chain transaction is indistinguishable, which is the opposite of the goal.
- ~ Protocol Impact: Minimal. Adds one permanent UTXO.
- ✗ Complexity: High. A massive engineering effort for little benefit.
Method 3: Kernel Timelock
This method uses a built-in feature to lock a transaction until a future block height. It is unsuitable for a true, permanent burn.
How it Works
A user creates a transaction sending coins to themselves, but sets the `lock_height` on the transaction kernel to a block number 100+ years in the future. The transaction is invalid until that block is mined.
Analysis
- ✗ Permanent: No. The coins become spendable once the lock expires.
- ~ Verifiable: The lock itself is visible, but it doesn't verify a burn.
- ✗ Protocol Impact: Negative. Causes long-term UTXO bloat, which harms Grin's scalability.
- ✓ Complexity: Low. Uses an existing feature.
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.
Pre-RFC Discussion
Propose the idea on the Grin forum to gather community feedback.
Draft RFC
Create a formal document detailing the technical specification.
Community Review
The community debates and refines the proposal for robustness.
Adoption
Once accepted, wallets and services can implement the standard.