BIP 0033
|
This page describes a BIP (Bitcoin Improvement Proposal). |
BIP: 31 Title: Stratized Nodes Author: Amir Taaki <genjix@riseup.net> Status: Draft Type: Standards Track Created: 15-05-2012
Abstract
As the Bitcoin network scales, roles are fast becoming specialised. In the beginning, a single Bitcoin user would perform the synonymous roles of miner, merchant and end-user. With the growth however of this system, these functions are being abstracted away to specialised services as a natural part of Bitcoin's growth.
Bitcoin's blockchain becomes more unwieldy for end users over time, negatively affecting the usability of Bitcoin clients. As it grows, it becomes ever more impractical to deal with on portable devices or low end machines. Several proposals have been put forward to deal with this such as lightweight (headers-only) clients and skipping validation for blocks before the last checkpoint. However these measures are at best stop-gap workarounds to stave off a growing problem.
This document will examine a proposal which will be termed stratized nodes, a modification off an earlier concept termed blockchain service.
History
Jan Moller created BCCAPI in 2011. BCCAPI allowed a user's client to delegate blockchain interaction to a remote server. This server would store and manage the blockchain while the user client would run queries against that server.
ThomasV later created Electrum server. BCCAPI's server backend was proprietary, and Electrum required a full Free Software stack. Electrum's server was an adhoc temporary replacement. As it grew and became used, issues started to appear in its design.
Marek Palatinus (slush) drafted a new standard called Stratum to replace Electrum's server. Stratum has multiple transports and is usable as a blockchain server by merchants, miners and user-clients. Electrum moved to using a Stratum implementation first relying on ABE/bitcoind and more recently libbitcoin.
Stratum is unmaintained by Marek Palatinus, suffers from easy resource starvation and denial of service attacks, and is insecure. The proposal specified here is intended to replace the Stratum's role as a blockchain for user-clients. The proposal here is solely concerned with removing the onus of blockchain validation and lookups from user-clients to specialised services in a secure manner. Any secondary benefits or uses are purely incidental.
Overview
During the initial handshake between Bitcoin nodes, a version packet is sent. version packets have a bitfield called services. Nodes can fill this field to tell the network how they behave and which services they support. NODE_NETWORK (1) means a node can be asked for full blocks for example.
We propose two more values of NODE_SERVICE (2) and NODE_STRATIZED (4).
NODE_SERVICE
- A blockchain service which supports the additional messages "getoutputs" and "getspends".
- Does not respond to "getdata" messages by itself (unless NODE_NETWORK is specified)
- If NODE_NETWORK is specified, then "getdata" for transactions will retrieve them not only from the memory pool but also check the blockchain if necessary.
NODE_STRATIZED
- A node which uses the stratized strategy specified in this document.
- NODE_STRATIZED will relay inventories for accepted transactions.
- Does not support "getblocks" as stratized nodes do not contain the entire blockchain.
Apart from the differences noted above, the nodes are otherwise unchanged in their behaviour from NODE_NETWORK.
Specification
Four new messages are defined.
"getoutputs"
struct get_outputs
{
uint8_t payment_type;
uint8_t address_hash[16];
};
"outputs"
struct point_t
{
uint8_t hash[32];
uint32_t index;
};
struct outputs
{
uint64_t number_outputs; // variable uint
point_t outpoints[];
};
"getspend"
struct get_spend
{
point_t outpoint;
};
"spend"
struct spend
{
uint64_t number_points;
point_t inpoints[];
};