https://de.bitcoin.it/w/index.php?title=Protokoll-Spezifikation&feed=atom&action=historyProtokoll-Spezifikation - Versionsgeschichte2024-03-29T08:14:59ZVersionsgeschichte dieser Seite in Bitcoin WikiMediaWiki 1.30.0https://de.bitcoin.it/w/index.php?title=Protokoll-Spezifikation&diff=1016&oldid=prevAlf147: /* Verifikation von Transaktionen */2016-01-14T17:29:58Z<p><span dir="auto"><span class="autocomment">Verifikation von Transaktionen</span></span></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr style="vertical-align: top;" lang="de">
<td colspan="2" style="background-color: white; color:black; text-align: center;">← Nächstältere Version</td>
<td colspan="2" style="background-color: white; color:black; text-align: center;">Version vom 14. Januar 2016, 17:29 Uhr</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l44" >Zeile 44:</td>
<td colspan="2" class="diff-lineno">Zeile 44:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>{{See also|OP_CHECKSIG}}</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>{{See also|OP_CHECKSIG}}</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>Die erste Transaktion eines Blockes ist normalerweise die generierende Transaktion, die keine Quelle hat und alle Gebüren, sowie die derzeit <del class="diffchange diffchange-inline">50 </del>Bitcoin an den Blockerzeuger ausschüttet.</div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>Die erste Transaktion eines Blockes ist normalerweise die generierende Transaktion, die keine Quelle hat und alle Gebüren, sowie die derzeit <ins class="diffchange diffchange-inline">25 </ins>Bitcoin an den Blockerzeuger ausschüttet.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Solche Transaktionen werden "coinbase transaction" genannt und werden von allen Clients akzeptiert, wenn nur eine pro Block vorhanden ist.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Solche Transaktionen werden "coinbase transaction" genannt und werden von allen Clients akzeptiert, wenn nur eine pro Block vorhanden ist.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
</table>Alf147https://de.bitcoin.it/w/index.php?title=Protokoll-Spezifikation&diff=437&oldid=prevKwarf: Übersetzung des englischen Artikels, noch nicht fertig2011-07-29T00:11:58Z<p>Übersetzung des englischen Artikels, noch nicht fertig</p>
<p><b>Neue Seite</b></p><div>Hinweis: Dieser Artikel ist noch eine totale Baustelle, da hier noch der englische Orginalartikel übersetzt wird. Wer einen Teil übersetzen will, macht das einfach. Bei Stellen, bei denen er sich unsicher ist, lässt er den englischen Text stehen.<br />
<br />
<br />
<br />
<br />
Variablentypen in dieser Dokumentation sind aus dem C99 Standard.<br />
<br />
== Allgemeine Standards==<br />
<br />
=== Hashes ===<br />
In Bitcoin werden Hashes durch zweifachen Aufruf der Hashfunktion generiert. Meistens wird dafür [http://de.wikipedia.org/wiki/Secure_Hash_Algorithm#SHA-2 SHA-256] benutzt, wobei auch [http://de.wikipedia.org/wiki/RIPEMD-160 RIPEMD-160] für kürzere Hashes, z.B. die Bitcoinadresse, Verwendung findet.<br />
<br />
Beispiel mit zweifachem SHA-256 mit dem String "hello":<br />
<br />
hello (Klartext)<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (SHA-256 Hash vom Klartext)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (SHA-256 Hash vom ersten Hash)<br />
<br />
Beispiel mit SHA-256 und anschließendem RIPEMD-160 mit dem String "hello":<br />
<br />
hello (Klartext)<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (SHA-256 Hash vom Klartext)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (RIPEMD-160 Hash vom ersten Hash)<br />
<br />
=== Hash-Bäume ===<br />
Hash-Bäume sind Binärbäume von Hashes. In Bitcoin wird '''doppeltes''' SHA-256 verwendet, aufgebaut sind sie wie folgt: <br />
<br />
hash(a) = sha256(sha256(a))<br />
<br />
hash(a) hash(b) hash(c)<br />
hash(hash(a)+hash(b)) hash(hash(c)+hash(c))<br />
hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))<br />
<br />
They are paired up, with the last element being _duplicated_.<br />
<br />
=== Signaturen ===<br />
<br />
Bitcoin benurtr [http://de.wikipedia.org/wiki/Elliptic_Curve_Cryptography Elliptic Curve] [http://de.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (ECDSA), um Transaktionen zu signieren, dabei wird die secp256k1 Kurve von [http://www.secg.org/collateral/sec2_final.pdf secg (S.15)] verwendet.<br />
<br />
Öffentliche Schlüssel sind als 04 <x> <y> angegeben, wobei x und y 32 Byte lange Strings sind, die einen Punkt auf der Kurve repräsentieren. Signaturen nutzen [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding], um die r und s Komponenten in einen Bytestream zu verpacken.<br />
<br />
<br />
=== Verifikation von Transaktionen ===<br />
{{See also|OP_CHECKSIG}}<br />
<br />
Die erste Transaktion eines Blockes ist normalerweise die generierende Transaktion, die keine Quelle hat und alle Gebüren, sowie die derzeit 50 Bitcoin an den Blockerzeuger ausschüttet.<br />
Solche Transaktionen werden "coinbase transaction" genannt und werden von allen Clients akzeptiert, wenn nur eine pro Block vorhanden ist.<br />
<br />
If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.<br />
The script from the in part of this transaction is executed.<br />
Then the script from the out part of the referenced transaction is executed.<br />
It is considered valid if the top element of the stack is true.<br />
<br />
=== Addressen ===<br />
<br />
Eine Bitcoinadresse ist der Hash eines öffentlichen ECDSA Schlüssels, der so generiert wird:<br />
<br />
Version = 1 Byte mit dem Wert 0 (Null); Im Testnetzwerk hat das Byte den Wert 111<br />
Key hash = Version mit einem angehängten RIPEMD-160(SHA-256(public key))<br />
Checksumme = Die ersten 4 Bytes von SHA-256(SHA-256(Key hash))<br />
Bitcoin Addresse = Base58Encode(Key hash mit der angehängten Checksumme)<br />
<br />
Die Base58 Encodierung ist etwas abgewandelt, insbesondere werden führende Nullen als einzelne Null behalten.<br />
<br />
== Allgemeine Strukturen ==<br />
<br />
Alle Integer außer IP und Portnummer werden als little endian encodiert.<br />
<br />
=== Nachrichtenstruktur ===<br />
<br />
{|class="wikitable"<br />
! Feldgröße !! Beschreibung !! Datentyp !! Kommentar<br />
|-<br />
| 4 || magic || uint32_t || Magic value am Anfang einer jeden Nachricht.<br />
|-<br />
| 12 || Kommando || char[12] || ASCII String, der den Paketinhalt spezifiziert, wird mit Nullen aufgefüllt.<br />
|-<br />
| 4 || Länge || uint32_t || Länge der Payload in Bytes<br />
|-<br />
| 4 || Checksumme || uint32_t || Die ersten 4 Bytes von sha256(sha256(payload))<br />
|-<br />
| ? || Payload || uchar[] || Die eigentlichen Daten<br />
|}<br />
<br />
Die Versions- und verack -Nachrichten haben keine Checksumme, die Payload beginnt 4 Bytes früher.<br />
<br />
Bekannte magic values:<br />
<br />
{|class="wikitable"<br />
! Netzwerk !! Magic value !! Übertragen als<br />
|-<br />
| Hauptnetzwerk || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| Testnetzwerk || 0xDAB5BFFA || FA BF B5 DA<br />
|}<br />
<br />
=== Integer mit variabler Länge ===<br />
<br />
Integer können je nach Daten anders encodiert werden, um Platz zu sparen. Diese Integer haben immer ein Prefix, der den Typ angibt<br />
<br />
{|class="wikitable"<br />
! Wert !! Speichergröße !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd + uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe + uint32_t<br />
|-<br />
| - || 9 || 0xff + uint64_t<br />
|}<br />
<br />
=== Strings mit variabler Länge ===<br />
<br />
Strings mit variabler Länge können gespeichert werden, indem ein Integer mit der Länge des Strings vor den String gestellt wird.<br />
<br />
{|class="wikitable"<br />
! Feldgröße !! Beschreibung !! Datentyp !! Kommentar<br />
|-<br />
| ? || Länge || var_int || Länge des Strings<br />
|-<br />
| ? || String || char[] || Der String selbst (kann leer sein)<br />
|}<br />
<br />
=== Netzwerkadresse ===<br />
<br />
Wenn irgendwo eine Netzwerkadresse gebraucht wird, wird folgende Struktur benutzt. Diese Struktur unterstützt IPv6, wobei der orginale Client derzeit nur IPv4 unterstützt,<br />
<br />
{|class="wikitable"<br />
! Feldgröße !! Beschreibung !! Datentyp !! Kommentar<br />
|-<br />
| 8 || Dienste || uint64_t || Die gleichen Dienste, wie auch in [[#version|version]]<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 Adresse in Network byte order. Der orginale Client unterstützt nur IPv4 und liest nur die letzten 4 Bytes, um die Adresse zu bekommen. Dennoch wird die Adresse als 16 Byte [http://de.wikipedia.org/wiki/IPv6#Global_Unicast IPv4-mapped IPv6 Adresse] gespeichert.<br />
(12 Bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', gefolgt von den 4 Bytes der IPv4 Adresse).<br />
|-<br />
| 2 || Port || uint16_t || Portnummer, in Network byte order<br />
|}<br />
<br />
Ein Hexdumpbeispiel der Netzwerkadressstruktur<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Netzwerkadresse:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: Siehe die Dienste, aufgelistet unter)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 oder IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventarvektoren ===<br />
<br />
Inventarvektoren werden genutzt, um andere Nodes nach Objekten, die sie haben, oder Daten, die benötigt werden, zu fragen.<br />
<br />
Inventarvektoren sind wie folgt aufgebaut:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_me || net_addr || The network address of the node emitting this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_you || net_addr || The network address seen by the node emitting this message (ie, the address of the receiving node)<br />
|-<br />
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br />
|-<br />
| ? || sub_version_num || [[#Variable length string|var_str]] || Secondary Version information (0x00 if string is 0 bytes long)<br />
|-<br />
|colspan="4"| version >= 209<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|}<br />
<br />
If the emitter of the packet has version >= 209, a "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (note the message header for this version message does not have a checksum):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 DA F6 - Sender address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Recipient address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version'' for clients >= 209. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 ....<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload (maximum payload length: 1000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || var_int || Number of address entries<br />
|-<br />
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 50000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || var_int || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.<br />
<br />
Payload (maximum payload length: 50000 bytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || var_int || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || start count || var_int || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object. Newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br />
<br />
<pre><br />
$step = 1<br />
loop until at genesis block:<br />
store current block hash<br />
move backwards by $step<br />
if number of stored hashes > 10:<br />
$step *= 2<br />
store genesis block<br />
</pre><br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || start count || var_int || number of hash_start entries<br />
|-<br />
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || var_int || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || var_int || Number of Transaction outputs<br />
|-<br />
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || var_int || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || sequence || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || uint64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || var_int || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || var_int || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || var_int || Number of block headers<br />
|-<br />
| 77x? || headers || block_header[] || Block headers<br />
|}<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network<br />
|-<br />
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message<br />
|}<br />
<br />
The signature is to be compared to this ECDSA public key:<br />
<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Kwarf