diff --git a/docs/alp-token-burn-on-ecash.md b/docs/alp-token-burn-on-ecash.md new file mode 100644 index 0000000..785fb03 --- /dev/null +++ b/docs/alp-token-burn-on-ecash.md @@ -0,0 +1,272 @@ +# Evaluation: ALP for intentional token burn on eCash (temple / White Lotus) + +**Verdict: Yes — ALP is suitable and currently the right token layer for a burn-as-respect product on eCash.** Prefer ALP over legacy SLP. Do not plan on CashTokens (those are BCH-native; eCash would need a hard fork). TBP (Token Burn *Protection*) is a different problem and is largely unnecessary on eCash. + +**Supply policy correction:** A **fixed supply is a poor fit** for Eastern memorial / rebirth symbolism. When every token is burned, offerings cannot continue. Prefer a **perpetual mint baton** so tokens can be **reborn** as new offerings are made. Track **cumulative burned** (merit) separately from **circulating** supply. + +--- + +## 1. Correction: CashTokens vs ALP on eCash + +| Protocol | Chain | Role | +|----------|-------|------| +| **CashTokens** | Bitcoin Cash (BCH) | Consensus-native tokens; **not** available on eCash without a hard fork | +| **SLP / eToken** | eCash (legacy) | OP_RETURN meta-protocol; Chronik-indexed | +| **ALP (Augmented Ledger Protocol)** | eCash | SLP successor (`SLP2` LokadID over **eMPP**); Chronik-indexed; intentional **BURN** supported in `ecash-lib` | + +Earlier guidance that recommended CashTokens for eCash was wrong. For eCash apps, **ALP is the modern token path**. + +Official ALP spec: [bitcoin-abc `doc/standards/alp.md`](https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/doc/standards/alp.md) (also published on ecashbuilders Notion). + +--- + +## 2. What the linked TBP page is (and is not) + +[Token burn protection (TBP)](https://ecashbuilders.notion.site/Token-burn-protection-TBP-protocol-14e9edc6e92f80abbb36ec1ca70adfe9) is about **accidental** burns: non-token wallets spending SLP/ALP UTXOs as plain sats and destroying tokens. + +The same page states: + +> This spec is only intended to be deployed on blockchains where non-token wallets are common. **eCash (XEC) wallets are already very aware of tokens, so this spec is not needed there.** + +So for a temple on eCash: + +- **TBP ≠ intentional offering burn** +- You do **not** need TBP to ship incense/flower burns +- You **do** need intentional burn encoding + indexing (ALP + Chronik + wallet UX) + +--- + +## 3. Does ALP support intentional burns? + +**Yes.** + +1. **Protocol design:** ALP SEND verifies `∑ inputs ≥ ∑ outputs`. Destroying the difference is a burn (same family as SLP). ALP also defines an explicit **BURN** section type (envisioned in the spec; implemented in tooling). +2. **`ecash-lib`:** `alpBurn(tokenId, tokenType, burnAtoms)` builds intentional burn pushdata. +3. **`ecash-wallet` / Cashtab path:** ALP standard tokens support GENESIS / MINT / SEND / **BURN**. ALP can burn an exact amount and keep change in one flow; SLP often needs chained txs for exact intentional burns. +4. **Chronik:** Default token index covers **SLP and ALP**, with safety checks so XEC-only apps do not accidentally spend token UTXOs. + +For a memorial offering, a burn tx can also carry **extra eMPP pushdata** (temple id, person id, offering type) beside the ALP BURN/SEND section — something SLP’s single-OP_RETURN monopoly made awkward. + +--- + +## 4. Fit for “online temple / White Lotus” burns + +| Requirement | ALP fit | +|-------------|---------| +| Intentional, attributable destruction of value | Strong — explicit burn + Chronik history | +| Branded offering token (e.g. White Lotus) | Strong — GENESIS with ticker/name/url/data | +| Regenerative / rebirth supply (never “runs out”) | Strong — keep mint baton(s) alive; ALP allows multiple batons | +| Metadata: who / which temple / flower vs incense | Strong — eMPP multi-section + app OP_RETURN | +| Wallet / indexer support on eCash | Strong — Chronik + Cashtab/`ecash-lib` stack | +| Consensus enforcement like CashTokens | **No** — still indexer rules; trust Chronik + wallet discipline | +| Accidental burn by random XEC wallet | Low risk on eCash (token-aware ecosystem); still educate users | + +**Recommended token policy for offerings (rebirth / regenerative)** + +Do **not** close the mint baton. ALP was explicitly improved over SLP to allow **multiple mint batons** and ongoing `MINT` while a baton input is present ([ALP spec](https://ecashbuilders.notion.site/ALP-a862a4130877448387373b9e6a93dd97)). + +Preferred cycle: + +``` +devotee pays XEC (or holds tokens) + ↓ + ALP MINT (rebirth) — baton stays alive + ↓ + ALP BURN as offering + memorial metadata + ↓ + cumulative burned ↑ circulating can stay small +``` + +Practical variants (pick one trust model): + +| Model | How rebirth works | Trust | Spiritual fit | +|-------|-------------------|-------|----------------| +| **A. Mint-at-offering (recommended v1)** | App/temple holds baton; each offering mints then burns (or mints to user who burns) | Temple/app key | Simple “reborn when remembered” | +| **B. Multi-temple batons** | ALP multi-baton: one baton per temple/region | Each temple | Federated White Lotus network | +| **C. Permissionless PoW remint** | Mist/eminer-style covenant on the baton; anyone remints by work | Rules in script | Strongest “no earthly owner”; harder to build — see §8 | +| **D. Burn-coupled remint** | Policy remints in proportion to recent burns / demand | Policy + baton custody or covenant | Closest to Lotus founder economics | + +Product metrics to show in the temple UI: + +- **Cumulative offerings burned** (never shrinks) — the spiritual ledger +- **Circulating tokens** (can be near zero) — not the point of the ritual +- **Alive mint baton(s)** — proof the flower can bloom again + +**Alternative (even simpler):** burn **native XEC** with OP_RETURN memorial tags (closest to current Lotus Temple XPI burns). Use ALP when you want a **named sacred token** with an explicit rebirth (mint) story. + +--- + +## 5. ALP vs other burn options on eCash + +| Approach | Pros | Cons | +|----------|------|------| +| **ALP intentional burn** | Branded token; exact burn; eMPP metadata; maintained stack | Meta-protocol; need Chronik; mint policy discipline | +| **Legacy SLP burn** | Older ecosystem familiarity | Worse endian/overflow/ghost-output footguns; weaker multi-protocol; exact burns harder | +| **Burn XEC only** | Simplest UX; max liquidity; no token mint politics | No separate “White Lotus” unit; offering is just cash | +| **CashTokens** | Consensus-native | **Not on eCash** without hard fork | +| **New L1 (White Lotus chain)** | Full monetary control | Ops burden; liquidity cold start | + +--- + +## 6. Risks / implementation notes + +1. **Indexer dependency:** Invalid ALP sections are discarded by indexers; consensus still moves the sats. Always build with Chronik validation before broadcast. +2. **Mint baton custody:** An open baton is *required* for rebirth, but whoever holds it can inflate supply. Mitigations: mint-only-at-offering (no free airdrops), rate limits, multi-sig/temple federation, or later a PoW/covenant baton (model C). +3. **OP_RETURN size:** Practical ALP output count is capped (~29 under current policy); fine for burns (usually 0–1 token change outputs). +4. **UX:** Cashtab users can hold/burn ALP; in-app temple wallet should use `ecash-lib` / `ecash-wallet` rather than hand-rolled SLP. +5. **Do not confuse TBP with product burns:** TBP is accidental-burn *prevention* for non-token chains; your product needs intentional burn *expression*. + +--- + +## 7. Bottom line + +**ALP is suitable — and is the best current eCash token protocol — for building intentional token burns for a White Lotus / online temple.** + +Ship path: + +1. Genesis an ALP token **with mint baton(s) kept alive** (rebirth enabled). +2. Offering flow = intentional `BURN` (+ memorial metadata); supply reborn via mint-at-offering **or** PoW remint (§8). +3. Index with Chronik; show **cumulative burned** as the temple’s eternal record. +4. Skip TBP, CashTokens, fixed-supply, and a new L1 unless requirements change. + +--- + +## 8. Feasibility: permissionless PoW remint covenant (model C) + +**Verdict: Feasible.** The pattern is already proven (Mist/eminer on BCH SLP). On eCash it is **somewhat easier** (native introspection, Chronik, `ecash-lib`, Agora already speaks ALP) but still a **non-trivial covenant + miner project**, not a config tweak. + +### 8.1 How it would work + +``` +GENESIS (open mint baton) + → send baton UTXO to PoW covenant P2SH + ↓ +anyone finds nonce: hash(preimage‖nonce) meets difficulty + ↓ +covenant allows spend only if outputs are exactly: + [0] eMPP OP_RETURN with ALP MINT (fixed/rules-based amount) + [1] minted tokens → miner (or temple pool) + [2] baton → next covenant address (state+1, baton never dies) + ↓ +devotees acquire tokens (miner sale / Agora / temple) → BURN as offering +``` + +Spiritual reading: **work recreates the flower; burn offers it; the baton is the eternal root.** + +### 8.2 Why this is realistic on eCash + +| Ingredient | Status | +|------------|--------| +| PoW mint baton covenant | Proven: Mist `slp-miner-reward-v1.spedn` + eminer | +| Enforce tx shape in Script | Proven on BCH; eCash has **native introspection** (cleaner than Mist’s preimage parsing) | +| ALP MINT encoding | Spec + `alpMint()` in `ecash-lib` | +| Indexer | Chronik indexes ALP mint batons / burns | +| ALP + covenant precedent | `ecash-agora` already builds ALP-aware covenant scripts | +| Miner port | Rewrite eminer off BCHD/SLP onto Chronik + `ecash-lib` (moderate effort) | + +ALP’s **multiple mint batons** also help: e.g. one PoW baton (permissionless rebirth) + one temple baton (bootstrap / emergency) without a hard fork. + +### 8.3 Issuance tiers (prefer frequency elasticity over `mint ∝ D`) + +Ergon needs `coins/block ∝ D` because its DAA keeps **blocks/time** ~constant. An ALP remint can keep **coins/remint** fixed and let **remints/time ∝ hashrate** instead — same coins/time elasticity, simpler covenant. + +| Tier | Design | Feasibility | +|------|--------|-------------| +| **Canonical** | Fixed `D`, base `M₀`, Moore `δ=99918/100000` on wall-time, **`N≥2` parallel PoW batons**, no 1-mint/host-block CLTV | **High** — simpler than Mist+full Ergon `mint∝D` | +| **Optional** | Temple bootstrap baton (retire later) | Easy | +| **Usually skip** | Token DAA + `mint ∝ work(D)` | Only if remint-rate design proves insufficient | + +**Moore constant:** use Ergon’s **post-fix** daily factor [`99918/100000`](https://github.com/Ergon-moe/Bitcoin-Static/blob/2e8d5f7635c899cc99e71f06dedbe72b3ff7f07b/src/validation.cpp#L978) (~2.3y half-life). Do **not** use pre-fix `99826/100000` (~1.1y). + +Do **not** copy Mist’s CLTV sync if you want Ergon-like flow: that freezes remints/time ≈ host blocks/time and kills hashrate→issuance elasticity. + +### 8.4 Product flow (PoW ↔ burn) + +Permissionless mint does **not** mint straight into a devotee’s incense burn. Typical loop: + +1. Miner wins remint → receives fresh tokens +2. Liquidity: sell on **Agora** / P2P / temple desk for XEC +3. Devotee burns tokens (or temple burns on their behalf with metadata) + +So the temple app still needs: burn UX, Chronik watchers, and a path to acquire tokens. PoW only replaces **who is allowed to create** supply. + +### 8.5 Main risks + +1. **Baton race:** First valid spend wins (same as Mist); wasted work for losers. Multi-baton mitigates serialization. +2. **Script / ALP byte exactness:** Covenant must match Chronik’s ALP parse exactly or minted tokens look invalid to wallets. +3. **Unaudited Script:** Mist warned its contracts were unaudited; treat White Lotus covenant as security-critical. +4. **Fee + hashrate cold start:** Early miners need XEC for fees; low token demand → low hashrate → slow rebirth (acceptable if temple also keeps a secondary baton). +5. **Economic griefing:** If mint reward ≫ burn demand, circulating dump; tune `D` and `M` (not host-block CLTV pacing). +6. **Moore clock:** decay on eCash time/height, not token mint height. +7. **Not L1 consensus:** Rules live in the covenant + indexer, not eCash consensus (acceptable and normal for ALP). + +### 8.6 Build estimate (engineering shape, not calendar) + +Must build: + +1. CashScript / hand-asm covenant: PoW + ALP MINT eMPP template + baton recursion +2. Genesis + baton handoff tool +3. Chronik-based miner (eminer spiritual successor) +4. Temple burn + cumulative-burn indexer +5. Acquisition path (Agora listing or in-app swap) + +Can defer: `mint ∝ D` DAA, multi-token, mobile miner GPU stack. + +### 8.7 Recommendation + +| Question | Answer | +|----------|--------| +| Is permissionless PoW remint feasible on eCash ALP? | **Yes** | +| Closest prior art | Mist/eminer + eCash Agora/ALP tooling | +| Right covenant economics | Fixed `D` + `M(t)=M₀·(99918/100000)^k` + **`N≥2` parallel batons** + no Mist 1/block CLTV (**not** required `mint ∝ D`) | +| Ship temple before PoW? | **Yes** — mint-at-offering (model A) validates burn UX; swap baton into PoW covenant later | +| Better than forking a White Lotus L1? | **Yes** — same rebirth idea, far less ops | + +### 8.8 Ritual economics: vàng mã and why Ergon-like remint fits + +Vietnamese **vàng mã** (votive paper) is a useful model: people spend real wealth on symbolic offerings and burn them so the act is irreversible. The point is **sacrifice**, not accumulating a scarce collectible. + +| Burn design | What happens to “wealth” | Ritual reading | +|-------------|--------------------------|----------------| +| Fixed-supply token burn | Remaining **holders** get richer (deflation) | Closer to destroying stock to pump bags | +| Custodial remint (temple baton) | Temple can recreate supply | Rebirth works, but an earthly mint owner remains | +| **Ergon-like / PoW remint** | Burn opens room for **new work** to remint; unit tends toward energy/effort cost | Sacrifice dissipates embodied effort; flower can bloom again through labor | + +**Why this is desirable for a communal ritual** + +1. **Purer sacrifice:** Elastic remint dampens the “I burn so my bags moon” loop. Non-burning holders are not the main beneficiaries. +2. **Rebirth without a priest-minter:** Permissionless PoW is the on-chain analogue of “the offering can always return through effort.” +3. **Shared ledger of merit:** Cumulative burns are a public commons (temple memory), even if circulating supply stays elastic. +4. **Optional monetary commons:** In the Lotus-founder two-loop view, burns are a **demand sink** that helps stabilize the unit for *everyone who uses it*—holders and non-holders alike—without oracles. + +**Careful with “energy is infinite ⇒ non-holders benefit”** + +Energy is **not** infinite; if it were free, the sacrifice would be empty. The meaningful claim is closer to: + +- Each burned token represents **effort already spent** (at mint). +- Remint requires **new effort**, so the ritual cycle continually draws real work into the commons. +- Non-holders benefit if the token is a **shared medium** (stable unit, public merit record, temple economy)—not merely because joules are unlimited. + +### 8.9 Lotus `log(D)` vs `sqrt(D)` vs Ergon — and the “scarce community” temptation + +Lotus today pays `R ≈ a·log(D)` (`lotusd` `GetBlockSubsidy`). That is **highly inelastic**: difficulty can rise a lot while issuance barely expands. So ritual burns behave like Bitcoin burns — **holders capture most of the scarcity**. Lotus Temple’s experience matches the math. + +Elasticity of issuance to work (higher = burns refill faster, holders gain less): + +``` +log(D) < sqrt(D) < D¹ (Ergon linear) + Lotus Shammah energy-proportional + proposal +``` + +Shammah’s move toward **sublinear work-coupled** emission (e.g. √-like / `γ ∈ (0,1)` in the 2026 papers) is partly the same concern: make supply answer work and burn demand, not just enrich bags. It is **closer to Ergon than Lotus v1**, but still **less elastic than Ergon** (sublinear by design, for Lyapunov stability / manipulation resistance). + +| Goal | Prefer | +|------|--------| +| Fast speculative community / NGU | Scarcer / `log`-like (Lotus-shaped) | +| Vàng mã sacrifice + rebirth + commons | **Ergon-like `mint ∝ work`** | +| Fork fairness (“energy can’t be counted twice”) | **Ergon-like** (strongest) | + +**Opinion for White Lotus temple:** do **not** choose scarcity to “build community quicker.” That community is mostly holders; you already saw burns serve them more than the wider commons. Build community with **ritual UX, Vietnamese brand, multi-temple, cumulative merit** — and let issuance stay **Ergon-like** so sacrifice stays clean. + +Bootstrap without fake scarcity: slightly higher early PoW mint that still requires work, Agora liquidity, temple-desk acquisition — not a hard cap. diff --git a/docs/ergon-style-issuance-on-ecash.md b/docs/ergon-style-issuance-on-ecash.md new file mode 100644 index 0000000..a62d23a --- /dev/null +++ b/docs/ergon-style-issuance-on-ecash.md @@ -0,0 +1,184 @@ +# Feasibility: Ergon-style (energy-pegged) issuance via eminer/Spedn on eCash + +**Verdict:** A **true Ergon-style elastic, energy-cost-pegged currency on eCash is feasible as a redesigned mineable token**, but **not** by reusing Mist v1 as-is, and **not** as a USD-pegged stablecoin. Pegging mint volume to **eCash chain difficulty** from a covenant is **not possible** without oracles or a consensus hard fork. The closest workable path is an **ALP (or SLP) minting-baton covenant** whose **own** PoW difficulty drives mint amount (Ergon’s proportional-reward idea, applied to the token’s hashrate). + +**Correction:** CashTokens are **BCH-native**, not available on eCash without a hard fork. On eCash use **ALP** (preferred) or legacy SLP/eToken. See also `docs/alp-token-burn-on-ecash.md` for intentional burn suitability. + +--- + +## 1. What each piece actually is + +| Name | Role in this evaluation | +|------|-------------------------| +| **eminer** (`mminer`) | Off-chain miner for Mist/Maze-style **PoW-minted SLP tokens** on BCH, governed by **Spedn** covenants | +| **Spedn / “SPDN”** | BCH Script DSL used to compile mint covenants (`spedn/slp-miner-reward-v*.spedn`). There is **no SPDN currency** in this repo | +| **Mist v1** | Fixed token PoW difficulty + scheduled reward reduction + CLTV sync (~1 mint per host block) | +| **Ergon (XRG)** | Separate PoW chain (`Bitcoin-Static`) where **native coinbase ∝ block difficulty**, with Moore/Koomey decay (~2.3y half-life). Marketed as **stable MoE pegged to mining energy cost**, not a fiat stablecoin | +| **eCash (XEC)** | Host chain; custom assets via **ALP** (preferred) or legacy SLP/eToken — **not** CashTokens (BCH-only). Script/covenants cannot read `nBits`/chain work | + +Ergon’s design goal (from [prop-reward.pdf](https://ergon.moe/prop-reward.pdf)): + +> Block reward shall be a linear function of the current block mining difficulty … peg the price to the expenses of miners … reflecting average cost of electricity … won’t be an investment. + +That is **elastic base money**, not USDT/USDC-style collateralized or oracle-pegged stables. + +--- + +## 2. Why Mist v1 cannot produce Ergon-like stability + +Production contract (`spedn/slp-miner-reward-v1.spedn`): + +1. **Fixed** leading-zero PoW difficulty +2. **Predetermined** mint: `initialMintAmount / (floor(height/interval) + 1)` +3. **CLTV** forces mint pacing ≈ host block rate + +Economic effect: + +- Issuance schedule is **planned**, like Bitcoin/Mist scarcity toward ~21M +- Extra hashrate only races for the **same** fixed reward; it does **not** mint more units +- Unit value is **not** tethered to energy cost; demand shocks move price freely + +Ergon’s feedback loop requires the opposite: + +``` +price ↑ → mining profitable → hashrate ↑ → difficulty ↑ → coins/block ↑ → supply meets demand → price → cost +price ↓ → miners leave → difficulty ↓ → coins/block ↓ → scarcity supports price → cost +``` + +Mist breaks that loop at “hashrate ↑ → coins/block ↑”. + +Experimental `v2` only retunes **token** difficulty from **baton satoshi value** (collateralized difficulty tiers). It still does not implement `mint ∝ difficulty` with a proper DAA. + +--- + +## 3. Can a covenant read eCash difficulty? + +**No.** Native introspection (BCH/eCash) exposes values, locking bytecode, token category/amount/commitment, locktime, etc. It does **not** expose parent header `nBits`, chain work, or network hashrate. + +Therefore: + +| Approach | Feasible without hard fork? | +|----------|-----------------------------| +| Mint amount = f(eCash `nBits`) inside a covenant | **No** (no on-chain signal) | +| Oracle feeds eCash difficulty into the covenant | Technically yes; **destroys** Ergon’s “no oracle” property | +| Hard-fork eCash `GetBlockSubsidy` like Ergon/Lotus | Consensus change; not a token project | +| Mint amount = f(**token’s own** PoW difficulty + DAA) | **Yes** — best token-layer analogue | + +Lotus (`lotusd`) already experiments with **difficulty-based native subsidy** (`enableDifficultyBasedSubsidy`, logarithmic in difficulty). That is related economically but is a **different chain’s base coin**, not an eCash token, and not Ergon’s linear proportional reward. + +--- + +## 4. Workable design: Ergon-like mineable ALP token on eCash + +### 4.1 Core rules (token-layer analogue) + +Treat the minting baton covenant as a mini-Ergon: + +1. **Own PoW** on each mint (hash of preimage ‖ nonce meets current difficulty `D`) +2. **DAA** on `D` targeting a wall-clock mint rate (e.g. N successful mints per day), using timestamps / host locktime carefully +3. **Proportional mint:** `mintAmount = floor(c(t) * work(D))` +4. **Moore decay on `c(t)`** (daily multiplicative factor ≈ Ergon’s `99918/100000` for ~2.3y half-life), stored or derived from mint height +5. **Singleton mint baton** (ALP mint baton; close/burn when fixed supply is desired) + +Then, with DAA holding mint *rate* roughly constant: + +- Higher token hashrate → higher `D` → **more coins per mint** → coins/time ∝ hashrate +- Work per coin stays roughly constant after Moore correction +- Price is pulled toward **marginal energy cost of token PoW** (plus eCash fees) + +That matches Ergon’s *mechanism*, with the important caveat that security of the **ledger** is still XEC miners’ PoW; token miners only pay for **issuance rights**. + +### 4.2 Why ALP > legacy SLP on eCash + +| | Legacy SLP / eToken | ALP on eCash | +|--|---------------------|--------------| +| Encoding | Big-endian, single OP_RETURN | Little-endian, **eMPP** multi-section | +| Intentional burn | Possible; exact burns often awkward | First-class `alpBurn` in `ecash-lib` | +| Indexing | Chronik | Chronik (default token index) | +| CashTokens | N/A on eCash | N/A on eCash (BCH-only) | + +Recommend **ALP + Chronik + ecash-lib** on eCash. Use eminer only as a **reference** for PoW-mint UX if pursuing Ergon-like issuance—not as a drop-in deploy. For temple burns, see `docs/alp-token-burn-on-ecash.md`. + +### 4.3 Critical design choices vs Mist + +| Mist v1 | Needed for Ergon-like token | +|---------|-----------------------------| +| Fixed difficulty | Adjustable `D` in NFT commitment / redeem state | +| Reward from height schedule only | `mint ∝ D` (+ Moore factor) | +| CLTV ≈ 1 mint / host block | **Do not** hard-cap mint rate independent of hashrate; use DAA instead (CLTV may still bound abuse) | +| Race wastes excess work with no issuance effect | Excess work raises future `D` / issuance | + +Without removing the “fixed reward per host block” pattern, the energy peg **cannot** form. + +### 4.4 What this is *not* + +- **Not a USD stablecoin.** Equilibrium is ~energy (and hardware) cost per unit, which moves with electricity markets and ASIC efficiency estimation error. +- **Not soft-pegged to XEC.** XEC remains scarce/deflationary base; the token is a second asset. +- **Not “stable” in the CeFi sense.** Expect oscillations; Ergon’s paper relies on speculative damping and miner mobility across SHA-256d coins. A low-liquidity token will be noisier than Ergon mainnet. +- **Not secured by token hashrate.** Double-spend safety is still eCash consensus; token PoW only governs mint fairness. + +--- + +## 5. Alternative paths (ranked) + +### A. Token-layer Ergon analogue (recommended research path) + +- **Scope:** New ALP token + minting covenant + miner (Chronik / `ecash-lib`) +- **Pros:** No eCash hard fork; permissionless; closest to “stablecoin possible” in Ergon’s meaning +- **Cons:** Bootstrap hashrate/liquidity; DAA and Moore params are hard; SLP eminer not reusable as-is +- **Invasiveness:** New contracts + miner; optional Lixi/Local-eCash listing later + +### B. Oracle-linked mint to eCash difficulty + +- **Pros:** Couples issuance to host-chain work +- **Cons:** Trusted/federated oracle; fails Ergon’s no-oracle thesis; attack surface + +### C. eCash consensus change (native proportional subsidy) + +- **Pros:** Cleanest Ergon clone for base money +- **Cons:** Social/consensus cost; changes XEC economics for everyone; out of scope for eminer + +### D. Keep Mist schedule, call it “stable” + +- **Pros:** Already built +- **Cons:** Economically false; fixed emission ≠ energy peg + +### E. Fiat-backed or overcollateralized USD stable on eCash + +- Separate product (custody, legal, oracles, liquidations), likely ALP or custodial. eminer/Ergon issuance theory does not deliver this. + +--- + +## 6. Risks and open problems + +1. **DAA design** under baton races, selfish minting, and timestamp manipulation +2. **Moore parameter error** → long-run inflation or deflation vs energy (Ergon’s own caveat) +3. **Fee drag:** every mint pays XEC fees; at low token price, issuance stalls even when “should” expand +4. **Hash algorithm:** token PoW is typically sha256d of preimage+nonce (CPU/GPU), while Ergon assumes ASIC SHA-256d mobility vs Bitcoin—elastic response `α` may be weaker +5. **Early unfairness:** fixed early `D` can still over-mint before DAA warms up; need genesis difficulty and maybe dampened early `c(t)` +6. **Regulatory / naming:** “stablecoin” implies fiat peg to many users; prefer “energy-elastic cash” / “Ergon-style token” in product language +7. **SLP on eCash** is legacy; building on SLP today is a dead-end for new issuance + +--- + +## 7. Suggested next steps (if pursuing) + +1. Specify covenant rules: state layout (height, `D`, last-mtime), mint formula, DAA, Moore factor, baton conservation +2. Prototype ALP mint baton + PoW covenant on chipnet; property-test mint amounts vs `D` +3. Minimal miner: solve PoW, submit mint, track baton UTXO via Chronik +4. Parameter study: target mint interval, `c(0)`, decay τ, min/max `D` +5. Explicitly **non-goals** for v1: USD peg, XEC peg, cross-chain bridges + +--- + +## 8. Bottom line + +| Question | Answer | +|----------|--------| +| Can eminer/Spedn launch an Ergon-**like** currency on eCash? | **Yes, with a new covenant design** (proportional mint to **token** difficulty + DAA + Moore decay), preferably as **ALP** | +| Can Mist v1 parameters alone do it? | **No** — fixed difficulty + scheduled emission is anti-Ergon | +| Can mint track **eCash** difficulty trustlessly? | **No** from script alone | +| Does that yield a **USD stablecoin**? | **No** — at best an **energy-cost-elastic** unit of account | +| Is a fiat stablecoin “possible” on eCash? | Yes via **other** designs (reserves/collateral/oracles), unrelated to Ergon/eminer | + +**Most honest framing:** use eminer as prior art for **decentralized PoW mint batons**, then implement Ergon’s proportional-reward economics as an **ALP** token on eCash so a **stable (energy-pegged) medium of exchange** can be attempted—not a dollar stablecoin, and not a config tweak of Mist. diff --git a/docs/white-lotus-proposal.md b/docs/white-lotus-proposal.md new file mode 100644 index 0000000..098e1fb --- /dev/null +++ b/docs/white-lotus-proposal.md @@ -0,0 +1,194 @@ +# Proposal: White Lotus — Ergon-like ritual coin + +**Recommendation: build White Lotus as an Ergon-like ALP token on eCash first. Do not launch an L1 unless the token proves ritual demand and outgrows eCash rails.** + +--- + +## 1. Decision + +| Option | Role | +|--------|------| +| **A. White Lotus on eCash (ALP + PoW remint)** | **Primary — ship this** | +| **B. White Lotus L1 (eCash/Ergon-style fork)** | Contingency only — after product-market fit | + +Ritual need (vàng mã sacrifice + rebirth + commons) is satisfied by **issuance rules**, not by owning a blockchain. eCash already gives maintenance, Chronik, wallets, and Agora. An L1 buys fork-fairness and sovereign monetary policy at the cost of becoming a chain operator. + +--- + +## 2. Why A over B (now) + +| Criterion | ALP on eCash | New L1 | +|-----------|--------------|--------| +| Work-elastic issuance | Yes — remint *frequency* ∝ hashrate (+ Moore) | Yes — `GetBlockSubsidy ∝ difficulty` (+ Moore) | +| Vàng mã burn + rebirth | Yes — burn + perpetual baton(s) | Yes — native burn + subsidy | +| Holder-capture vs Lotus `log(D)` | Avoided (issuance answers work) | Avoided if subsidy ∝ `D` | +| Ops burden | App + covenant + miner | Full node, miners, explorers, upgrades forever | +| User acquisition of offering | XEC → Agora/desk → burn | Need exchange/liquidity for new coin | +| Maintenance of base chain | Bitcoin ABC / eCash | You | +| Fork-energy fairness | Soft (token PoW) | Strong (L1 work) | +| Time to a working temple | Much shorter | Much longer | + +Lotus Temple already showed: **elastic but inelastic issuance (`log D`) + burns** enriched holders. Fix issuance, don’t fork a nation-state chain on day one. + +--- + +## 3. Product architecture (Option A) + +### 3.1 Narrative + +- **White Lotus (hoa sen trắng)** — Vietnamese mourning / purity symbol +- Cycle: *effort remints the flower → devotee burns it → merit is public → flower can bloom again* +- Cumulative burned = spiritual ledger; circulating supply is secondary + +### 3.2 Token + +| Item | Choice | +|------|--------| +| Host | eCash (XEC) | +| Protocol | **ALP** (`SLP2` / eMPP) | +| Ticker (example) | `WLOTUS` / `WLTS` | +| Mint authority | **Permissionless PoW covenants** on **multiple** mint batons | +| Burn | Intentional `alpBurn` + memorial metadata (person / temple / offering tier) | +| Indexer | Chronik | +| Liquidity | Agora + optional temple desk (XEC ↔ token) | + +### 3.3 Issuance — remint frequency + Moore decay + +**Insight:** On Ergon, block *rate* is held ~constant by the DAA, so elasticity lives in **coins per block** (`∝ D`). On an ALP PoW remint, invert that: + +- Fixed PoW difficulty; base atoms per remint before Moore +- **Many remints per eCash block** (no Mist “1 mint / host block” CLTV) +- **Multiple ALP mint batons** for **true parallel** remints (§3.5) +- ⇒ **remints/time ∝ hashrate** ⇒ **coins/time ∝ hashrate** + +``` +coins/time ≈ N_batons × (hashrate_per_baton / hashes_per_solution) × M(t) +``` + +No token DAA and no `mintAmount ∝ work(D)` required for Ergon-like *flow*. + +#### Moore / Koomey — Ergon **post-launch** constant only + +Ergon’s daily correction in [`validation.cpp` (GetBlockSubsidy)](https://github.com/Ergon-moe/Bitcoin-Static/blob/2e8d5f7635c899cc99e71f06dedbe72b3ff7f07b/src/validation.cpp#L978): + +```cpp +// Pre-EMA (obsolete ~1.1y half-life) — DO NOT USE FOR WLOTUS +aWork *= 99826; aWork /= 100000; + +// Post-EMA / corrected (~2.3y half-life) — USE THIS +aWork *= 99918; aWork /= 100000; +``` + +Bitcoin Static release notes fixed Moore from **1.1y → 2.3y**. **WLOTUS ships `δ = 99918/100000` from genesis** — never the old `99826` factor. + +| Symbol | WLOTUS | Notes | +|--------|--------|-------| +| `δ` | **`99918 / 100000`** | Ergon corrected daily factor | +| Day step | ~1 wall day | Ergon: once per `nSubsidyHalvingInterval` (144 × 10‑min blocks). Mirror with ~144 eCash blocks or median-time day | +| `M(t)` | `M₀ · δ^{k}` | `k = floor(elapsed_days)` since genesis | +| Clock | **eCash height / median time** | **Not** token-mint height (that races with hashrate) | + +Covenant integer form: + +``` +M_expected = M₀ +repeat k times: + M_expected = (M_expected * 99918) / 100000 +verify mintAtoms == M_expected +``` + +#### Canonical knobs + +| Knob | Setting | Role | +|------|---------|------| +| PoW difficulty `D` | Fixed, tunable | Effort per remint solution | +| Base atoms `M₀` | Genesis constant | Initial unlock per solution | +| Moore `δ` | **`99918/100000`** | ~2.3y half-life efficiency decay | +| Host CLTV 1-mint/block | **Off** | Keep hashrate → issuance elasticity | +| Supply cap | **None** | Batons never die | +| PoW baton count `N` | **`N ≥ 2` at genesis** | True parallel remints (§3.5) | + +**Skip unless needed later:** token-local DAA; `mintAmount ∝ work(D)`. + +Tune `D` / `M₀` / `N` from burn demand and miner contention. Each remint pays XEC fees (anti-spam). + +### 3.4 App flow + +``` +Devotee opens memorial page + → acquires WLOTUS (Agora / desk / gifted) + → chooses offering (flower / incense / candle = burn tiers) + → alpBurn + eMPP memorial payload + → Chronik + API update cumulative merit + +Parallel: + Miners race across N PoW batons → remint → sell / provide liquidity +``` + +Reuse `app-lotus-temple` UX; retarget settlement from XPI burns to ALP burns on eCash. + +### 3.5 Multiple mint batons (first-class parallelization) + +ALP allows **many mint batons** (SLP allowed only one). White Lotus treats multi-baton as **core design**. + +**A. PoW baton set (canonical issuance)** + +- Genesis creates **`N ≥ 2` identical PoW covenant batons** (independent tips, same rules). +- Miners remint **in parallel** in the same eCash block — not merely a serial chain on one tip. +- Each successful spend: PoW OK → mint exactly `M(t)` → **return one baton** to the next covenant state (**conserve `N`**). +- Choose `N` at genesis (e.g. 4–16); change only via a deliberate migration if ever required. + +This is how “multiple mints per block” becomes **true parallelization** and matches frequency-elasticity in §3.3. A single baton alone still serializes and wastes work under load. + +**B. Optional temple baton (bootstrap only)** + +- Separate rate-limited / multi-sig baton for cold-start or emergency. +- Prefer destroying it once PoW batons + Agora liquidity exist. + +**Invariant:** PoW batons are never burned; temple baton may be retired. + +--- + +## 4. Option B — L1 (when, and only when) + +Consider a White Lotus / Ergon-like L1 **only if**: + +1. Temple has sustained burn volume and cultural adoption +2. eCash fee / policy / tooling constraints block the ritual +3. You accept permanent chain ops (or a funded commons to run them) +4. You want hard fork-fairness (“energy can’t be counted twice”) as a first-class property + +Then: fork a maintained UTXO codebase, set work-elastic subsidy + **`δ = 99918/100000` Moore**, **0% founder fund**, fee burn optional. Port the temple app to native burns. + +Until then, L1 is premature optimization of sovereignty. + +--- + +## 5. Phased delivery (Option A) + +| Phase | Deliverable | +|-------|-------------| +| **0** | Spec: covenant rules, `M(t)` with `δ=99918/100000`, burn LOKAD, **`N` baton policy** | +| **1** | GENESIS (`N` PoW batons) + Chronik + temple burn UI (custodial remint OK to dogfood) | +| **2** | PoW remint covenant + miner (fixed `D`, Moore on wall-time, **multi-baton parallel**, no 1-mint/block CLTV) | +| **3** | Agora market + public cumulative-burn explorer | +| **4** | Retune `D` / `M₀` / `N` from burn & hashrate data | +| **5** | Revisit L1 only with evidence from 1–4 | + +--- + +## 6. Explicit non-goals (v1) + +- USD stablecoin +- Fixed max supply +- Lotus-style `log(D)` inelastic subsidy +- Ergon’s obsolete Moore factor `99826/100000` +- Mist-style 1-mint-per-host-block CLTV +- Launching a new L1 to “build community faster” +- Relying on TBP (not needed on eCash) + +--- + +## 7. One-line decision + +**White Lotus = ALP on eCash with parallel PoW remint batons, fixed `D`, Moore `δ=99918/100000`, and burn-as-vàng-mã. L1 only after the ritual works.**