Difference between revisions of "Wallet protocol"

From Bitcoin Wiki
Jump to: navigation, search
m (Explanation)
Line 5: Line 5:
  
 
Considering a complete BitCoin user setup, you have the following components:
 
Considering a complete BitCoin user setup, you have the following components:
* Peer -- Maintains connections with the BitCoin network, and relays BitCoin traffic based on policies.
+
* Peer/Node -- Maintains connections with the BitCoin network, and relays BitCoin traffic based on policies.
 
* Wallet -- Maintains private key database, and controls balances for the user.
 
* Wallet -- Maintains private key database, and controls balances for the user.
 
* UI -- End-user interface. Could be a wx/Qt/GTK GUI, CLI, Android app, iPhone app, etc...
 
* UI -- End-user interface. Could be a wx/Qt/GTK GUI, CLI, Android app, iPhone app, etc...

Revision as of 15:39, 3 March 2011

This is a project to define a new wallet protocol addressing problems with the current JSON-RPC implementation in bitcoind. Please feel free to make edits. If you disagree with something, turn it into a "debate".

Explanation

Considering a complete BitCoin user setup, you have the following components:

  • Peer/Node -- Maintains connections with the BitCoin network, and relays BitCoin traffic based on policies.
  • Wallet -- Maintains private key database, and controls balances for the user.
  • UI -- End-user interface. Could be a wx/Qt/GTK GUI, CLI, Android app, iPhone app, etc...
  • Miner -- Tries to solve blocks for the wallet.

The Peer communicates with other peers over the current BitCoin protocol. The Wallet commands the Peer over that same protocol, but only talks to its own Peer (not other peers). The protocol described herein is to be used for communication between the UI and Wallet, and also between the Miner and Wallet.

Requirements

  • Never use human-formatted data (for example, use base bitcoin units, not Decimal BitCoins nor Tonal BitCoins, which be left to the GUI)
  • Don't require polling (for example, broadcast events for new transactions, or changes to current "work")
  • Cooperative mining (see below)

Debates

Binary or plaintext

  • Binary is more efficient to parse and create
  • Plaintext is easier for humans to debug

Cooperative mining

The protocol should support submitting completed blocks, such that it can get (just) addresses from an upstream pool to generate to, and send all completed blocks to that pool for verification and counting (and possibly submission to the network). This can reduce the pool's load.