done:
- update uint64 (no need negative numbers in timestamp)
- fixed repeated Vote votes
- renamed expiration_timestamp and its comment
- modify number of rounds to votes
This PR continues work from PR #158 and PR #173, and introduces a new
**Section 9: Security Considerations** to the Mix Protocol RFC. It
formalizes the protocol’s core guarantees, trust assumptions, and known
limitations.
### New Section Added
Structured Section 9 with the following subsections:
- [x] **9.1 Security Guarantees of the Core Mix Protocol**
Defines sender anonymity, metadata protection, and statelessness
guarantees.
- [x] **9.2 Exit Node Trust Model**
Trust assumptions at the final hop:
- [x] `9.2.1 Message Delivery and Origin Trust`
- [x] `9.2.2 Origin Protocol Trust and Client Role Abuse`
- [x] **9.3 Destination as Final Hop**
Optional deployment model where the destination operates its own Mix
instance to eliminate exit-level trust.
- [x] **9.4 Known Protocol Limitations**
Clearly outlines out-of-scope threats:
- Undetectable node misbehavior
- Lack of built-in retries or acknowledgments
- No Sybil resistance
- Vulnerability to DoS attacks
### Key Improvements
- Clearly delineates what the Mix Protocol guarantees and what it leaves
to external systems.
- Formalizes the exit trust boundary, a key concept for downstream
applications.
- Introduces an alternative destination participation model.
- Enables future discussions around accountability, reliability, and
Sybil resistance.
---------
Co-authored-by: Prem Chaitanya Prathi <chaitanyaprem@gmail.com>
This PR builds on PR #173 and completes the remaining construction and
runtime processing logic in `Section 8` of the Mix Protocol RFC. It
finalizes the last steps of packet construction (`Section 8.5.2 step 3.
e–f`) and introduces the complete mix node handler logic in `Section
8.6`, including intermediary and exit processing.
It clearly separates construction, role determination, and processing
logic.
### Changes Introduced in This PR
- **8.5.2 Construction Steps (Final Steps Added)**
- Sphinx packet construction
- [x] Assemble Final Packet
- [x] Transmit Packet
- **8.6 Sphinx Packet Handling**
- [x] **8.6.1 Shared Preprocessing**
- Derives session key, validates replay tag and MAC, decrypts
header/payload
- [x] **8.6.2 Node Role Determination**
- Inspects decrypted header prefix and padding to classify node as
intermediary or exit
- [x] **8.6.3 Intermediary Processing**
- Parses next hop address and mean delay
- Updates ephemeral key and routing fields
- Samples actual forwarding delay and transmits packet
- Erases all temporary state.
- [x] **8.6.4 Exit Processing**
- Verifies payload padding and extracts destination address
- Parses and validates application-layer message
- Hands off to Exit Layer along with origin protocol codec and
destination address
### Highlights
- Explicit role determination via zero-delay and padding inspection
- Fully decoupled construction and handling logic
- Forwarding delay behavior updated:
- Sender selects per-hop mean delay
- Mix node samples actual delay using pluggable distribution
---------
Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>
adding done:
- multi steward support sections such as: consensus types, big and small
type flows
- new two de-mls term epoch and backup steward
- violation list section
- who can initiate the consensuses
- deterministically creation of the steward list (against biased list)
- order of the consensus messages
- adding member-id as 160 bit id
- adding flexible committing for multiple steward
- unifying the commit among multiple committing for specific epoch
- clarifying minimum number of steward list s_min and the scenario that
group member number getting below this
next (in a separate PR)
- introducing peer scoring (currently we only kicked off malicious
members)
- anti deadlock mechanism in case of non-active steward (even if the
committing is flexible now)
- identifying the format of dishonesty evidence
---------
Co-authored-by: Ekaterina Broslavskaya <seemenkina@gmail.com>
Co-authored-by: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com>
Added SDS-R, an (optional) extension of SDS to allow for coordinated
repair of missing messages over a limited time window.
It functions by allowing subgroups of participants to rebroadcast
dependencies that were reported missing by other participants. As with
the rest of SDS, it aims to scale to larger groups first and could
likely be simplified for 1:1 or small group chats. To prevent an
explosion in repair requests or broadcast storms, it uses backoff timers
to prevent multiple participants from performing the same action (either
request a repair or rebroadcast in response to a repair request) in a
probabilistic manner.
Note that what is still missing is a specified recommended way to use
SDS-R in conjunction with retrieving missing dependencies from Store
nodes.
---------
Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com>
Lamport timestamps should remain close to current time (in milliseconds)
for new joiners to be able to have their messages ordered reasonably
close to other messages in the channel.
This means that:
- the `timestamp` field should be large enough to accommodate
millisecond resolution timestamps, i.e. `uint64` (see
https://github.com/vacp2p/rfc-index/pull/195 for reasoning)
- the lamport timestamp should be updated before sending _each_ message
to `max(timeNowInMs, current_lamport_timestamp + 1)`.
The current spec only indicated that Lamport timestamps should be
_initialised_ to current time, which means that the logical timestamp
would soon drift from current time.
Changed Lamport timestamp initialization from nanoseconds to
milliseconds. The current time in nanoseconds exceeds JavaScript's
Number.MAX_SAFE_INTEGER, making nanosecond precision unsuitable for
JavaScript implementations. Milliseconds provide sufficient precision
while remaining well within safe integer bounds for decades to come.
This simple, scalable and decentralized consensus is for using in
decentralization MLS RFC.
todo:
- [x] solve lints
- [x] refine the RFC: adding liveness and time expiration section, also
default counting silent peers (peers that dont participate the voting)
- [x] add references
- [x] add license
- [x] first round reviewing
- [x] second round reviewing
- [x] last round review
---------
Co-authored-by: Ekaterina Broslavskaya <seemenkina@gmail.com>
This branch contains 2 new RFCs:
1. An RFC describing the secure 1-to-1 communication channels;
2. An RFC describing the MLS and the decentralized MLS.
---------
Co-authored-by: Ekaterina Broslavskaya <seemenkina@gmail.com>
Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>
