User:Gmaxwell/features

From Bitcoin Wiki
Revision as of 00:58, 1 February 2012 by Gmaxwell (talk | contribs)
Jump to: navigation, search

Features I want

Core user-facing client features

  • Type-2 deterministic wallets
  • Multi-wallet (including watchmode wallets)
  • disk corruption robust wallet storage
  • Peer management RPCs (peer info (last connect, version, transaction stats, blocks stats), add, remove)
  • A pseudo-cli interface for the GUI. e.g. file->console
  • Thin client mode
    • Should be able to run many bitcoin-cli bitcoin-qt instances over the network against a single trusted bitcoind network node
  • Offline wallet— BIP10ish
  • Ability to cancel a transaction if blocks have passed and it hasn't been mined. Canceling should put the transaction into 'hold' mode for many hours (several days?) before making its outputs available for respending, perhaps a resend-with-fee option that requires all outputs to be the same (except perhaps change) that can be executed faster.
  • Async RPC

Behind the scenes wallet improvements

  • Transaction queuing (to improve coin selection and allow the use of sendmany without explicitly asking for it)
  • Smarter coin selection (minds fees!), general MILP solver is probably too much. :)
  • Better anonymity (avoid cross-linking), but multiwallet helps
  • Wallet sweeping (avoid jagged coins, get excess inputs destroyed when you have a chance)

Features to avoid inefficient uses of the network:

  • Merged mining notary service, validation in client
  • Detached transaction signatures to prove payment/identity (avoids 'green address' privacy lost and bloat)
    • Payment protocol too, but it's not enough alone
  • Separate network for message relay? Keep people's IM traffic out of the blockchain? (ugh)

Network layer improvements

  • NTP integration (if trusted, healthy, ntp— use instead of network time)
  • Better network time intelligence
  • Roaming connections (reduced attack risk, learn about peers faster)
  • Lightweight node announce to (dns)seeds?
  • Priority relaying (measure which nodes are most 'useful' based on blocks/txn-w-fees then relay to them before other nodes, relay to them first— move to front on good actions probably enough)
  • Authenticated peers for addnode so a network attacker can't isolate you without your knowledge
  • Peer management RPCs (peer info (last connect, version, transaction stats, blocks stats), add, remove)
  • IPv6
  • Onion-cat style onion peers
  • Tor integration (request its own hidden service via the control port)
  • Blockchain over satellite receiver (peak blockchain datarate 14kbit/sec, sat bandwidth isn't that expensive)

Backend security

  • scrypt wallet encryption
  • Network sanity checks. Trusted peers down, network very slow? don't take txn out of unconfirmed.
  • timewarp fix
  • More DOS/network attack hardening (time skewing, memory exhaustion, etc)
  • Ability to mark keys as compromised and enable autosweeping of inputs that are sent to them
  • Provable notice of doublespend (when a node sees a doublespend it prepares an alert indexed by the doublespent output, including at least two spends of it, and floods it, if a client receives a such a notice for a transaction sent to it, it shoots fireworks and greatly delays showing it as confirmed)

Validation performance

  • Fast chain sync (fix database stupidity)
  • Read only chain summaries for old history
    • Compressed blockchain history, decompress to build the summary preserving zero trust
  • Backwards header sync, then fill blocks
  • Operate as a lite client until synced up

Mining

  • P2Pool
  • Simplistic GPU miner (bitcoin screensaver?)
  • Smarter tree rebulding
  • Share in lieu of TXN fees
    • No funds for anti-dos fee? Generate at least a diff N share with a commitment to the txn in the coinbase (paying whomever), distribute along with the txn (allows us to keep mining as our singular POW system, but still use small amounts of it without a pooling solution that works at cpu miner levels!)
    • Directly pay pools txn fees via computation, attempting blocks that pay them.
  • Directed graph fee/priority computation (a later txn can pay fee for parents, must avoid memory DOS)

Fee tweaks

  • Consider net unspent output change (txn which decrease the unspent outputs on the network should have fewer fees)
  • NAK for dropped transactions so clients (sometimes) know when there txn aren't making progress