diff --git a/README.md b/README.md index 37c5b8c..5433e03 100644 --- a/README.md +++ b/README.md @@ -6,6 +6,19 @@ The RIP process itself is defined in [RIP-0001](rip-0001/rip-0001.md). --- +## Bootstrap status (read this first) + +This repository is in a **bootstrap phase**. Specifically: + +- The RIP process described in RIP-0001 was published without a prior public discussion period. RIP-0001 is itself in `Draft` and is subject to revision. +- No public discussion venue ("Discussion-To") is yet operational. Preambles list `TBD` accordingly. +- The set of editors is bootstrapped at two: the original author of these documents and one independent editor (see [`governance/editor-changes.md`](governance/editor-changes.md)). Further editors will be appointed per RIP-0001 §Editors. +- Almost every Standards Track RIP in this repository was authored unilaterally and has not yet undergone substantive editor or community review. Such RIPs are marked `Idea` (a pre-`Draft` state defined in RIP-0001 §RIP Status). Do not interpret their presence here as endorsement by Rincoin's user community. + +Until that changes, RIPs in this repository should be read as **proposals from their respective authors**, not as ratified protocol policy. + +--- + ## Index | Number | Title | Layer | Type | Status | Requires | diff --git a/SECURITY.md b/SECURITY.md index 7309e58..c435de8 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -8,9 +8,14 @@ The following keys may be used to communicate sensitive information to developer | Name | Fingerprint | |------|-------------| -| Aevust | ED20 B635 4EE4 526D 01F8 3B53 8B6E 3BF4 5C71 4ECA | +| Aevust | ED20 B635 4EE4 526D 01F8 3B53 8B6E 3BF4 5C71 4ECA | +| Takologi | FEE1 ACA5 2C65 FF3E BF31 818C B559 5E17 52BC 2A82 | -### How to obtain our public key +### How to obtain our public keys -You can import our public key directly from this repository: -`gpg --import security/Aevust_0x8B6E3BF45C714ECA_public.asc` +You can import the public keys directly from this repository: + +``` +gpg --import security/Aevust_0x8B6E3BF45C714ECA_public.asc +gpg --import security/Takologi_0xB5595E1752BC2A82_public.asc +``` diff --git a/governance/core-role.md b/governance/core-role.md index 2b319dc..cdf8ca4 100644 --- a/governance/core-role.md +++ b/governance/core-role.md @@ -1,6 +1,8 @@ # Rincoin Core Role Assignments -**Last Updated**: 2026-05-14 +> **Scope:** This file records project-level role assignments inside the author's Rincoin Core development effort. It is **not part of the RIP process** defined in RIP-0001 and confers **no authority** over the review, acceptance, or status of RIPs. RIP-process decisions are governed solely by the editors listed in [`editor-changes.md`](editor-changes.md), per RIP-0001 §Editors. + +**Last Updated**: 2026-05-20 | Role | Current Holder | |------|----------------| @@ -10,17 +12,4 @@ | Core Research Lead | @Aevust | | Principal Architect | @Aevust | -## Current Voter Count - -**Distinct voters**: 2 (@ysmreg, @Aevust) - -**Required authority for version increments**: - -| Component | Required | -|-----------|----------| -| MINOR (v1.0.x) | 1 vote — permitted by any single Core Role holder | -| MAJOR / GENERATION | 2/2 — unanimous agreement required | - -## Role Assignment History - -See `governance/editor-changes.md` for the full record of role transitions and assignment changes. +Project-level role assignment history is maintained outside this repository. RIP editor changes are recorded separately in [`editor-changes.md`](editor-changes.md). diff --git a/rip-0001/rip-0001.md b/rip-0001/rip-0001.md index 0298179..dc13493 100644 --- a/rip-0001/rip-0001.md +++ b/rip-0001/rip-0001.md @@ -2,11 +2,15 @@ RIP: 1 Layer: Process Title: RIP Process and Specifications - Author: @Aevust - Status: @Active + Author: Aevust + Author-Fingerprint: ED20 B635 4EE4 526D 01F8 3B53 8B6E 3BF4 5C71 4ECA + Author: Takologi + Author-Fingerprint: FEE1 ACA5 2C65 FF3E BF31 818C B559 5E17 52BC 2A82 + Discussion-To: TBD — no public pre-RIP discussion has yet taken place; this RIP is itself a draft proposal awaiting community review. + Status: Draft Type: Process Created: 2026-04-22 - Updated: 2026-05-16 + Updated: 2026-05-20 License: CC0-1.0 ``` @@ -14,19 +18,17 @@ ## Abstract -A Rincoin Improvement Proposal (RIP) is a design document providing information to the Rincoin community, describing a new feature for Rincoin or its processes or environment. The RIP should provide a concise technical specification of the feature and a rationale for the feature. +A Rincoin Improvement Proposal (RIP) is a design document that specifies a change to the Rincoin protocol, a change to a Rincoin-related process, or general information for the Rincoin community. -This document defines the RIP process: the types of RIPs, their workflow, required content, format, and the responsibilities of RIP editors. It also defines the Core Role structure, the version-numbering scheme for Rincoin Core releases, and the succession procedure that governs the human authority responsible for protocol evolution. It is modeled directly after Bitcoin Improvement Proposal 1 (BIP-1) and BIP-2, with adaptations specific to Rincoin's regenerative cryptoeconomic architecture. +This document defines the RIP process: the types of RIPs, their workflow, required content and format, the responsibilities of RIP editors, and the relationship between RIPs and the Rincoin network. It is modeled after BIP-1, BIP-2, and BIP-3. -This RIP serves as the meta-specification governing all subsequent RIPs. +This RIP is itself a draft. It has not been ratified by the Rincoin community. --- ## Motivation -The Rincoin protocol comprises a thermodynamically self-regenerating monetary architecture spanning multiple consensus-level mechanisms: the Customized Halving emission schedule, the Proof of Rinne (PoR) reincarnation consensus, the Cryptographic Vault for legacy asset quarantine, Zero-Knowledge Proof owner recovery, the MimbleWimble Extension Block (MWEB) privacy layer, and Layer-2 Account Abstraction. These mechanisms must evolve under transparent, peer-reviewed governance. - -Without a formalized improvement-proposal process, technical changes risk being merged on an ad-hoc basis, undermining the long-horizon stability guarantees the protocol is designed to provide. Furthermore, because the Proof of Rinne consensus operates on a ~400-year timescale, the governance structures that maintain the protocol must themselves be designed to survive across human generations. This RIP establishes both the improvement-proposal process and the long-horizon governance framework required to operate it. +Rincoin needs a transparent, low-ceremony way to propose, document, and review changes to the protocol and to processes around it. The Bitcoin Improvement Proposal (BIP) process has done this for the Bitcoin ecosystem since 2011 and has been refined by BIP-2 (2016) and BIP-3 (2024). Adopting a directly comparable process for Rincoin keeps the cognitive cost low for contributors familiar with BIPs, and avoids inventing governance constructs that the protocol does not need. --- @@ -37,22 +39,20 @@ Without a formalized improvement-proposal process, technical changes risk being A RIP is a design document describing one of the following: 1. A new feature or modification to the Rincoin protocol. -2. Information about a process, convention, or environment relevant to Rincoin development. -3. A description of a recommended best practice. +2. A process, convention, or environment relevant to Rincoin development. +3. General information or a recommended practice for the Rincoin community. -RIPs are published in the official Rincoin RIPs repository and are the authoritative source of specifications for protocol features. +A RIP is a *document*, not a *rule*. Rules are what nodes actually run. Publication of a RIP does not, by itself, change any consensus rule, network parameter, or piece of software. --- ### RIP Types -There are three kinds of RIP: - -1. **Standards Track RIP** — Describes any change that affects most or all Rincoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change that affects interoperability. - -2. **Process RIP** — Describes a process surrounding Rincoin or proposes a change to (or an event in) a process. Process RIPs are like Standards Track RIPs but apply to areas other than the Rincoin protocol itself. This RIP-0001 is itself a Process RIP. +There are three types of RIP: -3. **Informational RIP** — Provides general guidelines or information to the Rincoin community but does not propose a new feature. Informational RIPs do not necessarily represent Rincoin community consensus or recommendations. +1. **Standards Track** — A change that affects most or all Rincoin implementations: network protocol, block or transaction validity, or anything affecting interoperability. +2. **Process** — A change to a process surrounding Rincoin. This RIP-0001 is a Process RIP. +3. **Informational** — General guidelines or information. Informational RIPs do not necessarily represent community consensus or a recommendation. --- @@ -60,50 +60,47 @@ There are three kinds of RIP: Each Standards Track RIP MUST specify exactly one Layer: -1. **Consensus (hard fork)** — A change that creates a permanent divergence between non-upgraded and upgraded nodes. All nodes MUST upgrade or be permanently partitioned from the upgraded chain. - -2. **Consensus (soft fork)** — A backwards-compatible tightening of consensus rules. Non-upgraded nodes will continue to accept blocks produced by upgraded nodes, but may not produce blocks acceptable to upgraded nodes. - +1. **Consensus (hard fork)** — A change that creates a permanent divergence between non-upgraded and upgraded nodes. +2. **Consensus (soft fork)** — A backwards-compatible tightening of consensus rules. 3. **Peer Services** — Changes to the P2P network protocol that do not affect consensus. - 4. **API/RPC** — Changes to the JSON-RPC interface or other application-facing APIs. - 5. **Applications** — Conventions for applications built on Rincoin (e.g., wallet conventions, payment URIs). --- ### RIP Status -RIPs proceed through the following statuses: +A RIP is in exactly one of the following states. The status MUST appear in the preamble. -- **Draft** — The first formally tracked status. The RIP has been merged into the RIPs repository. -- **Proposed** — A RIP that is complete, has a working implementation reference (where applicable), and is ready for community review. -- **Active** — A RIP that has been adopted and deployed (or, for Process RIPs, is in effect). -- **Final** — A Standards Track RIP whose specification is locked and deployed; equivalent to Active but applies after a single deployment event with no further parameter changes anticipated. -- **Replaced** — A RIP that has been superseded by a later RIP. -- **Withdrawn** — A RIP that has been withdrawn by its authors. -- **Deferred** — A RIP that has stalled and is no longer actively pursued. -- **Rejected** — A RIP that has been rejected by the Founder or Core Strategic Authority on substantive grounds, or by RIP editors on procedural grounds (e.g., duplicate proposal, out of scope, or irreconcilable format defects). +- **Idea** — Merged for record only. Not yet a complete proposal; no substantive review has occurred. An `Idea` RIP MUST carry a visible note to that effect at the top of its body. +- **Draft** — Formally tracked. The author considers the proposal mature enough for sustained technical review. +- **Proposed** — Specification is complete; for Standards Track RIPs a reference implementation exists. Ready for broad technical review and considered a candidate for deployment discussion. +- **Active** — A Process or Informational RIP that is in effect; or a Standards Track RIP whose deployment is observable on the public network by independent operators. +- **Final** — A Standards Track RIP whose deployment has completed and whose specification will not be revised. +- **Withdrawn** — The author has withdrawn the RIP. +- **Replaced** — Superseded by a later RIP (recorded in `Superseded-By:`). +- **Rejected** — Refused on procedural grounds (see §Editors). Rejection is not a judgement on technical merit. +- **Obsolete** — No longer in use. -The status MUST be reflected in the RIP's preamble. +Advancement to `Active` or `Final` requires a public pull request that cites objective evidence of deployment (e.g., the activation block height and the rule that observers can verify is being enforced). Status changes are mechanical, not editorial. Publication of the RIP does not imply network acceptance. --- ### RIP Workflow -1. **Pre-RIP discussion** — An author posts a summary of the proposed change to the Rincoin development forum or Discord (#rip-drafts channel) and solicits feedback. - -2. **Drafting** — The author writes a RIP following the format defined in this document and opens a pull request to the RIPs repository. - -3. **Editor review** — RIP editors check format compliance, completeness, and clarity. Editors do NOT judge technical merit at this stage. +1. **Pre-RIP discussion** — The author posts a summary of the proposed change to a public Rincoin discussion venue (forum, mailing list, or archived Discord channel) and solicits feedback. +2. **Drafting** — The author writes a RIP following this document and opens a pull request to the RIPs repository. +3. **Editor review** — Editors check format compliance, completeness of required sections, license, and absence of duplication. Editors do NOT judge technical merit. +4. **Merge** — On passing editor review, the RIP is assigned a number and merged as `Draft` (or `Idea` if the author requests record-only publication of work-in-progress material). +5. **Community review** — The merged RIP is publicly reviewed. The author revises in subsequent PRs. +6. **Reference implementation** — For Standards Track RIPs, a working reference implementation MUST exist before the status can advance to `Proposed`. +7. **Activation / Adoption** — For Standards Track RIPs, advancement to `Active` or `Final` requires evidence of deployment as defined in §RIP Status. For Process and Informational RIPs, `Active` reflects that the document is in use. -4. **Merge as Draft** — Upon passing editor review, the RIP is assigned a number and merged with status `Draft`. - -5. **Community review** — The Draft is publicly reviewed. Authors revise based on feedback. +--- -6. **Reference implementation** — For Standards Track RIPs, a reference implementation MUST be available before status can advance to `Proposed`. +### RIPs and Network Adoption -7. **Activation** — For Consensus-Layer RIPs, activation parameters (block height, signaling mechanism, deployment timeout) MUST be specified before status can advance to `Active` or `Final`. +Publication of a RIP in this repository does not imply network adoption, consensus acceptance, deployment approval, mandatory implementation, or activation on the Rincoin network. RIPs are proposals, not directives. Consensus-level legitimacy is determined by long-term technical review, testing, node and miner adoption, wallet and infrastructure compatibility, and actual on-chain behaviour. --- @@ -111,20 +108,29 @@ The status MUST be reflected in the RIP's preamble. A Standards Track RIP MUST contain the following sections, in this order: -1. **Preamble** — RFC-822-style headers (specified below). +1. **Preamble** — RFC-822-style headers (see below). 2. **Abstract** — A short (~200-word) description of the issue being addressed. -3. **Motivation** — Why the existing protocol is inadequate to address the problem. -4. **Specification** — The technical specification, complete enough that competing interoperable implementations can be built from it. -5. **Rationale** — Discussion of design decisions, alternatives considered, and trade-offs. -6. **Backwards Compatibility** — Description of incompatibilities and their consequences. MUST identify the RIP as hard fork, soft fork, or non-consensus change. -7. **Reference Implementation** — Link to a complete reference implementation (required before status `Proposed`). -8. **Test Vectors** — Concrete test cases that any conforming implementation MUST pass. -9. **Security Considerations** — Analysis of security implications, attack vectors, and mitigations. -10. **Acknowledgments** — Credit to contributors, prior art, and inspirations. +3. **Motivation** — Why existing rules are inadequate. +4. **Specification** — Complete enough that competing interoperable implementations can be built from it. +5. **Rationale** — Design decisions, alternatives, trade-offs. +6. **Backwards Compatibility** — Identifies the RIP as hard fork, soft fork, or non-consensus change, and describes incompatibilities. +7. **Reference Implementation** — Required before advancement to `Proposed`. +8. **Test Vectors** — Concrete test cases that conforming implementations MUST pass. +9. **Security Considerations** — Attack vectors, mitigations. Absence of implications is itself a claim that requires justification. +10. **Acknowledgments** — Credit to contributors and prior art. 11. **Copyright** — License declaration. CC0-1.0 is recommended. Process and Informational RIPs MAY omit Specification, Reference Implementation, Test Vectors, and Backwards Compatibility where not applicable. +A Consensus-Layer RIP's Specification MUST additionally include: + +- **Activation conditions** (block height, signaling mechanism, deployment timeout). +- **Rollback considerations**. +- **Interoperability analysis**. +- **Replay/split considerations** where relevant. +- **Migration procedures**. +- **Operational impact assessment** for node operators, miners, wallets, exchanges, explorers, and infrastructure providers. + --- ### Header Preamble @@ -133,10 +139,11 @@ Each RIP MUST begin with a preamble in the following format, enclosed in a Markd ``` RIP: - Layer: (for Standards Track only) + Layer: (Standards Track only) Title: Author: <name> <email> - Author-Fingerprint: <PGP/GPG fingerprint> (optional) + Author-Fingerprint: <PGP/GPG fingerprint> (optional, paired with Author) + Discussion-To: <URL or short note> Status: <status> Type: <type> Created: <YYYY-MM-DD> @@ -147,16 +154,14 @@ Each RIP MUST begin with a preamble in the following format, enclosed in a Markd License: <SPDX identifier> ``` -The optional `Author-Fingerprint` field MAY be included by an author who commits to signing this RIP and any future amendments using the corresponding key. If included, the key MUST be retrievable via the repository's `SECURITY.md` or a public keyserver. The field is RECOMMENDED for Standards Track RIPs that affect consensus rules. Including the fingerprint constitutes an attestation of authorship and provides a cryptographic anchor that verifiers can use independently of GitHub's commit-signing infrastructure. - -The optional `Updated` field records the date of the most recent substantive revision to the RIP. It SHOULD be set when the specification, status, or normative content of the RIP is modified after initial merge; trivial edits (typographical corrections, link updates) MAY omit the update. When `Updated` is set, the date MUST follow ISO 8601 format (`YYYY-MM-DD`) and MUST be no earlier than `Created`. The `Updated` field is informational and does NOT replace the requirement for substantive revisions to be tracked via repository commit history. +`Author` and `Author-Fingerprint` may repeat (one pair per author). If `Author-Fingerprint` is present, the key MUST be retrievable via `SECURITY.md` or a public keyserver. `Updated` MUST follow ISO 8601 and MUST NOT be earlier than `Created`. --- ### File Format - RIP files MUST be plain Markdown (`.md`). -- Filenames MUST follow the pattern `rip-NNNN.md` where NNNN is the zero-padded RIP number. +- Filenames MUST match the pattern `rip-NNNN.md` (lowercase) where `NNNN` is the zero-padded number, located under `rip-NNNN/`. - RIPs MUST use UTF-8 encoding with Unix (LF) line endings. - Mathematical notation MAY use LaTeX inline (`$...$`) or display (`$$...$$`) syntax. - Code blocks MUST specify a language identifier where applicable. @@ -165,44 +170,45 @@ The optional `Updated` field records the date of the most recent substantive rev ### RIP Editors -RIP editors are responsible for: +Editors are administrators of this process. Editorial responsibilities do not imply protocol governance authority and do not include judging the technical merit of any RIP. Technical merit is judged by the broader Rincoin community and, for Consensus-Layer changes, by the running miners, full nodes, and economic users of the network. -- Assigning RIP numbers. -- Reviewing RIPs for format compliance and minimum quality standards. -- Maintaining the RIPs repository. -- Updating RIP statuses upon community consultation. +#### Editor responsibilities -RIP editors do NOT judge technical merit. That is the responsibility of the broader community and, for Consensus-Layer changes, the running miners and full nodes. +- Assign RIP numbers in the order PRs reach merge-readiness. +- Review submissions for format compliance, completeness of required sections, license, and absence of duplication. +- Merge passing PRs as `Draft` (or `Idea` if the author requests record-only publication). +- Update statuses on receipt of public PRs that cite the objective triggers defined in §RIP Status. +- Maintain the index in `README.md`. +- Maintain editor contact information in `SECURITY.md`. + +Editors MAY refuse to merge a PR on the following procedural grounds only: duplicate of an existing RIP, off-topic, plagiarized, irreconcilable format defects, missing required sections, or absence of a license declaration. Editors MUST NOT refuse a PR on the basis that they disagree with its contents. #### Appointment -The initial RIP editor is @Aevust <edu@aevust.org>. +The bootstrap editors of this process are Aevust and Takologi. Additional editors are added by majority vote of the sitting editors, following a public 14-day notice period during which any community member may comment. The notice and outcome MUST be recorded in `governance/editor-changes.md`. -Additional editors are appointed by the **Founder and Core Strategic Authority** following a probationary period of at least 90 days during which the candidate demonstrates technical contribution and good-faith engagement with the development community. Appointment requires concurrence of both the Founder and at least one additional Core Strategic Authority member. Community consultation serves an advisory role; final appointment authority rests with the Founder and Core Strategic Authority. +#### Author–editor recusal -This structure mirrors the practice of Bitcoin's BIP process (appointment by existing editors and project leadership, informed by community feedback) and Ethereum's EIP process (candidate identification by existing editors, trial period, technical merit verification), adapted for Rincoin's governance model. +When two or more editors are seated, an editor MUST recuse from procedural acts (merge, number assignment, status change) on any RIP they (co-)authored. Until the second editor is seated, this RIP and any other RIP authored by the sole editor SHOULD carry a visible "no independent editorial review" note. -#### Editor qualifications +#### Removal -Editors MUST demonstrate: +A sitting editor MAY be removed by majority vote of the remaining editors for any of the following: -- Technical competence in Rincoin protocol design or adjacent domains (cryptography, distributed systems, consensus mechanisms). -- Availability to perform timely reviews, ordinarily within 14 days of submission. -- Absence of undisclosed conflicts of interest with respect to proposals under review. -- A track record of constructive, good-faith engagement with the development community. +1. **Infrastructure coercion** — Using delegated or entrusted Rincoin infrastructure (seed nodes, Electrum servers, repositories, DNS entries, build systems) as leverage to obtain governance rights, compensation, editorial authority, or other benefits not established at the time of delegation. +2. **Non-technical coercion** — Coordinated threats or external pressure campaigns intended to influence protocol development decisions. +3. **Deliberate harm** — Intentional introduction of undisclosed defects, backdoors, or misleading specifications into RIP documents or protocol code. +4. **Material conduct violations** — Serious or repeated violation of the Rincoin Code of Conduct. -#### Disqualifying conduct +Removal decisions and their rationale MUST be recorded in `governance/editor-changes.md`. The community's ultimate check on editor conduct is the right to fork this repository. -The following constitute grounds for permanent disqualification from the editor role, or removal of an existing editor, upon determination by the Founder and Core Strategic Authority: +Editor contact information and current PGP/GPG signing-key fingerprints are maintained in `SECURITY.md` so that key rotation does not require amending this RIP. -1. **Infrastructure coercion**: Using delegated or entrusted protocol infrastructure — including but not limited to seed nodes, Electrum servers, repositories, DNS entries, or build systems — as leverage to obtain governance rights, compensation, editorial authority, or other benefits not established at the time of delegation. -2. **Non-technical coercion**: Coordinated use of threats, external pressure campaigns, or other non-technical means to influence protocol development decisions or appointment outcomes. -3. **Deliberate harm**: Intentional introduction of undisclosed defects, backdoors, or misleading specifications into protocol code or RIP documents. -4. **Material conduct violations**: Serious or repeated violation of the Rincoin Code of Conduct, including harassment, impersonation, or misrepresentation of authority. +--- -The disqualification criteria apply to both candidates for the editor role and sitting editors. A sitting editor found to have engaged in disqualifying conduct MAY be removed by decision of the Founder and Core Strategic Authority. The removal decision and its rationale MUST be recorded in a publicly accessible location — typically a dedicated file (e.g., `governance/editor-changes.md`) in the RIPs repository — to preserve historical accountability without amending this RIP for each personnel change. +### Signed Commits -RIP editors' contact information, including any current PGP/GPG signing keys used for verifying RIP-related communications and signed releases, is maintained in `SECURITY.md` at the repository root. This information is updated independently of this RIP and SHOULD be consulted for current key fingerprints. Decoupling key fingerprints from this Process RIP ensures that key rotation does not require amending the RIP itself. +Standards Track RIPs that affect consensus rules SHOULD have their final repository commit signed by an author whose key is listed in `SECURITY.md`. Editors SHOULD verify that, where `Author-Fingerprint` is present, the corresponding key is retrievable. Verification failures are signals to reviewers, not grounds for rejection. --- @@ -212,16 +218,11 @@ RIP editors' contact information, including any current PGP/GPG signing keys use rincoin-rips/ ├── README.md # Index of all RIPs with status ├── SECURITY.md # Editor contact info and signing key fingerprints -├── rip-0001/ -│ └── rip-0001.md # This RIP -├── rip-0002/ -│ └── rip-0002.md ├── rip-NNNN/ │ └── rip-NNNN.md ├── doc/ │ └── assets/ # Simulation results and supplementary images ├── governance/ -│ ├── core-role.md # Current Core Role assignments │ └── editor-changes.md # Role transition and removal history └── security/ └── *_public.asc # PGP/GPG public keys referenced by SECURITY.md @@ -229,157 +230,33 @@ rincoin-rips/ --- -### Signed Commits - -Standards Track RIPs that affect consensus rules SHOULD have their final repository commit signed by the author using a key listed in `SECURITY.md`. This provides cryptographic continuity between the published RIP and the author's identity claim, independent of the hosting platform's commit-signing infrastructure. - -Authors who include the optional `Author-Fingerprint` preamble field commit to maintaining a corresponding key in `SECURITY.md` for the lifetime of their authorship. Editors SHOULD verify, before merging a Standards Track RIP, that: - -- If `Author-Fingerprint` is present, the corresponding key is retrievable via `SECURITY.md` or a public keyserver. -- The merge commit (or, where applicable, a detached signature accompanying the PR) verifies under that key. - -Verification failures are not, by themselves, grounds for rejecting a RIP. They are signals to editors and reviewers that authorship attestation should be re-established before advancement past `Draft`. - ---- - -### Version Numbering and Core Role Governance - -Rincoin Core software releases and the human roles responsible for them are governed by an integrated scheme that links the protocol's long-horizon design philosophy (the ~400-year Proof of Rinne epoch) to practical software lifecycle management and personnel continuity. - -#### Core Roles - -The following four roles constitute the Core Strategic Authority of Rincoin: - -| Role | Responsibilities | -|------|------------------| -| **Core Technical Lead** | Lead protocol development; owner of the official GitHub repository; final reviewer and approver of Core software updates. | -| **Core Authority Lead** | Responsible for official infrastructure (domains, servers, public-facing channels) and overall strategic direction. | -| **Core Research Lead** | Responsible for protocol research, academic output, and whitepaper maintenance. | -| **Principal Architect** | Cross-functional support for the above three roles in development, research, and strategic activities. | - -A single individual MAY hold multiple roles simultaneously. Each individual casts exactly one vote in governance decisions regardless of the number of roles held. Vacant roles are excluded from both the numerator and denominator of any vote. - -The title of **Founder** is held by the original creator of the Rincoin protocol. The Founder title by itself is not a Core Role for voting purposes; however, the Founder MAY concurrently hold one or more Core Roles, in which case the Founder casts a vote in their capacity as a Core Role holder. - -#### Current Role Holders - -The current assignment of individuals to Core Roles is maintained in the authoritative file `governance/core-role.md` in the RIPs repository. Consult that file for the current record. - -As a reference point, role assignments typically change infrequently. Whenever a Core Role assignment changes, the `governance/core-role.md` file MUST be updated, and the change MUST be recorded in `governance/editor-changes.md` for historical accountability. - -The Core Role structure itself (the four roles and their responsibilities) is defined in this RIP and does not change except by RIP amendment. - -#### Version Numbering Scheme - -Rincoin Core releases follow a three-component versioning scheme: - -``` - v[GENERATION].[MAJOR].[MINOR] -``` - -- **GENERATION** — Incremented at each Proof of Rinne epoch boundary (approximately every 400 years, ~233,280,000 blocks). The current generation is `1`. -- **MAJOR** — Incremented for significant protocol upgrades, including consensus-layer changes (hard forks and soft forks) and substantial architectural modifications. MAJOR is an unsigned integer with no hard upper bound; implementations MUST NOT reject a version solely because MAJOR exceeds 255. -- **MINOR** — Incremented for routine maintenance, bugfixes, peer-services updates, and minor feature additions that do not require consensus changes. Analogous to Bitcoin Core's patch-version practice (e.g., 25.0 → 25.1). - -Associated tools and simulation suites (e.g., `rincoin-sim`) MAY use an extended four-component scheme: - -``` - v[GENERATION].[MAJOR].[MINOR].[PATCH] -``` - -where the first three components track the Core release the tool validates against, and PATCH increments for tool-internal fixes that do not correspond to a Core release change (e.g., `rincoin-sim` v1.0.6.1 is a sim-internal fix against Core v1.0.6). - -#### Version Authority - -The authority required to increment each version component scales with the number of distinct individuals holding at least one Core Role: - -| Distinct voters | MINOR | MAJOR / GENERATION | -|-----------------|-------|--------------------| -| 1 | ✅ permitted | ❌ prohibited | -| 2 | ✅ permitted | Unanimous (2/2) | -| 3 | ✅ permitted | Supermajority (2/3) | -| 4 | ✅ permitted | Supermajority (3/4) | - -When only one Core Role holder exists, MAJOR and GENERATION increments are prohibited until a second role is filled. This prevents unilateral protocol capture while preserving the ability to maintain the network through MINOR releases. - - -#### Succession - -If one or more Core Roles become vacant, the following priority -order applies. - -**Founder priority**: If the Founder is available, the Founder has primary authority to reconstitute vacant Core Roles directly, without requiring the steps below. The Founder's reconstitution decision SHOULD be recorded in `governance/editor-changes.md` for historical accountability. - -If the Founder is unavailable, role succession follows this strict priority order: - -1. **Designated successor (Deputy)** — Each role holder designates a successor in writing, cryptographically signed with their key listed in `SECURITY.md`. Role holders are strongly encouraged to maintain an active Deputy (e.g., Deputy Technical Lead) during normal operations to ensure seamless transition. - -2. **Core coordination** — Remaining Core Role holders convene and select a replacement by unanimous agreement. If unanimous agreement cannot be reached within **30 days**, the process escalates to Step 3. - -3. **Infrastructure Custodian fallback** — If Step 2 fails or all formal Core Roles are vacant, the official **Infrastructure Custodians** — defined as the registered holders of the official domains (`rincoin.org`, `rincoin.com`, `rincoin.net`) and the primary GitHub Organization owner — act as an emergency anchor. The Custodians reconstitute the Core Authority by unanimous agreement among themselves, subject to a **14-day public notice period**. Individual verbal objections during this period do not block reconstitution. If, however, the majority of the network actively rejects the Custodians' authority — such as by converging on an alternative software fork — the process escalates to Step 4. - -4. **Community consensus** — If infrastructure access is also lost, or the network explicitly rejects the Custodians' intervention, new leadership is recognized through rough consensus emerging from the network's established participants (miners, full-node operators, exchanges, and other economicactors). No formal voting mechanism is prescribed at this stage; legitimacy is determined organically by whether the network converges on the proposed leadership. This reflects the same trust model that Bitcoin employs in practice for analogous governance vacuums. - ---- - ## Rationale -### Why model after BIP-1/BIP-2 rather than EIP-1? - -Rincoin is a UTXO-based Proof-of-Work blockchain derived from the Bitcoin/Litecoin lineage. Its core data structures, consensus model, and developer tooling all share heritage with Bitcoin. Adopting the Bitcoin community's improvement-proposal format minimizes cognitive load for developers familiar with that ecosystem and preserves continuity with related specifications (e.g., MWEB's LIP-0002/LIP-0003). - -Ethereum's EIP-1 process is well-engineered for an account-based, smart-contract-centric chain with a different governance culture (e.g., the All Core Devs call cadence). Importing that process wholesale would mismatch Rincoin's architecture and community. +### Why model after BIP-1/2/3 rather than EIP-1? ---- - -### Why require Test Vectors and Reference Implementation? - -The single most common failure mode in cryptocurrency improvement proposals is specifications that are technically plausible on paper but ambiguous in implementation. Requiring concrete test vectors and a working reference implementation before advancing past `Proposed` ensures that the specification is unambiguously implementable. - -For Rincoin specifically, this requirement is reinforced by the existence of the [`rincoin-sim`](https://github.com/Aevust/rincoin-sim) repository, which provides a 1/1000-scale regtest environment for validating consensus changes prior to mainnet deployment. - ---- +Rincoin is a UTXO-based Proof-of-Work blockchain in the Bitcoin/Litecoin lineage. Adopting the BIP process minimizes cognitive load for developers familiar with that ecosystem, preserves continuity with related specifications (e.g., LIP-0002/LIP-0003 for MWEB), and avoids importing the governance culture of an account-based chain whose contributor model is materially different. -### Why integrate versioning with Core Role governance? +### Why thin statuses (BIP-3 style)? -The version-numbering scheme deliberately encodes the protocol's long-horizon design philosophy. The `GENERATION` component links software releases to the Proof of Rinne ~400-year epoch, ensuring that the names of releases themselves remind operators and developers of the protocol's regenerative timescale. +The status set is a tool for tracking documents, not a governance hierarchy. Each state corresponds to an observable fact (was it merged, does an implementation exist, is it deployed, has it been superseded). Keeping the set short makes the meaning of each state unambiguous, and keeps editors out of the role of judging readiness. -The `MAJOR / GENERATION` prohibition under single-holder governance is a deliberate fail-safe: it ensures that no individual — including the original Founder — can unilaterally execute a hard fork. The network can be maintained through `MINOR` releases by a single holder, but substantive protocol evolution requires distributed authority. This design recognizes that the integrity of a cryptocurrency protocol depends not only on its cryptographic primitives but also on the resilience of the human authority that maintains it. +### Why an `Idea` state in addition to BIP-3's set? -The MAJOR component carries no hard upper bound by design. Given Rincoin's philosophy of prioritising correctness over speed, the expected rate of MAJOR increments within a single ~400-year GENERATION is far below any practical limit. Should the development pace ever approach an upper bound, the community may introduce a successor scheme via a Process RIP without altering the GENERATION component. +Several documents already merged into this repository were published before any review or pre-RIP discussion took place. Marking them `Draft` would overstate their maturity. `Idea` is a holding state for such material, used only for documents already merged for record. New PRs should target `Draft` directly. ---- - -### Why one vote per individual rather than one vote per role? - -A vote-per-role scheme would over-weight individuals who hold multiple roles, particularly during the early phases of the project when role consolidation is unavoidable. The vote-per-individual scheme ensures that as the project grows and roles distribute across more people, governance naturally becomes more decentralized without requiring an amendment to this RIP. - ---- +### Why no central authority? -### Why the four-stage succession chain? - -Each successive step corresponds to a degraded operational state and is designed to ensure liveness (the system cannot deadlock indefinitely) while preserving safety (no individual can unilaterally seize authority): - -1. **Deputy** — Normal operations; succession is pre-planned and instantaneous. -2. **Core coordination** — Partial disruption; remaining authorities resolve internally, bounded by a 30-day timeout to prevent indefinite deadlock. -3. **Infrastructure Custodian fallback** — Catastrophic disruption; physical/digital asset control (domains, repository ownership) provides a concrete and verifiable anchor for emergency reconstitution. -4. **Community consensus** — Total loss of formal structure; the network falls back to the same informal rough-consensus model that Bitcoin employs when its leadership structures fail. - -The distinction between "verbal objections" (which do not block reconstitution) and "active rejection by converging on an alternative software fork" (which does) is critical. This ensures that individual fear, uncertainty, and doubt (FUD) cannot weaponize the notice period as a denial-of-service attack against legitimate succession, while preserving the absolute sovereignty of the network's economic and thermodynamic majority. - ---- +A RIP process whose editors can veto on technical merit is no longer a documentation process — it is a governance body. Bitcoin's experience over more than a decade shows that BIP-style governance works precisely because editors are interchangeable clerks and acceptance is determined by the running network. This RIP keeps that property. ### Why CC0? -CC0-1.0 places the document in the public domain, maximizing the freedom of downstream users (including derivative chains, academic citation, and educational reproduction) to incorporate RIP content without licensing friction. This matches the BIP convention. +CC0-1.0 places each RIP in the public domain, maximising downstream freedom (derivative chains, academic citation, reproduction) without licensing friction. This matches BIP convention. --- ## Backwards Compatibility -This is a Process RIP and introduces no consensus-layer changes. It applies to all future RIPs and retroactively normalizes the format of any pre-existing draft RIPs (specifically the prior drafts informally circulated as "RIP-0002 Customized Halving" and "RIP-0003 MWEB Integration", which are superseded by the formal RIPs published under this process). - -The Version Numbering scheme codifies practice already in effect for Rincoin Core releases (v1.0.5, v1.0.6) and does not retroactively rename prior releases. The four-component extension (`v[GENERATION].[MAJOR].[MINOR].[PATCH]`) for associated tools such as `rincoin-sim` is likewise compatible with existing tool releases (e.g., rincoin-sim v1.0.6.1). +This is a Process RIP and introduces no consensus-layer changes. It supersedes the prior draft of RIP-0001 in this repository. Other previously merged RIPs whose statuses or wording do not conform to this revision are updated in a separate set of PRs; their substantive specifications are not modified by this RIP. --- @@ -395,24 +272,16 @@ Not applicable (Process RIP). ## Security Considerations -The RIP process itself is not a security-critical component, but the quality of RIPs produced under it directly affects the security of the Rincoin protocol. The requirement for explicit Security Considerations sections in all Standards Track RIPs, combined with the requirement for a reference implementation prior to activation, is intended to surface security concerns before deployment. - -Editors MUST reject RIPs that omit a Security Considerations section, even when the author asserts that no security implications exist; the absence of implications is itself a claim requiring justification. - -The Core Role governance structure introduces additional security considerations beyond the RIP process itself: - -- **Single-holder protocol capture**: Mitigated by the explicit prohibition on MAJOR and GENERATION increments under single-holder governance. A solitary Core Role holder cannot unilaterally introduce consensus-layer changes. -- **Sybil attacks on succession**: The Infrastructure Custodian fallback resists Sybil attacks by tying authority to verifiable physical/digital asset control (domain registrations, GitHub Organization ownership) rather than to claims that can be cheaply forged. -- **Denial-of-service via objection campaigns**: The "verbal objections do not block" rule in Step 3 of the Succession procedure prevents an adversary from weaponizing the notice period to indefinitely stall legitimate reconstitution. -- **Key compromise of Core Role holders**: Mitigated by the `SECURITY.md` key-rotation procedure, which is decoupled from this RIP so that key rotation does not require amending the governance specification. +- **Editor capture.** Mitigated by editor plurality, the strict procedural-only scope of editorial action, the author-recusal rule, and the community's ability to fork. +- **Key compromise.** Mitigated by maintaining current fingerprints in `SECURITY.md`, decoupled from this RIP so that rotation does not require amendment. +- **False claim of network adoption.** Mitigated by the explicit "Publication ≠ adoption" disclaimer and by requiring objective evidence before advancement to `Active` or `Final`. +- **Off-chain leverage as governance.** This RIP recognises only the documentary process. Control of off-chain assets (domains, hosting, build systems, social channels, exchange listings, seed nodes) confers no authority over the Rincoin protocol; the protocol is what nodes run. --- ## Acknowledgments -This RIP draws extensively from BIP-1 (Amir Taaki, 2011) and BIP-2 (Luke Dashjr, 2016) for the Bitcoin Improvement Proposal process, and from EIP-1 (Hudson Jameson et al.) for clarifications on workflow and editor responsibilities. The structure of the RIP types and statuses is harmonized with both communities' conventions to maximize interoperability of cross-chain technical discourse. - -The Version Numbering and Core Role Governance section was refined through structured deliberation with Gemini (Google DeepMind) and Claude (Anthropic) in their capacities as members of the Core Strategic Authority, with successive iterations addressing Sybil resistance, deadlock avoidance, and the distinction between verbal objection and active network rejection. +This RIP draws from BIP-1 (Amir Taaki, 2011), BIP-2 (Luke Dashjr, 2016), and BIP-3 (Murch, 2024) for the Bitcoin Improvement Proposal process, and from EIP-1 for incidental wording on editor responsibilities. --- diff --git a/rip-0011/rip-0011.md b/rip-0011/rip-0011.md new file mode 100644 index 0000000..a1c24a7 --- /dev/null +++ b/rip-0011/rip-0011.md @@ -0,0 +1,80 @@ +``` + RIP: 11 + Title: Rincoin Core Versioning Scheme + Author: Aevust <edu@aevust.org> + Author-Fingerprint: ED20 B635 4EE4 526D 01F8 3B53 8B6E 3BF4 5C71 4ECA + Author: Takologi <takologi@proton.me> + Author-Fingerprint: FEE1 ACA5 2C65 FF3E BF31 818C B559 5E17 52BC 2A82 + Discussion-To: TBD — no public pre-RIP discussion has taken place yet. + Status: Draft + Type: Informational + Created: 2026-05-20 + Requires: RIP-0001 + License: CC0-1.0 +``` + +--- + +## Abstract + +This RIP describes the version-numbering scheme used by Rincoin Core releases and by tightly coupled tools (such as the `rincoin-sim` regtest harness). It is informational: it documents existing practice and recommends a convention for future releases. It does not propose any consensus change. + +--- + +## Motivation + +A predictable version-numbering scheme helps node operators, miners, wallet developers, exchanges, and tool maintainers reason about the scope of a release at a glance. Aligning the scheme with the Bitcoin Core convention keeps it familiar to contributors with a Bitcoin background. + +--- + +## Specification + +Rincoin Core releases use a three-component version: + +``` +v[MAJOR].[MINOR].[PATCH] +``` + +- **MAJOR** — Breaking changes at the protocol level: consensus-layer changes (hard forks and soft forks) and other substantial architectural modifications. +- **MINOR** — Significant but non-breaking changes: considerable architectural modifications that do not change consensus or the wire protocol, new functionality, or significant performance work. +- **PATCH** — Routine maintenance, bug fixes, peer-services updates, and minor feature additions. PATCH releases MUST NOT touch consensus rules. + +Tools and simulation suites that are tightly bound to a specific Rincoin Core version MAY use a four-component scheme: + +``` +v[MAJOR].[MINOR].[PATCH].[BUILD] +``` + +The first three components track the Core release the tool validates against; `BUILD` increments for tool-internal fixes that do not correspond to a Core release change. Example: `rincoin-sim v1.0.6.1` is a sim-internal fix against Core v1.0.6. + +Decisions about specific version numbers belong to the active Rincoin Core maintainers and are outside the scope of this RIP. + +--- + +## Rationale + +The scheme mirrors Bitcoin Core's longstanding `MAJOR.MINOR.PATCH` practice. It is intentionally narrow in scope: it labels releases, it does not allocate authority. Earlier drafts of this material (which lived inside the previous RIP-0001) coupled versioning to a project-governance hierarchy; that coupling is dropped here. + +--- + +## Backwards Compatibility + +This RIP is informational and codifies existing practice for Rincoin Core releases (v1.0.x) and for `rincoin-sim` builds. It does not retroactively rename prior releases. + +--- + +## Security Considerations + +None directly. The scheme does not change software behaviour. The clear separation of `PATCH` from `MINOR` and `MAJOR` is intended to reduce the risk that a security-only release is mistaken for a feature release. + +--- + +## Acknowledgments + +The scheme follows Bitcoin Core convention. The material in this RIP was originally drafted inside RIP-0001 and moved here when RIP-0001 was scoped down to the proposal process. + +--- + +## Copyright + +This document is licensed under the Creative Commons CC0-1.0 license. diff --git a/security/Takologi_0xB5595E1752BC2A82_public.asc b/security/Takologi_0xB5595E1752BC2A82_public.asc new file mode 100644 index 0000000..69ddbb1 --- /dev/null +++ b/security/Takologi_0xB5595E1752BC2A82_public.asc @@ -0,0 +1,51 @@ +-----BEGIN PGP PUBLIC KEY BLOCK----- + +mQINBGoOBnYBEADqcCmR7Szb7xgNOiv73arPEFLtz1WyT4CRELc7seKfwb+enwlw +Y95Q2zbnraNDNCU/VjXJXAErvJssxMQeFW+7wRSCBovpUkfoa5S7vXFdMzg72uAG +MVPZ0t0aAB6TfXCGf8YoaQ/a+oOyE+tL28aXFLODzUf/NgMT51AVl6bkh7dWW0aX +FcgCOPUif9jew6dfrOMgzO8CY5S0TI26eMN8F286ofFyuiyvNTAOswwfPnKmx39t +WaqpX62iiCN16j5UNI8Dxwl0HtkF3smKRq9vX9kH43fkBHN7Q3FJUWllvtlfGo7a +s06hBu2umJoDaz3soo4mNFjUGTxDE7BYsSfW1VbejF+wKk5QfhGZGqPwjKH3D9Bv +hkSPawYans91XBuAc0zOdWyudYxQTtdaJmH75ivlCcljbDHDhaQsbbzNjvfut3cs +CKSEXfv2TjyD/mMj/ciIVGb55vXhMO9OPHUHj1uRxz4Pv7wscOYWcbudSrCi3wVC +kncAYE0ObRrSI9A70wm9EM85YNqRstGTK8XgYsIRm2iZBeXdaL8Rf5MaB1sMlMzx +UTayT6mnI3yuhcZcHKYUxbSFb/r3KqDEAOAOB67cXR0XZRK2AxrrdMGOjrI0IwWr +9NSt8Gguc1u/dgE88bd7VlYZaMv6dDEIH88RBObDXzv6KyDB+1EyXFgHUwARAQAB +tB1UYWtvbG9naSA8dGFrb2xvZ2lAcHJvdG9uLm1lPokCTgQTAQoAOBYhBP7hrKUs +Zf8+vzGBjLVZXhdSvCqCBQJqDgZ2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA +AAoJELVZXhdSvCqC77EQAKnCmQ68wn77FYUUr0ajOUT+FlkThBXODQywoJRYui60 +QwvzTnOB5dD804f86wcTa+y88AIq/4vTAi1HcmIdnoGJkPFaLdji6vgBn1J19P7M +gsn5CUQcArMaAEruQLXJQPEFXR9KfHcq/Ec4ct75xTNwH3NIirDg/FR+ZriYWT0U +YuvqTKa7rJvJYC4Qz7uU/WlwIrCksNxISKFE/E+ocPqD7qB6+M3ors045RrQIBgq +xMhXA/pGy72Ay03M8eTxPhc7QUqdDI2P08S5xVYjfx4TPFGXbiPomWsbkqYxqAK7 +6NjzFzX8i2/vjSRo+pQC8NXDnJ6ZUlGoIk8Xb7/ah+pblFsZDgsCuhsaITjKiU/u +MhOPdTDXp0bbP6dxnX5Qs8r6/KxRCGRBpu+g1AnfVO8bJdjx5AgA3HuI8pt2Tpjo +aPvW+iXJ7kBXyUKrP5p3RMWudQQiH8rldLQl24GtZjYpO3GPTfPk6L1rFSWcKPc9 +JMDdZMfskA/eIrQqAjxq7VPzRYyw0UfhA5Wm7oHpona3w+rmQNAKBUxPyd1SBFU/ +ZNPTeBfzgz6guYodosBx9sVJRV1YHsvzKlS+awTsiheFqz7pw7SaRJ+VVB4zy1tP +eAhO9HEzNkNtCxOUzBHEr5yp8lbUmWcqI7fQEEIkxo2AKm1c8iQtx15J7An/stP/ +uQINBGoOBnYBEADkugaj8QRkpJmbliRMhLIc8RaMByJNLEoWDUtnplgaOc2QT5N1 +sSRmYzn0pQ+oh0y3WeRZCS5Ua61rghXebzZvZ0yWF5E0IzDjMYffKRgNNjcYi+Ap +Y07Afu9S2rW+DRJacqxp4QEWjgqeek7cXQfcDJosMLQe2aygr8zOuQdfnPeVaVfT +CzOS9NOpDJFNIloqHa9wGG9WeTo4i/Q3Q87XPfq6s6X+xdlw84y3wL8cYWn8VYZx +vt7vytvE8/9vnlVeRsrT6yMmLzLzBRVopf2UWo9RXNay8ZGNuUY1x7AKS9FcCfka +CjsEOqOMpay24te6TfFzKACdbwWwN+rx4vCp4OPsZlh5F9ystZ4ZT9nRC20Dm3iM +77bisloXGBRjL7HNx6WnMOCcdsGMOclR5GGZiZKpgYK0i29snmSrrn55pmyhIN9j +oE8Ii5oBdx7cYIfxlb2Y1iWGJlVWGIUBNrmfo3bQqCDVan3amFIo6pnGfbBjE9DM +YCj1WjJ09RvJjZpSPCnCk1w4BnGib1O6DiLf7RcW4DlHwPf9E+9JqTZBlqPw4uFW +m4i0lbsYLSqHqH+1S5Ci5aNKNCUzCpIOq+y9VHFOfPAyelHv0EwFZ403mZpfG/pN +dU2NiyMvpMNjH4JsiUJwmQKKTg8ELFRJ44JJWY4/RKJO45bfgwBLi2MJwwARAQAB +iQI2BBgBCgAgFiEE/uGspSxl/z6/MYGMtVleF1K8KoIFAmoOBnYCGwwACgkQtVle +F1K8KoKVxA//eoPA6Dvq2Cj+EFS/letBz1hj1vYO1o76MFV+4hVa4OqHDcSmAgyh +/OT/OJpqji8Pqfe+zqXLqj7IaLe+sYLVoTi39ikYErANK1L331ghFgvZR7bN9zK4 +8iopPrSnIA3OeYe8rk0wY0lJZXw0F+29Ud14qMV+n1gO3L516+kiC4VDiZ6vDteS +k7/sdxpfRy9wKju5BheiOXJqZjPs8vnp/8+Gxq67IRButcABP5VP9aYlLVGLqUS8 +tIjg/Iuw/MEMl9MM2iZC5ezXhtkp0F3e4nkBe3W69bhkoiRmZl7l0SWq7RNM1z3i +i9lxJtpqGNWwlYyZj54Vd13pJwwZ8rC56yjwtvziBVZPuohDpaxC2dsKITPpYAk2 +TZN8fYrqUtLX2xlSAl3isExPKPn5NTlIPvj643wHG1DOAZ5/MV8KUa/grSeQuyk6 +Jz/aqstnQqGYW9BvRng4mjT7og86Y+3Iup1ER8B0fm0CXsKiHd9Mse69ntX5epEi +lc5U1dLLnXzxYZqNOBQbsrZAY9VgkFklRmJp5hfTgb8yhYIn5aGwIfy18J2XbrMx +NZKZoRFQh4EvN7ZmGcyiDZ4DCLzZDkJdTzXzdIIw7f6L/gSENufnVONEQnb0sbTI +UgsgTc51tsMZBtZBcQKKzHCMKNZkdCAi8aVZFHYcY97ZiuJhIOkwfTs= +=CMVs +-----END PGP PUBLIC KEY BLOCK-----