diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/MONZERO_ASSETS_V1_SPEC.md | 286 | ||||
| -rw-r--r-- | docs/MONZERO_ASSET_CRYPTO_REVIEW_BRIEF.md | 133 | ||||
| -rw-r--r-- | docs/MONZERO_PHASE0_BASELINE_20260815.md | 196 | ||||
| -rw-r--r-- | docs/MONZERO_PHASE0_STABILIZATION.md | 139 | ||||
| -rw-r--r-- | docs/RELEASE_CHECKLIST.md | 178 |
5 files changed, 864 insertions, 68 deletions
diff --git a/docs/MONZERO_ASSETS_V1_SPEC.md b/docs/MONZERO_ASSETS_V1_SPEC.md new file mode 100644 index 000000000..0da86ae83 --- /dev/null +++ b/docs/MONZERO_ASSETS_V1_SPEC.md @@ -0,0 +1,286 @@ +# Monzero Assets V1 product and privacy specification + +Status: early draft; not a consensus specification +Native coin: XMZ +Proposed feature: fixed-function private assets + +This document records product decisions and unresolved research questions. It +does not authorize mainnet implementation or claim that the proposed +cryptographic construction is safe. + +## 1. Objective + +Allow users to create publicly identifiable, fixed-supply assets whose owners, +recipients, balances, and transfer amounts receive privacy protections from the +Monzero protocol. + +XMZ remains the only native coin used for network fees, asset-creation fees, +mining rewards, and consensus security. + +## 2. V1 scope + +V1 is limited to: + +- issue a fixed-supply asset; +- transfer an issued asset; +- burn an issued asset; +- scan, restore, and display asset balances; +- voluntary disclosure through explicitly designed view functionality; and +- off-chain metadata committed by an on-chain hash. + +V1 deliberately excludes: + +- reissuable supply or retained mint authority; +- arbitrary smart contracts; +- transfer taxes, freezes, blacklists, clawbacks, or pausing; +- native automated market makers or order books; +- cross-chain bridges; +- wrapped assets; +- on-chain images or executable metadata; and +- claims that low-activity assets have the same practical anonymity as XMZ. + +Fixed supply is mandatory in V1 because it removes an authority lifecycle and +substantially reduces supply-validation and wallet-warning complexity. + +## 3. Privacy contract + +| Property | V1 policy | +| --- | --- | +| Asset identifier | Public | +| Issuance transaction | Public | +| Initial and maximum supply | Publicly verifiable policy | +| Supply mutability | Fixed; no reissuance | +| Sender | Private under the reviewed transaction model | +| Recipient | Private under the reviewed transaction model | +| Individual balance | Confidential | +| Transfer amount | Confidential | +| Asset activity | Observable at asset level | +| Metadata | Public and untrusted | + +The exact meaning of “private” must be replaced by testable cryptographic and +traffic-analysis claims before implementation. A thin asset with few outputs +may have a much weaker practical anonymity set than XMZ. + +## 4. Asset identity + +- Every asset has a cryptographic asset ID. +- Names, symbols, logos, and websites are never identifiers. +- Duplicate names and symbols are permitted. +- Wallets must show a shortened asset ID anywhere confusion is possible and + provide the complete ID on demand. +- The asset-ID derivation domain must include the Monzero mainnet identity and + an issuance-specific commitment. + +The exact derivation remains a cryptographic design item. It must avoid circular +transaction-hash definitions, collisions, cross-network replay, and malleability. + +### 4.1 Inactive descriptor prototype + +The source tree contains a research-only issuance descriptor and asset-ID +derivation in `src/cryptonote_basic/asset_types.*`. It is deliberately absent +from transaction serialization, the mempool, blocks, RPC, and wallets. Public +nodes therefore continue to reject every transaction version above v2 and +cannot issue or transfer assets. + +The provisional V2 canonical byte sequence is: + +1. ASCII domain `MonzeroAssetIssuanceV2` without a terminator; +2. one-byte descriptor version; +3. 16 raw network-UUID bytes; +4. one-byte asset class; +5. 32-byte issuer public key; +6. 32-byte issuance nonce; +7. eight-byte unsigned atomic supply, little-endian; +8. one-byte display precision; +9. 32-byte metadata content hash; +10. 32-byte collection asset ID, or the zero hash; +11. two-byte metadata-reference length, little-endian; and +12. the metadata-reference bytes. + +The provisional asset ID is `cn_fast_hash(canonical_descriptor)`. Version 2 +requires a valid issuer public key, a public Monzero network, non-zero supply, +display precision from 0 through 11, no NUL in the metadata reference, and a +maximum metadata-reference length of 256 bytes. Consensus assigns no meaning +to the reference contents. + +The asset classes and their additional rules are: + +| Class | Supply | Decimals | Collection reference | +| --- | ---: | ---: | --- | +| Fungible | Greater than zero | 0–11 | Forbidden | +| Non-fungible | Exactly 1 | 0 | Optional | +| Collection | Exactly 1 | 0 | Forbidden | +| Edition | Greater than zero | 0 | Optional | + +An NFT or edition must commit to a non-zero metadata content hash. A collection +reference alone does not prove legitimate membership. The inactive prototype +therefore defines two domain-separated authorization messages: + +- `MonzeroAssetIssuanceAuthorizationV1 || canonical_descriptor`, signed by the + issuer key committed in the descriptor; and +- `MonzeroCollectionMembershipV1 || collection_id || member_asset_id`, signed + by the collection controller. + +The implementation verifies both signatures and rejects altered descriptors, +member IDs, invalid keys, and zero IDs. The future transaction and database +design must still define how a collection controller is resolved from its +on-chain issuance, whether it can rotate, and how it is permanently closed. +Until that complete path exists, wallets must not display a collection as +verified. + +### 4.2 Inactive registry and reorganisation model + +The prototype includes an in-memory reference registry, disconnected from the +blockchain database. An issuance is inserted only after its canonical ID and +issuer signature validate. A claimed collection must already exist on the same +network, have the collection class, precede the member issuance, and authorize +the exact member asset ID. Duplicate IDs and unexpected membership signatures +are rejected. + +The registry records issuance height and deterministically removes every asset +issued at or above a detached height. Tests demonstrate removal and subsequent +valid reissuance after a simulated reorganisation. This is an executable state +model, not the final database schema or consensus integration. + +This encoding is a stable prototype vector for review, not an activation +decision. A cryptographic review may replace the hash construction or fields; +doing so must deliberately update the golden vector before any testnet fork. + +## 5. Issuance policy + +An issuance declares: + +- asset ID construction data; +- atomic supply; +- decimal display precision; +- metadata content hash; +- metadata URI; +- protocol version; and +- an XMZ creation fee. + +Issuance creates the complete lifetime supply. No key or authority can create +additional units after confirmation. + +Limits requiring research include maximum atomic supply, decimal range, +metadata URI length, transaction size, and creation-fee amount. + +## 6. Transfers and burns + +Nodes must reject a transaction unless it proves, for each asset independently, +that valid inputs equal valid outputs plus an explicitly burned amount. + +XMZ fees form a separate balance domain and may never be paid with an issued +asset. An asset transaction therefore needs sufficient XMZ inputs without +allowing the asset proof to create, destroy, or transform XMZ accidentally. + +A burn is permanent and must be distinguishable from an ordinary confidential +output without revealing unrelated private amounts. + +### 6.1 Inactive transparent conservation model + +`asset_types.*` also contains a test-only, transparent balance statement. It +exists to make the intended accounting rules executable before any +confidential commitment or proof system is selected. It is not serialized, +accepted by the mempool, exposed over RPC, or usable by a wallet. + +The validator currently enforces these semantic invariants: + +- XMZ inputs equal XMZ outputs plus an XMZ-denominated fee; +- issuance creates exactly the descriptor's complete fixed supply; +- an asset ID may be issued only once; +- every non-issuance asset ID must already be known; +- each asset balances independently as inputs equal outputs plus explicit + burns, preventing conversion between asset IDs; +- zero IDs, zero-valued entries, and empty statements are noncanonical; and +- all aggregation and output-plus-fee calculations reject integer overflow. + +These checks do not provide confidentiality, ownership authorization, range +proofs, double-spend protection, or a consensus transaction format. Those +properties remain prerequisites for an isolated prototype network. The +transparent statement must never be mistaken for a production transaction +design. + +## 7. Metadata + +Consensus stores only bounded identity and commitment fields. Descriptions, +logos, project links, and social information remain off-chain. + +Consensus must never depend on a registry, gateway, domain, image host, or +website. Wallets must treat all metadata as untrusted input and enforce content +type, size, rendering, and scripting restrictions. + +A registry may label an asset as verified, but verification must be visibly +different from endorsement. + +## 8. Wallet requirements + +- Discover every supported asset during normal scanning. +- Restore all XMZ and asset balances from documented recovery material. +- Display asset ID, fixed-supply status, and metadata verification state. +- Prevent name, symbol, decimal, and logo spoofing from obscuring the asset ID. +- Build transactions that balance XMZ fees and asset values independently. +- Explain thin-asset anonymity limitations before first use. +- Support opt-in disclosure without silently broadening an existing view key. +- Refuse unknown asset transaction versions safely. + +Hardware wallets are unsupported until their transaction review and signing +flows explicitly understand asset IDs, supply, fees, and burns. + +## 9. Required cryptographic research + +An external review must cover: + +- per-asset commitment construction; +- prevention of cross-asset inflation; +- issuance and burn proofs; +- interaction with RingCT and existing output types; +- ring-member compatibility and selection; +- thin-asset anonymity sets; +- range proofs and balance proofs; +- XMZ fee separation; +- transaction malleability; +- scanning cost and false positives; +- verification time and transaction size; and +- malformed or adversarial asset transactions. + +Public asset IDs with confidential amounts are the preferred V1 research path. +Confidential asset IDs are deferred to a possible later protocol version. + +## 10. Activation policy + +Asset rules require a versioned hard fork after: + +1. completion of the Phase 0 stabilization gates; +2. publication of a complete binary consensus specification; +3. independent cryptographic and implementation review; +4. an isolated prototype network; +5. automated inflation and reorganisation tests; +6. an extended public testnet; +7. resolution of audit findings; and +8. advance coordination with node, miner, wallet, and service operators. + +Unknown asset transaction versions must be rejected. Mainnet must not contain a +privileged rollback, administrator mint, or emergency asset-editing key. + +## 11. Deferred systems + +Launchpad, trading, and bridging are separate projects. Their existence is not +required for consensus-level asset ownership or transfer. + +If a bridge is later considered, its first scope should be XMZ to wrapped XMZ, +with explicit custody assumptions, strict caps, independent audits, reserve +monitoring, and warnings that transparent-chain activity can correlate users. + +## 12. Open decisions + +- Formal asset-ID derivation +- Commitment and proof construction +- Decoy eligibility and ring selection +- Maximum supply and decimal constraints +- Asset-creation fee and anti-spam policy +- Burn representation and supply reporting +- Asset-specific disclosure design +- Transaction weight limits +- Database schema and migration plan +- Reorganisation semantics for metadata indexes +- Testnet identifiers and activation schedule diff --git a/docs/MONZERO_ASSET_CRYPTO_REVIEW_BRIEF.md b/docs/MONZERO_ASSET_CRYPTO_REVIEW_BRIEF.md new file mode 100644 index 000000000..cf625635c --- /dev/null +++ b/docs/MONZERO_ASSET_CRYPTO_REVIEW_BRIEF.md @@ -0,0 +1,133 @@ +# Monzero Assets V1 cryptographic review brief + +Status: pre-implementation review input +Network activation: none +Native coin: XMZ +Descriptor prototype: version 2 + +## Review objective + +Determine whether Monzero can safely support fixed-supply fungible assets, +NFTs, collections, and editions with public asset IDs, confidential amounts, +private recipients, and XMZ-only fees without weakening existing XMZ +transaction validation. + +No asset transaction is currently serialized or accepted. The existing source +contains only canonical identity, authorization, transparent conservation, and +in-memory reorganisation reference models. + +## Preferred V1 construction for review + +Each asset output exposes a public 32-byte asset ID and otherwise uses the +existing one-time destination and confidential amount machinery. The asset ID +must be committed by the transaction prefix hash and every applicable +ownership/balance signature so it cannot be substituted after signing. + +Amounts continue to use the existing commitment generator. Validation groups +commitments by public asset ID and verifies a separate balance equation for +each group. XMZ forms its own group and is the only group from which the +transaction fee may be subtracted. + +This intentionally does not attempt confidential asset IDs. It minimizes new +cryptographic machinery, but outputs and activity are linkable at asset-class +level and rings must not mix assets in a way that permits an asset-substitution +proof. + +## Required transaction operations + +### Issuance + +- Commit the complete canonical descriptor and its derived asset ID. +- Verify authorization by the descriptor issuer key. +- Create exactly the declared lifetime supply. +- Reject an asset ID already present in canonical chain state. +- Charge a consensus-defined XMZ creation fee. +- For a claimed collection, verify authorization by the controller recorded in + the earlier collection issuance. + +### Transfer + +- Prove ownership of every real input without exposing which ring member it is. +- Bind each input and output to a public asset ID. +- Prove confidential input amounts equal confidential output amounts plus any + explicit burn for each asset independently. +- Pay the network fee only from the XMZ balance equation. + +### Burn + +- Permanently remove units without creating a spendable output. +- Bind the burn to the asset ID and transaction signature. +- Decide during review whether burn amounts are public or confidential. Public + burns simplify circulating-supply accounting; confidential burns protect + amounts but complicate public supply reporting. + +## NFT and collection rules + +- NFT and collection descriptors have supply one and zero decimals. +- Editions are indivisible and have supply greater than zero. +- Metadata is off-chain and untrusted; consensus commits only its content hash + and bounded reference bytes. +- Collection membership signs + `MonzeroCollectionMembershipV1 || collection_id || member_asset_id`. +- Collection controller rotation and permanent closure are deliberately + unresolved. V1 should prefer immutable controllers or an explicit signed + closure operation over an administrator override. +- Royalties are metadata hints only and are not consensus-enforced. + +## Questions requiring an external answer + +1. Can existing RingCT/CLSAG and Bulletproofs+ components be safely reused when + balance equations are partitioned by a public asset ID? +2. Must all decoys in an input ring share the real input's public asset ID, and + how should wallets sample rings for thin assets? +3. Which exact transcript elements must include the asset ID to prevent + substitution, replay, or cross-asset inflation? +4. What issuance pseudo-input or equivalent proof safely establishes the + declared fixed supply without revealing initial recipient amounts? +5. How should explicit burns be represented and proven? +6. Can batching proofs across asset groups introduce cancellation between + groups or malicious generator relationships? +7. What bounds are required for asset groups, inputs, outputs, metadata, and + verification cost per transaction and block? +8. Does public asset grouping weaken XMZ privacy when XMZ and issued assets are + moved together? +9. Which changes are required in hardware-wallet transaction review? +10. Are there safer established constructions or maintained libraries that + should replace this proposal? + +## Threat model and mandatory negative tests + +- Inflation within one asset. +- Cancellation or conversion between two asset IDs. +- Paying XMZ fees with an issued asset. +- Duplicate issuance across the main chain and alternate branches. +- Descriptor, asset-ID, collection-ID, or metadata-hash substitution. +- Forged issuer or collection-controller authorization. +- Replay across mainnet, testnet, and stagenet. +- Duplicate key images and repeated inputs. +- Malformed points, torsion points, noncanonical scalars, and zero commitments. +- Integer and parser length overflow. +- Proof batching failures that pass individually invalid transactions. +- Reorganisation rollback leaving phantom assets or deleting canonical assets. +- Denial of service from many asset groups or pathological proof shapes. +- Wallet restoration missing assets, NFTs, burns, or reorganised history. + +## Activation requirements + +1. Written review of the construction and transcript. +2. A complete byte-level transaction specification and golden vectors. +3. Strict parsing and verification implemented behind a test-only feature gate. +4. Persistent state with atomic connect/detach behavior. +5. Inflation, malformed-proof, fuzz, and multi-node reorg tests. +6. Wallet restoration and hardware-wallet impact assessment. +7. A disposable isolated network followed by a resettable public testnet. +8. Independent implementation audit and remediation. +9. A separately coordinated hard fork; no silent mainnet activation. + +## Explicit non-goals + +- Smart contracts or arbitrary programs. +- Bridges, wrapped assets, exchanges, or AMMs. +- Confidential asset identifiers. +- Reissuance, freezing, clawback, taxes, or administrator minting. +- A claim that low-activity NFTs have XMZ-sized anonymity sets. diff --git a/docs/MONZERO_PHASE0_BASELINE_20260815.md b/docs/MONZERO_PHASE0_BASELINE_20260815.md new file mode 100644 index 000000000..3e2a1f781 --- /dev/null +++ b/docs/MONZERO_PHASE0_BASELINE_20260815.md @@ -0,0 +1,196 @@ +# Monzero Phase 0 Baseline — 2026-08-15 + +This report records the state recovered after the development machine restart. It is a baseline, not a release approval. + +## Recovery and backup + +- Source commit: `4f92268d7c16741cfb41e5bbe2aa46cc260a9ea5` +- Working tree: 56 changed or untracked paths at the end of this baseline run. These include pre-existing project work and the Phase 0 documents; nothing was discarded or reset. +- Full pre-change archive: `/home/pinhead/Projects/Monzero-Fork-backups/Monero-Fork-before-assets-phase0-20260815.tar.zst` +- SHA-256: `40f9d5f4ba04cfd948dd6356cdb648253966ce3186ce8ac9b86af75010c46fb1` +- Archive integrity: passed `zstd -t`. + +## Build baseline + +- Target: `unit_tests` +- Build command: `cmake --build build --target unit_tests -j2` +- Result: passed; the current source produced `build/tests/unit_tests/unit_tests`. +- Parallelism was deliberately limited to two jobs after the earlier machine crash. + +## Unit-test baseline + +The binary discovered 1,231 tests from 152 test cases. The run progressed through the test inventory but did not produce a clean final result, so Phase 0 remains open. + +### Confirmed failure: DNSSEC-dependent URL test + +`AddressFromURL.Failure` fails because DNSSEC validation returns false through the configured local resolver. A focused rerun reproduced the failure: + +```text +Value of: dnssec_result + Actual: false +Expected: true +``` + +The resolver reported that no signatures were available while building the DNSSEC chain of trust. This may be environment-dependent, but it must be isolated or made deterministic before it can be accepted in release CI. + +### Confirmed incomplete test: protocol-handler race test + +`cryptonote_protocol_handler.race_condition` remained blocked in a futex wait for more than ten minutes. The test runner was then interrupted with SIGINT; no daemon or wallet process was terminated. This requires a focused, time-bounded reproduction and diagnosis. + +Because the run was interrupted, no pass count is claimed. Passing output was observed across substantial wallet/crypto utility, mnemonic, LMDB, networking, serialization, HTTP, SOCKS, ZMQ, and node-server groups, but that is not a substitute for a complete suite result. + +## Local network observation + +The already-running local daemon on RPC port 16175 was left untouched and reported: + +```json +{ + "height": 807, + "target_height": 0, + "incoming_connections_count": 0, + "outgoing_connections_count": 0, + "difficulty": 167813, + "synchronized": true, + "status": "OK" +} +``` + +The daemon considers its local chain synchronized, but zero peer connections means this observation does not demonstrate live network convergence or propagation. + +## Phase 0 disposition + +Asset consensus implementation remains on hold. The next engineering actions are: + +1. Reproduce and diagnose the protocol-handler race-test stall under a strict timeout. +2. Replace external DNS assumptions in unit tests with deterministic fixtures, or document and enforce a validated CI resolver. +3. Establish a multi-node automated chain test covering peer discovery, block propagation, reorg handling, wallet refresh, and transaction relay. +4. Produce reproducible, checksummed Linux and Windows release artifacts from a clean source checkout. + +Only after the stabilization gates in `MONZERO_PHASE0_STABILIZATION.md` are satisfied should the asset design move from research specification to consensus implementation. + +## Follow-up remediation + +The fast gate is now deterministic and clean: + +- `tests/phase0/run-fast-unit-tests.sh build` passed all 1,230 selected tests from 151 test cases in 174.317 seconds. +- DNSSEC-dependent tests use an explicitly configured validating TCP resolver (`DNS_PUBLIC`, defaulting to `tcp://1.1.1.1`). +- Fork-specific address, emission, amount-precision, wallet-cache, serialization, multisig, URI, HTTP, and notifier fixtures were corrected and passed. +- The foreign Monero wallet fixture is now explicitly expected to fail the Monzero genesis check; it is not accepted as a Monzero wallet. +- The initial `tests/phase0/monzero_multinode.py --build-dir build` harness passed twice, demonstrating three-node peer connectivity, block propagation, restart/catch-up, and a common tip in isolated regtest directories. + +The 1,230-test result excludes only +`cryptonote_protocol_handler.race_condition`. Its handcrafted miner +transaction always used the legacy `txout_to_key` output, even after the test +chain activated hard-fork v16. Consensus correctly rejected that alternate +chain because v16 requires `txout_to_tagged_key`, leaving the test waiting for +an impossible synchronization event. The fixture now selects the output type +from the active hard-fork version. + +`tests/phase0/run-stress-tests.sh build` subsequently passed the focused +approximately 9,600-block concurrency test in 9.582 seconds. Phase 0 and asset +activation remain open until the wallet-restoration, double-spend/adversarial +reorg, and reproducible-release checks pass. + +The extended three-node harness passed again at final height 84. It verified +competing three- and five-block forks, convergence on the longer fork after +reconnection, one-XMZ transaction relay through every node, confirmation by a +different node, and the exact confirmed receiver balance. It then restored the +receiver from its temporary mnemonic seed, rescanned from height zero, and +recovered the identical address and balance. + +The focused native adversarial gate initially found that the inherited +`FIRST_BLOCK_REWARD` in `tests/core_tests/double_spend.h` still used Monero's +subsidy. Monzero's larger genesis subsidy introduced an unexpected miner change +output, so the same-transaction fixture tried to derive Bob's key image from +the miner's output and failed before reaching consensus validation. Updating +the fixture to the already verified Monzero subsidy fixed the test setup. + +`tests/phase0/run-adversarial-core-tests.sh build` then passed all 16 selected +cases with zero failures. Coverage includes transaction-pool public/all-key +spends, no-relay/local/key-image conflicts, duplicate inputs in one +transaction, double spends across the same or different blocks, competing +chains, alternate-chain rollback, and both kept-by-block modes. + +## Existing artifact audit + +The existing `genesis-pre2` Linux and Windows outer checksums and every inner +package checksum pass. Archive listings contain the intended executables, +launch scripts, documentation, license, and checksum manifests. + +These packages are nevertheless **stale baseline artifacts**, not candidates +for republication after the Phase 0 fixes. The current native Linux binaries +are dynamically linked, unstripped developer builds with host-library +dependencies (including Boost 1.90), and the existing Windows binaries predate +the stabilization changes. New artifacts must be produced from an immutable, +documented source snapshot in pinned Linux and Windows build environments and +reproduced by a second build before their filenames or website links change. + +## Protected manifest and inactive asset identity prototype + +`config/monzero-consensus.json` now records the monetary policy, transaction +version, asset-acceptance state, hard-fork schedule, and protected vectors for +all three public networks. Three compiled `monzero_consensus` tests regenerate +the genesis blocks and lock the corresponding hashes, UUIDs, nonces, prefixes, +ports, emission constants, precision, and hard-fork schedule. + +The research-only `cryptonote::assets::issuance_descriptor` provides bounded +validation, canonical encoding, network domain separation, and a pinned +asset-ID vector. It is compiled for testing but is not referenced by +transaction serialization, consensus validation, the mempool, blocks, RPC, or +wallets. `CURRENT_TRANSACTION_VERSION` remains 2 and the manifest explicitly +records `public_asset_transactions_accepted: false`. + +After these additions, the fast unit gate passed 1,237 of 1,237 selected tests +from 153 test cases in 170.050 seconds. The separate pruning concurrency gate +also passed in 10.220 seconds. + +The inactive asset research code now additionally includes a transparent +semantic conservation validator. It separates XMZ fees from issued-asset +balances, requires issuance outputs to equal the declared fixed supply, and +enforces independent input/output/burn equality for every known asset. Focused +tests cover valid issuance, transfers and burns plus duplicate issuance, +unknown assets, cross-asset conversion, native inflation, noncanonical values, +and integer-overflow attempts. This validator remains disconnected from all +transaction and consensus paths and is not a privacy construction. + +With the six additional conservation tests included, the deterministic fast +gate passed 1,243 of 1,243 selected tests from 153 test cases in 181.415 +seconds on 2026-08-15. The separate approximately 9,600-block pruning +concurrency stress test also passed in 14.564 seconds. + +The provisional descriptor was advanced to version 2 before activation to add +an explicit asset class and collection ID. Fungible, non-fungible, collection, +and edition identities are now unambiguous. NFT and collection descriptors +require one indivisible unit, while edition units are indivisible. Issuer and +collection-membership messages have separate hash domains and signature +verification. Fifteen focused asset/consensus tests pass; no public transaction +format or asset acceptance rule is enabled. + +After the descriptor-v2 and authorization additions, the deterministic fast +gate passed 1,245 of 1,245 selected tests from 153 test cases in 152.606 +seconds on 2026-08-15. + +An inactive reference registry now exercises authenticated issuance state, +verified collection membership, ordering by issuance height, duplicate +rejection, and deterministic removal/reissuance across simulated chain +detachments. Seventeen focused asset and protected-consensus checks pass. The +registry is intentionally in-memory and is not connected to LMDB or block +validation. + +The exact staged Phase 0 source snapshot subsequently passed 1,247 of 1,247 +selected deterministic tests from 153 test cases in 162.024 seconds. + +## Deterministic packaging checkpoint + +`utils/release/package-linux.sh` and `verify-package.sh` now construct and +validate normalized Linux archives. Two development archives made from the +same input binaries and epoch were byte-identical, with SHA-256 +`a47ae087706f52a96829a83b3e4bd8be722663eb6ca3a95743526e4005314a41`. +The test archive passed extraction, inner-manifest, executable-format, and +version checks. + +This does not promote the test artifact to a release. Strict verification +correctly rejects it because the source tree is dirty, binary reproducibility +is unverified, and the developer executables are dynamically linked, +unstripped, and contain debug information. The generated archives remain in +temporary directories and were not copied to `dist/` or the website. diff --git a/docs/MONZERO_PHASE0_STABILIZATION.md b/docs/MONZERO_PHASE0_STABILIZATION.md new file mode 100644 index 000000000..2a42c8ca6 --- /dev/null +++ b/docs/MONZERO_PHASE0_STABILIZATION.md @@ -0,0 +1,139 @@ +# Monzero Phase 0 stabilization plan + +Status: active engineering gate +Baseline date: 2026-08-15 +Native coin ticker: XMZ + +This plan must be completed before any Monzero Assets consensus rules are +activated on a public network. Research, specification, and isolated prototypes +may proceed, but asset transaction formats must not be accepted by mainnet. + +## Current baseline + +- The independent mainnet identity, genesis, address prefixes, ports, emission, + precision, and hard-fork schedule are recorded in `MONZERO_CHAIN_SPEC.md`. +- Linux command-line and Windows GUI/CLI prerelease packages exist, but the + release process is not yet reproducible or signed. +- The official public node is `node.monzero.org:6174`, with restricted RPC on + port 6175. +- Only one official publicly reachable bootstrap node is currently established. +- Wallet creation, mining, synchronization, transfers, the public explorer, and + website have received manual testing. +- The inherited release checklist and portions of user-facing utility text still + refer to Monero infrastructure or terminology. +- The working tree contains substantial uncommitted fork work. A full pre-assets + backup was created before beginning this phase. + +## Gate A: source and consensus baseline + +- [ ] Commit the current fork as a named, reviewable baseline. +- [x] Record the exact genesis transaction, nonce, hash, and network UUID. +- [x] Record mainnet, testnet, and stagenet address prefixes and ports. +- [x] Generate a machine-readable consensus-parameter manifest. +- [x] Add tests which fail if protected network constants change unexpectedly. +- [ ] Document every intentional divergence from the upstream Monero version. +- [ ] Separate compatibility identifiers that must remain unchanged from + user-facing branding that should say Monzero. +- [ ] Define the supported database migration and rollback policy. + +Acceptance: two clean source checkouts produce nodes that agree on genesis, +hard-fork versions, block rewards, transaction validity, and block hashes. + +## Gate B: network reliability + +- [ ] Operate at least three independently administered public seed nodes. +- [ ] Place seed nodes in at least two providers and two geographic regions. +- [ ] Confirm a fresh node can bootstrap when any one seed is unavailable. +- [ ] Confirm a seed never attempts to use itself as its bootstrap peer. +- [ ] Test inbound, outbound, IPv4, DNS failure, restart, and peer-cache recovery. +- [ ] Monitor height, peer count, fork divergence, disk, memory, and RPC health. +- [ ] Define an incident response and emergency release procedure. + +Acceptance: a new node with an empty data directory synchronizes without manual +peer intervention, and the network continues progressing with one seed offline. + +## Gate C: wallet and transaction correctness + +- [ ] Create, restore, and rescan wallets from seed at multiple restore heights. +- [ ] Test incoming, outgoing, pending, failed, and replaced transactions. +- [ ] Test coinbase maturity and normal output unlock rules. +- [ ] Test view-only wallets, subaddresses, multisig, and offline signing, or + explicitly declare unsupported features before launch. +- [ ] Verify CLI and GUI display XMZ consistently. +- [ ] Verify no user-facing command suggests reusing Monero keys. +- [ ] Test wallet recovery after unclean shutdown and daemon reorganisation. + +Acceptance: an independently restored wallet reconstructs the same balance and +transaction history as the original wallet. + +## Gate D: automated consensus testing + +- [x] Unit tests for emission, precision, parsing, address prefixes, and fees. +- [x] Golden vectors for genesis and representative transactions. +- [x] Multi-node integration tests for synchronization and relay. +- [ ] Reorganisation tests across every active hard-fork version. +- [x] Network partition and recovery tests. +- [ ] Transaction and block parser fuzzing. +- [x] Invalid inflation, overflow, duplicate-spend, and malformed-proof tests. +- [ ] Continuous integration for supported Linux and Windows targets. + +Acceptance: all protected tests pass from a clean build and intentional +consensus changes require explicit vector updates. + +## Gate E: release engineering + +- [ ] Replace `docs/RELEASE_CHECKLIST.md` with a Monzero-specific checklist. +- [ ] Produce reproducible Linux builds from a pinned environment. +- [ ] Produce reproducible Windows builds from a pinned environment. +- [ ] Publish source commit, build recipe, file sizes, and SHA-256 hashes. +- [ ] Establish an offline release-signing key and publish its fingerprint. +- [ ] Sign release manifests; pursue Windows code signing separately. +- [ ] Test archives on clean supported operating systems. +- [ ] Document upgrade, downgrade, uninstall, and data-directory behaviour. + +Progress note: deterministic Linux archive construction and verification are +implemented and produce byte-identical archives from identical inputs. The +current developer binaries are dynamic, unstripped, and not independently +reproduced, so strict release verification correctly rejects them. + +Acceptance: two independent builders produce byte-identical binaries or a +documented, investigated explanation for every difference. + +## Gate F: public documentation and disclosure + +- [ ] Publish the private-bootstrap height range and total mined allocation. +- [ ] Publish team-controlled addresses or a privacy-compatible accountability + mechanism agreed before public launch. +- [ ] State clearly that Monzero is independent from the Monero project. +- [ ] Publish supported platforms, known limitations, and audit status. +- [ ] Create security contact and responsible-disclosure instructions. +- [ ] Remove inherited links that direct users to unrelated Monero services. + +Acceptance: a new operator can verify, install, run, back up, restore, and +upgrade a node or wallet using only public Monzero documentation. + +## Asset-development hold point + +Mainnet asset implementation remains blocked until Gates A through E are +complete. The Monzero Assets specification may advance in parallel, and an +isolated disposable development network may be used after cryptographic review. + +## Inactive asset/NFT prototype progress + +- [x] Canonical network-separated fixed-supply asset IDs. +- [x] Explicit fungible, NFT, collection, and edition classes. +- [x] NFT/collection supply-one and zero-decimal invariants. +- [x] Independent XMZ fee and per-asset conservation semantics. +- [x] Domain-separated issuer authorization signatures. +- [x] Domain-separated collection-membership authorization signatures. +- [x] Inactive authenticated issuance registry with deterministic reorg rollback. +- [x] External cryptographic-review brief and mandatory threat cases. +- [ ] Reviewed confidential per-asset commitment and range-proof construction. +- [ ] Versioned asset transaction serialization with strict parser limits. +- [ ] Persistent database indexes and production reorganisation-safe asset state. +- [ ] Isolated asset development network and faucet. +- [ ] Wallet issuance, scanning, restoration, transfer, burn, and metadata UI. +- [ ] Explorer display with unverified/verified collection distinction. + +All completed items in this section are inactive primitives and unit tests. +They do not enable token or NFT issuance on mainnet, testnet, or stagenet. diff --git a/docs/RELEASE_CHECKLIST.md b/docs/RELEASE_CHECKLIST.md index 632366985..b64a28a30 100644 --- a/docs/RELEASE_CHECKLIST.md +++ b/docs/RELEASE_CHECKLIST.md @@ -1,68 +1,110 @@ -- [ ] Security audit -- [ ] Code audit -- [ ] Ledger integration - - [ ] Implemented in Monero codebase (if needed) - - [ ] Ledger app integration coded by Ledger - - [ ] Ledger Monero app update available -- [ ] Trezor integration - - [ ] Implemented in Monero codebase (if needed) - - [ ] Trezor app integration coded by Trezor - - [ ] Trezor firmware update available (if needed) -- [ ] Fork height set - - [ ] Monero-announce mailer notice - - [ ] Twitter announcement - - [ ] Reddit announcement - - [ ] Getmonero.org announcement -- [ ] Notify wallets - - [ ] MyMonero - - [ ] Coinomi - - [ ] Exa Wallet - - [ ] Wookey Wallet - - [ ] X Wallet - - [ ] Guarda - - [ ] ZelCore - - [ ] Cake Wallet - - [ ] Monerujo - - [ ] Edge Wallet - - [ ] Exodus - - [ ] XMRWallet -- [ ] Notify exchanges - - [ ] https://web.getmonero.org/community/merchants/#exchanges -- [ ] Notify 3rd party payment processors - - [ ] https://web.getmonero.org/community/merchants/#payment-gateways -- [ ] Notify mining pools - - [ ] https://miningpoolstats.stream/monero -- [ ] Release tagged - - [ ] Update src/version.cpp.in with new version AND new name (if necessary) - - [ ] Update Gitian YML files in contrib/gitian/ to the new version number - - [ ] Update README.md with new fork table entry (or at least update the Recommended Monero version) - - [ ] Update contrib/gitian/README.md so that the instructions reflect the current version - - [ ] Update src/checkpoints/checkpoints.cpp with a recent hardcoded checkpoint - - [ ] Update src/blocks/checkpoints.dat with ./monero-blockchain-export --output-file checkpoints.dat --block-stop <recent block height> --blocksdat - - [ ] Update expected_block_hashes_hash in src/cryptonote_core/blockchain.cpp with checkpoints.dat sha256 hash -- [ ] Testnet forked -- [ ] Testnet testing/verification - - [ ] Ledger - - [ ] Trezor - - [ ] Release-specific testing - - [ ] RPC testing/update RPC documentation -- [ ] CLI reproducible builds validated -- [ ] CLI released - - [ ] https://web.getmonero.org/downloads/ updated - - [ ] Update hashes.txt on website - - [ ] Update downloads.yml on website - - [ ] Update auto-update DNS records - - [ ] Update redirects on downloads box - - [ ] Update seed nodes -- [ ] GUI released - - [ ] https://web.getmonero.org/downloads/ updated - - [ ] Update hashes.txt on website - - [ ] Update hashes.txt.sig on website - - [ ] Update downloads.yml on website - - [ ] Update auto-update DNS records - - [ ] Update redirects on downloads box -- [ ] Release Announcements - - [ ] Monero-announce mailer notice - - [ ] Twitter announcement - - [ ] Reddit announcement - - [ ] Getmonero.org announcement +# Monzero release checklist + +This checklist applies to every Monzero node, CLI wallet, GUI wallet, miner +control, website download, and consensus release. Native amounts use XMZ. + +## Scope and source + +- [ ] Release version, codename, source commit, and supported platforms agreed +- [ ] Working tree clean or every included patch documented +- [ ] Submodules pinned and verified +- [ ] Consensus-affecting changes identified explicitly +- [ ] Database or wallet migration requirements documented +- [ ] User-visible changes and known limitations written +- [ ] Independent reviewer approves the release scope + +## Consensus and network safety + +- [ ] Genesis and protected consensus-vector tests pass +- [ ] Block reward, precision, fees, and amount parsing tests pass +- [ ] Valid and invalid transaction tests pass +- [ ] Synchronization from an empty data directory succeeds +- [ ] Reorganisation and restart tests pass +- [ ] Node interoperates with the currently deployed release +- [ ] Seed list contains no node configured to connect to itself +- [ ] Mainnet, testnet, and stagenet identifiers remain isolated +- [ ] Hard-fork activation height and operator notice reviewed, if applicable + +## Wallet safety + +- [ ] New wallet creation tested in CLI and GUI +- [ ] Seed restoration reproduces addresses and balances +- [ ] Incoming and outgoing transfers confirmed +- [ ] Pending, failed, pool, and confirmed history tested +- [ ] Coinbase and normal output unlock behaviour tested +- [ ] Wallet shutdown and unclean-restart recovery tested +- [ ] View-only, multisig, hardware, and offline signing marked tested or unsupported +- [ ] No workflow requests a recovery seed except an explicit recovery operation + +## Branding and configuration + +- [ ] Product name is Monzero and native ticker is XMZ +- [ ] Executable names, titles, prompts, logs, and default paths are correct +- [ ] Ports, address prefixes, network UUIDs, DNS seeds, and website are correct +- [ ] Required upstream attribution and copyright notices are preserved +- [ ] User-facing inherited Monero service links are removed or clearly contextual +- [ ] Warnings prohibit cross-fork key and seed reuse + +## Automated testing + +- [ ] Unit tests pass from a clean build +- [ ] Core and functional tests pass +- [ ] RPC compatibility tests pass +- [ ] Parser and consensus fuzzing has no unresolved regressions +- [ ] Website and explorer API smoke tests pass +- [ ] Linux launch, mining, wallet, and uninstall scripts pass shell validation +- [ ] Windows launch and mining scripts pass on a clean Windows system + +## Build and package + +- [ ] Linux build produced by the pinned build environment +- [ ] Windows build produced by the pinned cross-build environment +- [ ] A second builder checks reproducibility +- [ ] Executable formats and required runtime libraries inspected +- [ ] Archives contain only intended files +- [ ] README and upgrade instructions included +- [ ] SHA-256 manifest generated and verified +- [ ] Release manifest signed with the Monzero release key +- [ ] Packages scanned and tested after extraction from their final archives + +The Linux archive layer is generated with `utils/release/package-linux.sh`. +It refuses a dirty tree unless `ALLOW_DIRTY=1` is explicitly supplied, in +which case the filename and embedded manifest are marked development/dirty. +`utils/release/verify-package.sh` verifies archive shape, inner checksums, +executable presence, formats, and reported versions. This makes packaging +deterministic; it does not by itself make locally compiled binaries +reproducible. `RELEASE_STRICT=1` additionally rejects dirty manifests, +unverified build reproducibility, dynamically linked binaries, debug +information, and unstripped executables. + +## Deployment + +- [ ] Public node binaries backed up before replacement +- [ ] Public node database backup or recovery procedure confirmed +- [ ] New node starts, binds expected ports, and reports correct version +- [ ] Peer counts, height, difficulty, synchronization, and RPC checked +- [ ] At least one independent node successfully handshakes and synchronizes +- [ ] Explorer and website display current chain data +- [ ] Download files, sizes, MIME types, checksums, and links verified publicly +- [ ] Rollback binary and rollback instructions remain available + +## Publication and monitoring + +- [ ] Release notes identify experimental and unaudited components +- [ ] Source commit and signed hashes published +- [ ] Node, miner, wallet, and service operators receive upgrade instructions +- [ ] Security contact and disclosure process published +- [ ] Height, fork divergence, peers, RPC, CPU, memory, disk, and logs monitored +- [ ] Post-release review performed after 24 hours and seven days + +## Assets-specific gate + +For any future Monzero Assets release: + +- [ ] Phase 0 stabilization gates are complete +- [ ] Consensus and cryptographic specifications are public +- [ ] Independent cryptographic and implementation audits are resolved +- [ ] Inflation and cross-asset conversion tests pass +- [ ] Asset wallet restoration tests pass +- [ ] Extended public testnet has completed a planned upgrade +- [ ] Mainnet activation height has advance operator coordination |