Skip to content

Lite wallet support proposal #28

@akumaigorodski

Description

@akumaigorodski

Lite wallet support: script-hash sync, Utreexo proofs, and mobile-friendly state updates

I want to propose a few full node additions that would make it possible to build a lite BitAssets wallet library (intended for mobile wallets, edge, resource constrained devices etc).

The main goal is for a lite wallet to be UTXO-centric: it should be able to know its own UTXO set, rebuild its balance, and prove it locally without running a full node. The most important full-node change for this is Utreexo support. For lite wallets this enables compact balance/state proofs; for full node it also creates a future path toward safely pruning of old transaction data, and for now an Utreexo forest maintenance can happen in parallel to current logic.

At a high level, I think the node should support a protocol like this (LW is lite wallet, FN is full node):

  1. On connect via QUIC socket, the LW says which script hashes it is interested in, up to some limit (privacy-friendly options like compact filters and whatnot can be implemented later, we should start with working basics).

  2. Then LW asks for all related state starting from a given bitAssets block hash (genesis hash for initial sync).

  3. The FN responds with a delta state update message which has:

    • UTXOs relevant to LW script hashes which were created during given period.
    • confirmed transactions for the given period (may be incomplete, or none at all due to pruning).
    • Utreexo state/proofs for FN current chain tip (having this, LW can add new UTXOs to its state and remove spent ones which are no more in Utreexo roots).
  4. After subscribing, the LW also receives live notifications when:

    • a related transaction enters the mempool: that transaction is sent to LW.
    • a related transaction is confirmed in a block: a new delta state update message is sent to LW.

I am opening this issue to find out if this general direction makes sense before getting too deep into message formats or implementation details. If it does, perhaps with some more appropriate changes, then I'm willing to handle all the work and provide related PRs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions