Developer Update #1 – Network Prototype & Transaction Flow

2026-01-28

Status: Active prototype development (local testing environment)

Overview

This update documents early implementation work on the Bitcoin Everlight network prototype. The focus of this phase is validating the core transaction life cycle, node behaviour, and internal data flow prior to public node on boarding and broader test activity.

Development at this stage is centred on correctness, determinism, and observability rather than throughput optimization or consensus finalization.

This work builds directly on the transaction and architecture concepts outlined in the Everlight Whitepaper.

---

Scope of This Update

The following components are actively being implemented and tested in local environments:

• Lightweight transaction model

• Deterministic transaction serialization

• Signature-based validation

• Node-side mempool handling

• Fee and nonce enforcement

• Transaction broadcast interfaces

• Anchoring interface stubs (non-final)

This update does not cover consensus, economic finality, or Bitcoin settlement mechanics, which remain under active design.

---

Transaction Model (Prototype)

The current prototype uses an account-style transaction model with explicit nonce tracking. This approach simplifies validation during early testing and enables predictable transaction ordering within node mempools.

Each transaction includes:

• Sender public key (Ed25519)

• Recipient identifier

• Amount

• Fee

• Nonce

• Optional memo

• Detached signature

Transactions are serialized deterministically prior to signing to ensure reproducible transaction identifiers and prevent malleability during propagation.

---

Reference Transaction Structure

type Tx struct {
    FromPubKey string `json:"from_pubkey"`
    To         string `json:"to"`
    Amount     uint64 `json:"amount"`
    Fee        uint64 `json:"fee"`
    Nonce      uint64 `json:"nonce"`
    Memo       string `json:"memo"`
    Sig        string `json:"sig"`
}

This structure represents the minimal payload required for local validation and relay during the prototype phase.

---

Signing & Verification Flow

Transactions are signed client-side using Ed25519. The signature covers all transaction fields except the signature itself.

Deterministic Signing Payload

func (t Tx) signingPayload() ([]byte, error) {
    type payload struct {
        FromPubKey string
        To         string
        Amount     uint64
        Fee        uint64
        Nonce      uint64
        Memo       string
    }

    p := payload{
        FromPubKey: t.FromPubKey,
        To:         t.To,
        Amount:     t.Amount,
        Fee:        t.Fee,
        Nonce:      t.Nonce,
        Memo:       t.Memo,
    }

    return json.Marshal(p)
}

This ensures that:

• All nodes compute identical transaction hashes

• Signatures remain verifiable across the network

• Transaction IDs are deterministic

---

Validation Rules (Current)

Upon receipt, nodes perform the following checks:

1. Public key format validation

2. Signature verification

3. Nonce monotonicity

4. Minimum fee enforcement

5. Amount sanity checks

func (t Tx) Verify() error {
    pub, _ := hex.DecodeString(t.FromPubKey)
    sig, _ := hex.DecodeString(t.Sig)

    payload, _ := t.signingPayload()

    if !ed25519.Verify(pub, payload, sig) {
        return errors.New("invalid signature")
    }

    if t.Amount == 0 {
        return errors.New("amount must be > 0")
    }

    if t.Fee < 1 {
        return errors.New("fee too low")
    }

    return nil
}

These rules are intentionally conservative and will evolve as network economics and spam resistance mechanisms mature.

---

Node Mempool Behavior

Nodes maintain an in-memory mempool with bounded size limits. Incoming transactions are:

• Validated immediately

• Indexed by sender

• Ordered by nonce

• Retained until inclusion or expiration

At this stage, mempool eviction and prioritization logic remains simple and deterministic to aid testing and observability.

---

Transaction Broadcast (Prototype)

The prototype node exposes basic interfaces for transaction submission and relay:

• POST /tx – submit a signed transaction

• GET /mempool – inspect pending transactions

• GET /health – node liveness

• POST /peer – peer registration (testing only)

Peer-to-peer gossip is currently implemented via explicit broadcast calls and will be replaced with a more robust peer discovery layer in later iterations.

---

Anchoring Interface (Stub)

While Bitcoin anchoring is a core design objective, the current prototype implements only an anchoring interface stub.

This stub defines:

• Commitment generation hooks

• Batch boundaries

• Anchor submission triggers

No Bitcoin transactions are generated at this stage. This separation allows transaction flow and node behavior to be tested independently of settlement design.

---

Observability & Instrumentation

During testing, nodes emit structured logs for:

• Transaction acceptance and rejection

• Signature verification failures

• Nonce conflicts

• Mempool state changes

This instrumentation is critical for identifying edge cases prior to public test phases.

---

Current Limitations

The following limitations are acknowledged and intentional at this stage:

• No consensus or finality guarantees

• No persistent state storage

• No Bitcoin settlement

• No public incentives

• No performance optimization

The goal of this phase is correctness and clarity, not throughput.

---

Next Development Focus

Work planned for the next development phase includes:

• Persistent state storage

• Transaction batching logic

• Anchor commitment construction

• Improved peer discovery

• Public node onboarding scaffolding

• Expanded test coverage

These items will be documented in subsequent developer updates.

---

Closing Notes

This update reflects active development work and represents an early-stage implementation intended for testing and iteration. Interfaces and logic described here may change as design decisions are finalized.

Future updates will continue to document progress with a focus on transparency and technical clarity.