Transaction Optimization

Caching payment paths for reuse

  • both used and unused

Optimizing for cost

  • how? doing it explicitly requires knowledge of account units
  • might be done implicitly by tracking which payment paths have been chosen in the past and keeping a kind of pagerank for exchanges
  • allow client to indicate whether to optimize for speed or for cost

Caching client account data

  • client might specify available credit for accounts and exchange rates between accounts
  • data could be specified to expire, or could be good indefinitely until next client update
  • client could push data, or specify a URL to pull new data when it expires
    • either of these models might be simpler to implement for the client than the query/authorize/commit callback model... maybe we should consider starting with these instead?
    • client-initiated push-pull only allows client to avoid running an HTTP server
    • client may or may not wish to confirm each transaction before it is committed
  • server could push account entries back to the client, or client could pull entries from server for reconciliation
    • server would have to keep a balance since the last reconciliation
    • reconciliation could be "hard", meaning server balance is reset to zero, or "soft", meaning it isn't
    • reconciliation + setting new account & exchange data should be an atomic transaction, otherwise transactions that would otherwise affect the client's decision-making might slip in between the two