I took the number out, it is now just "the getutxo bip" until a number is assigned. On Thu, Jul 10, 2014 at 4:29 PM, Mike Hearn wrote: > I opened up a pull req for a draft BIP for getutxo. > > https://github.com/bitcoin/bips/pull/88 > > I include a rendering below for your reading convenience. If you'd like to > comment on design/security/etc then please first familiarise yourself with > the long discussions that were already had here: > > https://github.com/bitcoin/bitcoin/pull/4351 > > > BIP: 45 > Title: getutxo message > Author: Mike Hearn > Status: Draft > Type: Standards Track > Created: 2014-06-10 > > Table of Contents > > - Abstract > > - Motivation > > - Specification > > - Backward compatibility > > - Authentication > > - Implementation > > > > > Abstract > > This document describes a small P2P protocol extension that performs UTXO > lookups given a set of outpoints. > > > Motivation > > All full Bitcoin nodes maintain a database called the unspent transaction > output set. This set is how double spending is checked for: to be valid a > transaction must identify unspent outputs in this set using an identifier > called an "outpoint", which is merely the hash of the output's containing > transaction plus an index. > > The ability to query this can sometimes be useful for a lightweight/SPV > client which does not have the full UTXO set at hand. For example, it can > be useful in applications implementing assurance contracts to do a quick > check when a new pledge becomes visible to test whether that pledge was > already revoked via a double spend. Although this message is not strictly > necessary because e.g. such an app could be implemented by fully > downloading and storing the block chain, it is useful for obtaining > acceptable performance and resolving various UI cases. > > Another example of when this data can be useful is for performing floating > fee calculations in an SPV wallet. This use case requires some other > changes to the Bitcoin protocol however, so we will not dwell on it here. > > > Specification > > Two new messages are defined. The "getutxos" message has the following > structure: > > Field Size DescriptionData typeComments 1check mempoolbool Whether to > apply mempool transactions during the calculation, thus exposing their > UTXOs and removing outputs that they spend. ?outpointsvector The list of > outpoints to be queried. Each outpoint is serialized in the same way it is > in a tx message. > > The response message "utxos" has the following structure: > > Field Size DescriptionData typeComments 4chain heightuint32 The height > of the chain at the moment the result was calculated. 32chain tip hash > uint256 Block hash of the top of the chain at the moment the result was > calculated. ?hit bitmapbyte[] An array of bytes encoding one bit for each > outpoint queried. Each bit indicates whether the queried outpoint was found > in the UTXO set or not. ?result utxosresult[] A list of result objects > (defined below), one for each outpoint that is unspent (i.e. has a bit set > in the bitmap). > > The result object is defined as: > > Field Size DescriptionData typeComments 4tx versionuint32 The version > number of the transaction the UTXO was found in. 4heightuint256 The > height of the block containing the defining transaction, or 0x7FFFFFFF if > the tx is in the mempool. ?outputCTxOut The output itself, serialized in > the same way as in a tx message. > Backward > compatibility > > Nodes indicate support by advertising a protocol version above 70003 and > by setting a new NODE_GETUTXO flag in their nServices field, which has a > value of 2 (1 > > > Authentication > > The UTXO set is not currently authenticated by anything. There are > proposals to resolve this by introducing a new consensus rule that commits > to a root hash of the UTXO set in blocks, however this feature is not > presently available in the Bitcoin protocol. Once it is, the utxos message > could be upgraded to include Merkle branches showing inclusion of the UTXOs > in the committed sets. > > If the requesting client is looking up outputs for a signed transaction > that they have locally, the client can partly verify the returned output by > running the input scripts with it. Currently this verifies only that the > script is correct. A future version of the Bitcoin protocol is likely to > also allow the value to be checked in this way. It does not show that the > output is really unspent or was ever actually created in the block chain > however. > > If the requesting client has a mapping of chain heights to block hashes in > the best chain e.g. obtained via getheaders, then they can obtain a proof > that the output did at one point exist by requesting the block and > searching for the output within it. When combined with Bloom filtering this > can be reasonably efficient. > > Note that even when the outputs are being checked against something this > protocol has the same security model as Bloom filtering: a remote node can > lie through omission by claiming the requested UTXO does not exist / was > already spent (they are the same, from the perspective of a full node). > Querying multiple nodes and combining their answers can be a partial > solution to this, although as nothing authenticates the Bitcoin P2P network > a man in the middle could still yield incorrect results. > > > Implementation > > https://github.com/bitcoin/bitcoin/pull/4351/files >