BitcoinCash/specification
1
Fork 0
Code Issues Pull Requests Releases Activity

Added hard forks and relevant files after 2018/05/15.

Browse Source 
Formated all the files.
This commit is contained in:
Christopher-Zeng
2020-11-10 12:04:49 -05:00
parent 18f36edeea
commit a92fa7435c
25 changed files with 2746 additions and 1009 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/forks/bip-0064.md
+37 -28
View File
@@ -1,14 +1,14 @@
<pre>
BIP: 64
Layer: Peer Services
Title: getutxo message
Author: Mike Hearn &lt;hearn@vinumeris.com&gt;
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0064
Status: Draft
Type: Standards Track
Created: 2014-06-10
</pre>
# BIP-0064
BIP: 64
Layer: Peer Services
Title: getutxo message
Author: Mike Hearn &lt;hearn@vinumeris.com&gt;
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0064
Status: Draft
Type: Standards Track
Created: 2014-06-10
## Abstract
@@ -16,31 +16,35 @@ This document describes a small P2P protocol extension that performs UTXO lookup
## Motivation
All full Bitcoin nodes maintain a database called the unspent transaction output set. This set is
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
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.
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
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:
Two new messages are defined.
The "getutxos" message has the following structure:
| Field Size | Description | Data type | Comments |
|--|--|--|--|
| 1 | check mempool | bool | Whether to apply mempool transactions during the calculation, thus exposing their UTXOs and removing outputs that they spend.
| ? | outpoints | vector&lt;COutPoint&gt; | The list of outpoints to be queried. Each outpoint is serialized in the same way it is in a tx message.
| 1 | check mempool | bool | Whether to apply mempool transactions during the calculation, thus exposing their UTXOs and removing outputs that they spend. |
| ? | outpoints | vector&lt;COutPoint&gt; | 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:
@@ -66,21 +70,26 @@ NODE_GETUTXO flag in their nServices field, which has a value of 2 (the second b
## Authentication
The UTXO set is not currently authenticated by anything. There are proposals to resolve this by
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
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. Additionally, the form of the provided scriptPubKey
should be checked before execution to ensure the remote peer doesn't just set the script to OP_TRUE.
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.
Additionally, the form of the provided scriptPubKey should be checked before execution to ensure the remote peer doesn't just set the script to `OP_TRUE`.
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
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
@@ -92,4 +101,4 @@ results.
## Implementation
https://github.com/bitcoin/bitcoin/pull/4351/files
https://github.com/bitcoin/bitcoin/pull/4351/files