Bitcoin Wiki - User contributions [en]

Protocol documentation

2011-07-27T14:59:02Z

Prof7bit: clarification what the "limited" means

Sources:
* [[Original Bitcoin client]] source

Type names used in this documentation are from the C99 standard.

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use '''Double''' SHA-256, and are built up as so:

hash(a) = sha256(sha256(a))

hash(a) hash(b) hash(c)
hash(hash(a)+hash(b)) hash(hash(c)+hash(c))
hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))

They are paired up, with the last element being _duplicated_.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (ECDSA) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where x and y are 32 byte strings representing the coordinates of a point on the curve. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default).

=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

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.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload)) (not included in version or verack)
|-
| ? || payload || uchar[] || The actual data
|}

The version and verack messages do not have a checksum, the payload starts 4 bytes earlier.

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd + uint16_t
|-
| <= 0xffffffff || 5 || 0xfe + uint32_t
|-
| - || 9 || 0xff + uint64_t
|}

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || var_int || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

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.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_me || net_addr || The network address of the node emitting this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || The network address seen by the node emitting this message (ie, the address of the receiving node)
|-
| 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.
|-
| ? || sub_version_num || [[#Variable length string|var_str]] || Secondary Version information (0x00 if string is 0 bytes long)
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|}

If the emitter of the packet has version >= 209, a "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (note the message header for this version message does not have a checksum):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 DA F6 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
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
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
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

=== verack ===

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".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 ....

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || Number of address entries
|-
| 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).
|}

'''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.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
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)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

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.

Payload (maximum payload length: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

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.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || start count || var_int || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object. Newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

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:

<pre>
$step = 1
loop until at genesis block:
store current block hash
move backwards by $step
if number of stored hashes > 10:
$step *= 2
store genesis block
</pre>

=== getheaders ===

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).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || var_int || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || var_int || Number of Transaction outputs
|-
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Always locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
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).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 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.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || var_int || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || var_int || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

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.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of block headers
|-
| 77x? || headers || block_header[] || Block headers
|}

=== getaddr ===

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.

No additional data is transmitted with this message.

=== checkorder ===

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.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== ping ===

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.

=== alert ===

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.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || 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
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

== Wireshark dissector ==
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector

==See Also==

* [[Network]]
* [[Protocol rules]]
[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Category talk:Clients

2011-06-25T23:18:23Z

Prof7bit:

Here is a lot of software that does not fit the definition "Client" as given on the top of the page. They should be moved to a different category.[[User:Prof7bit|Prof7bit]] 11:46, 25 June 2011 (GMT)
:Done :-) [[User:Prof7bit|Prof7bit]]
*Except that this isn't the definition used in common-speak. To most people, a "frontend" (more often called a "user interface") is the client. The contents of this category should be split between Nodes (which implement at least the p2p protocol) and Wallets (which implement at least the wallet management). See [[Infrastructure]] for an overview. --[[User:Luke-jr|Luke-jr]] 15:11, 25 June 2011 (GMT)
**Since none of the other categories was linked from the software category and the client page existed already since January I asssumed it would be ok to follow the description of this client category ("downloads the block chain etc.."), leave it as it was and instead create the aditional category "frontend" (which can be an API binding or a complete User interface). My only intention was to remove a bit of the chaos, if the term "client" were not already used by this old category page i would have probably come up with a slightly different naming. Maybe it would be better to completely remove the ambiguous "client" (which could be understood as the p2p-client and by *some* people also as the user interface) and instead always strictly only use "node" "User Interface" and "API-Binding" and avoid the word "client" altogether.
** regarding "Wallet" I am not sure whether this should be mixed into this client-server categorizing problem, it would create more confusion. (there is the user interacting with the wallet (wallet as an abstract concept) through the UI but there is also the node software (the bitcoin client <-- there it is again this word) using the keys in the physically existing wallet file to calculate the balance and to generate transactions) [[User:Prof7bit|Prof7bit]] 23:01, 25 June 2011 (GMT)
*** After thinking about it a while I think we are (or I am) already over-complicating it. The original problem I had when I saw the software listing (and the reason I started to edit) was simply to distinguesh between real p2p bitcoin protocol implementations and mere user interfaces. Therefore we should throw away this complex construct of nested categories and sub categories and not split hairs about ambiguous names and instead simply make 3 categories: (a) p2p node implementations, (b) user interfaces and (c) API bindings and on each of these category pages explain in plain english what they mean and what they do. [[User:Prof7bit|Prof7bit]] 23:16, 25 June 2011 (GMT)

Category talk:Clients

2011-06-25T23:16:09Z

Prof7bit:

Here is a lot of software that does not fit the definition "Client" as given on the top of the page. They should be moved to a different category.[[User:Prof7bit|Prof7bit]] 11:46, 25 June 2011 (GMT)
:Done :-) [[User:Prof7bit|Prof7bit]]
*Except that this isn't the definition used in common-speak. To most people, a "frontend" (more often called a "user interface") is the client. The contents of this category should be split between Nodes (which implement at least the p2p protocol) and Wallets (which implement at least the wallet management). See [[Infrastructure]] for an overview. --[[User:Luke-jr|Luke-jr]] 15:11, 25 June 2011 (GMT)
**Since none of the other categories was linked from the software category and the client page existed already since January I asssumed it would be ok to follow the description of this client category ("downloads the block chain etc.."), leave it as it was and instead create the aditional category "frontend" (which can be an API binding or a complete User interface). My only intention was to remove a bit of the chaos, if the term "client" were not already used by this old category page i would have probably come up with a slightly different naming. Maybe it would be better to completely remove the ambiguous "client" (which could be understood as the p2p-client and by *some* people also as the user interface) and instead always strictly only use "node" "User Interface" and "API-Binding" and avoid the word "client" altogether.
** regarding "Wallet" I am not sure whether this should be mixed into this client-server categorizing problem, it would create more confusion. (there is the user interacting with the wallet (wallet as an abstract concept) through the UI but there is also the node software (the bitcoin client <-- there it is again this word) using the keys in the physically existing wallet file to calculate the balance and to generate transactions) [[User:Prof7bit|Prof7bit]] 23:01, 25 June 2011 (GMT)
*** After thinking about it a while I think we are (or I am) already over-complicating it. The original problem I had when I saw the software listing (and the reason I started to edit) was simply to distinguesh between real p2p bitcoin protocolimplementations and mere user interfaces. Therefore we should throw away this complex construct of nested categories and not split hairs about ambiguous names and instead simply make 3 categories: (a) p2p-node software, (b) user interfaces and (c) API bindings and on each of these category pages explain in plain english what they mean and what they do. [[User:Prof7bit|Prof7bit]] 23:16, 25 June 2011 (GMT)

Category talk:Clients

2011-06-25T23:01:46Z

Prof7bit:

Category:User Interfaces

2011-06-25T22:34:19Z

Prof7bit:

A user interface is what the end-user sees and interacts with. Some clients like the original bitcoin client already have their own user interface built in but alternative user interfaces with more sophisticated features can optionally be used to control the client.

Technically they connect to the running client (which can even run on a different computer) via the JSON-RPC protocol and fall into the category [[:Category:Frontends|Frontends]] together with the various available [[:Category:API Bindings|API Bindings]] for different programming langauges.

[[Category:Frontends]]

Category talk:Nodes

2011-06-25T21:56:48Z

Prof7bit: Created page with "Now there is redundancy. This category "node" is exactly the same as the category "client" I would suggest the following structure: * software ** clients (same as "nodes") ** fr..."

Now there is redundancy. This category "node" is exactly the same as the category "client"

I would suggest the following structure:
* software
** clients (same as "nodes")
** frontends (divided in two subcategories)
*** User interfaces
*** API Bindings

Category:API Bindings

2011-06-25T21:45:04Z

Prof7bit: Created page with "Category:Frontends"

[[Category:Frontends]]

Category:User Interfaces

2011-06-25T21:42:40Z

Prof7bit:

A user interface is what the end-user sees and interacts with. It interfaces with a [[:Category:Wallets|wallet]].

[[Category:Frontends]]

Category talk:Clients

2011-06-25T12:55:46Z

Prof7bit:

Template:MainPage Topics

2011-06-25T12:53:09Z

Prof7bit:

{|cellpadding="2" style="background-color: inherit;"
|-
| scope="col" style="width: 200px;" |
* [[Introduction]]
* [[Getting started]]
* [[Securing your wallet]]
* [[Secure Trading|Best practices for traders]]
| scope="col" style="width: 200px;" |
* [[PHP developer intro]]
* [[API reference (JSON-RPC)]]
* [[Protocol specification]]
* [[Myths]]
|}

{|cellpadding="2" style="background-color: inherit;"
|-
! scope="col" style="width: 200px;" |
! scope="col" style="width: 200px;" |
|-
|
* [[:Category:Software|Software]]
* [[:Category:Mining|Mining]]
* [[:Category:Exchanges|Exchanges]]
* [[:Category:Directories|Local Directories]]
* [[Press|Press coverage]]
* [[:Category:Marketing|Marketing resources]]
|
* [[:Category:Technical|Technical articles]]
* [[:Category:Clients|Clients]]
* [[:Category:Frontends|Frontends]]
* [[:Category:Economics|Economics]]
* [[Trade|Bitcoin-accepting sites]]
* [[Donation-accepting_organizations_and_projects|Donation-accepting sites]]
* [[Meetups]]
|}

<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> – '''[[Special:Categories|See More]]'''</div>

Template:MainPage Topics

2011-06-25T12:51:47Z

Prof7bit:

{|cellpadding="2" style="background-color: inherit;"
|-
| scope="col" style="width: 200px;" |
* [[Introduction]]
* [[Getting started]]
* [[Securing your wallet]]
* [[Secure Trading|Best practices for traders]]
| scope="col" style="width: 200px;" |
* [[PHP developer intro]]
* [[API reference (JSON-RPC)]]
* [[Protocol specification]]
* [[Myths]]
|}

{|cellpadding="2" style="background-color: inherit;"
|-
! scope="col" style="width: 200px;" |
! scope="col" style="width: 200px;" |
|-
|
* [[:Category:Software|Software]]
* [[:Category:Mining|Mining]]
* [[:Category:Exchanges|Exchanges]]
* [[:Category:Directories|Local Directories]]
* [[Press|Press coverage]]
* [[:Category:Marketing|Marketing resources]]
|
* [[:Category:Technical|Technical articles]]
* [[:Category:Software|Software]]
* [[:Category:Economics|Economics]]
* [[Trade|Bitcoin-accepting sites]]
* [[Donation-accepting_organizations_and_projects|Donation-accepting sites]]
* [[Meetups]]
|}

<div style="text-align: right;" class="noprint"><span class="plainlinks">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit''']</span> – '''[[Special:Categories|See More]]'''</div>

Category:Software

2011-06-25T12:47:48Z

Prof7bit:

Software that is related to Bitcoin.

==See Also==

* [[:Category:Clients|Clients]]
* [[:Category:Frontends|Frontends]]
* [[:Category:Developer|Developer]]

[[Category:Main category]]

Category:Frontends

2011-06-25T12:47:05Z

Prof7bit:

A frontend connects to a running [[:Category:Clients|client]] (for example via JSON-RPC) to provide a user interface for it, it does not implement the bitcoin protocol itself.

==See Also==

* [[API_reference_(JSON-RPC)]]
* [[:Category:Clients|Clients]]

[[Category:Software]]

Category:Clients

2011-06-25T12:45:16Z

Prof7bit:

'''Bitcoin clients''' are software that can connect to the network (implement the p2p protocol), download the [[blockchain]], manages wallets, and send or receive bitcoins, these clients intend to be alternatives to the original Bitcoin client.

Software or API wrappers that merely connects to an already running bitcoind to provide an alternative user interface or language binding is found in the category [[:Category:Frontends|Frontends]].
==See Also==

* [[Protocol rules]]
* [[:Category:Frontends|Frontends]]

[[fr:Catégorie:Clients Bitcoin]]
[[de:Kategorie:Client-Anwendungen]]
[[Category:Software]]

Category:Clients

2011-06-25T12:43:46Z

Prof7bit:

Category talk:Software

2011-06-25T12:29:29Z

Prof7bit:

== different system of categories ==

It would be desirable to have the bitcoin clients and other software grouped in the following categories:
* JSON clients for one's own bitcoind
* full featured bitcoin p2p implementation (full replacement for the official client)
* partial / minimal / "thin" implementation of p2p protocol (something like bitcoinj for example)

and maybe at least 3 words of description behind each link in the list to avoid clicking of dozens of links only to find out what category they are in. [[User:Prof7bit|Prof7bit]] 11:41, 25 June 2011 (GMT)

:Proper categorizing done :-) [[User:Prof7bit|Prof7bit]] 12:29, 25 June 2011 (GMT)

Category:Frontends

2011-06-25T12:25:58Z

Prof7bit:

Category:Frontends

2011-06-25T12:20:24Z

Prof7bit:

Category:Clients

2011-06-25T12:18:53Z

Prof7bit:

'''Bitcoin clients''' are software that can connect to the network, download the [[blockchain]], manages wallets, and send or receive bitcoins.

==See Also==

* [[Protocol rules]]
* [[:Category:Frontends|Frontends]]

[[fr:Catégorie:Clients Bitcoin]]
[[de:Kategorie:Client-Anwendungen]]
[[Category:Software]]
[[Category:Main category]]

Category:Frontends

2011-06-25T12:15:58Z

Prof7bit:

A '''frontend''' connects to a running [[:Category:Clients|client]] (for example via JSON-RPC) to provide an alternative user interface for it or wrap it into an API usable with a different programming language, it does not implement the bitcoin p2p protocol itself.

Category:Clients

2011-06-25T12:13:54Z

Prof7bit:

Spesmilo

2011-06-25T12:10:50Z

Prof7bit:

[[File:Spesmilo_english.png|thumb|400px|right]]
[[File:Spesmilo_esperanto.png|thumb|400px|right]]

Free software PySide RPC client open to a diverse community.
Additional translations and features are welcome, no matter how obscure.
Principal authors: [[User:genjix|genjix]] and [[User:Luke-Jr|Luke-Jr]]

==Features==
* Multilingual: American, Dutch, English, Esperanto, or French.
* Supports both Decimal and [[Tonal BitCoin|Tonal]] Bitcoins (and autodetection)
* Supports [[URI Scheme|bitcoin: URIs]]
* Can connect to remote JSON-RPC
* Can run local "embedded" bitcoind

==Current version (0.0.1.beta1)==
* [http://luke.dashjr.org/programs/bitcoin/files/Spesmilo_0.0.1.beta1_i386_windows.exe Windows installer] -- Requires Administrator to install or you will get an error
* [http://luke.dashjr.org/programs/bitcoin/files/Spesmilo_0.0.1.beta1_source.tbz2 Source code]

===Gentoo install===
layman -o https://gitorious.org/bitcoin/gentoo/blobs/raw/master/overlay.xml -f -a bitcoin
emerge -a spesmilo #(you may need to keyword some packages)

===Quick start (from source)===
# Dependencies: PySide, ImageMagick
make local
make
./spesmilo

To install:
make install

To install with bitcoin: URI support for KDE:
make install KDESERVICEDIR="/usr/share/kde4/services"

==Screenshots==
<gallery>
{{ns:file}}:Spesmilo-tonal.png|Tonal preference
{{ns:file}}:Spesmilo-decimal.png|Decimal preference
</gallery>

==External Links==

* [https://www.bitcoin.org/smf/index.php?topic=3451.0 Forum thread]
* [http://gitorious.org/bitcoin/spesmilo Gitorious repository]

[[Category:Frontends]]
[[Category:Free Software]]
[[Category:License/GPLv3]]
[[Category:Open Source]]
[[Category:Mobile]]

Python Bitcoinclient

2011-06-25T12:08:40Z

Prof7bit:

A Python client for bitcoind’s JSON-RPC interface.

This is free software licensed unter the terms of the GNU General Public License version 3 or later (GPLv3+).

This client does not require any external dependencies, it uses the httplib and json modules from the Python standard library.

==See Also==

* [[Original Bitcoin client]]
* [[Spesmilo]]

==External Links==

* [https://gitorious.org/bitcoinclient Bitcoinclient] project page at gitorious

[[Category:Open Source]][[Category:GPLv3+]]
[[Category:Frontends]]
[[Category:Python]]

Python Bitcoin

2011-06-25T12:07:37Z

Prof7bit:

Facilitates high-level interaction with Bitcoin (based on JSON-RPC).

This software is Open Source.

==See Also==

* [[Original Bitcoin client]]

==External Links==

* [http://gitorious.com/python-bitcoin Python Bitcoin] project

[[Category:Open Source]]
[[Category:Frontends]]

Java Bitcoin Client

2011-06-25T12:06:03Z

Prof7bit:

{{stub}}
'''Java Bitcoin Client''' is a [[Bitcoin]] frontend / API written in java.

==See Also==

* [[BitCoinJ]]

==External links==

*[http://sourceforge.net/projects/bitcoin-client/ Java Bitcoin Client sourceforge project page]

[[Category:Frontends]]
[[Category:Free Software]]
[[Category:License/Apache]]
[[Category:Open Source]]

Java Bitcoin Client

2011-06-25T12:05:03Z

Prof7bit:

{{stub}}
'''Java Bitcoin Client''' is a [[Bitcoin]] client written in java.

==See Also==

* [[BitCoinJ]]

==External links==

*[http://sourceforge.net/projects/bitcoin-client/ Java Bitcoin Client sourceforge project page]

[[Category:Frontends]]
[[Category:Free Software]]
[[Category:License/Apache]]
[[Category:Open Source]]

Bitcoiner

2011-06-25T11:58:49Z

Prof7bit:

An open source RPC client for Android that connects to a node on a PC via the RPC interface.
It allows transaction and balance overview as well as sending and receiving bitcoins using QR-codes. Going by a similar name is [[Bitcoiners]], a job board a freelancers directory.

For setting up the node to work with SSL please see [[Enabling_SSL_on_original_client_daemon]].

==External Links==

* Bitcoiner on [https://market.android.com/details?id=net.lwi.bitcoiner Android market].
* [http://sourceforge.net/projects/bitcoiner/ Bitcoiner] project page on Sorceforge.

==References==
<references />

[[Category:Frontends]]
[[Category:Free Software]]
[[Category:Open Source]]
[[Category:Mobile]]

Bitcoin-python

2011-06-25T11:56:33Z

Prof7bit:

Friendly bitcoin API binding for Python.

bitcoin-python is a set of Python libraries that allows easy access to the bitcoin peer-to-peer cryptocurrency client API.

This software is Open Source.

==Documentation==
Documentation can be found here, or in the source archive. It is built using Sphinx:

http://toomanysecrets0.github.com/bitcoin-python/doc/

==See Also==
* [[Original Bitcoin client]]

==External Links==
* [https://github.com/toomanysecrets0/bitcoin-python bitcoin-python] project

[[Category:Open Source]]
[[Category:Frontends]]

Bitcoin-js-remote

2011-06-25T11:53:56Z

Prof7bit: category

A user interface for Bitcoin written in JavaScript.

For SSL support a small server side script is included.

This software is released under the MIT/X11 License.

==External Links==

* [http://tcatm.github.com/bitcoin-js-remote Bitcoin-js-remote] website
* [http://github.com/tcatm/bitcoin-js-remote Bitcoin-js-remote] project page

==Example of an Apache HTTPD Configuration for Bitcoin JS Remote==
[I am assuming a little knowledge about Apache httpd. You had better read on Apache httpd directives: http://httpd.apache.org/docs/2.2/mod/directives.html. Of course, this is only an example of many other configurations]

Assuming your bitcoin.conf file includes:
rpcuser=myuser
rpcpassword=mypass

First, generate a suitable file for Basic Authentification. See man htpasswd or execute
htpasswd -b -c my_prefer_filename myuser mypass

Set following Apache directives in the proper context, i.e. server or virtual host configuration:
<Proxy http://127.0.0.1:8332>
AuthType Basic
AuthName "Bitcoin Access"
AuthUserFile my_prefer_filename
Require user myuser
Order deny,allow
Allow from all
</Proxy>

Assuming you want to access Bitcoin JS Remote with http://mydomain/jbc
Alias /jbc pathabs_to_bitcoin-js-remote
ProxyPass /lbc/ http://127.0.0.1:8332/
# ProxyPassReverse is not required because bitcoind talks pure
# JSON, i.e no HTTP Headers with URIs are generated by bitcoind
# ProxyPassReverse /lbc/ http://127.0.0.1:8332/

Above ProxyPass directive is asuming you are set the RPC.url field to "/lbc/" into "settings.json" file, located in the bitcoin-js-remote directory. See the settings.json_sample file for proper syntax.

A variety of configurations are feasible:

# If RPC.url is an absolute path (i.e. RPC.url : /lbc/),
# bitcoind at 127.0.0.1 shall be accessed by http://mydomain/jbc/
ProxyPass /lbc/ http://127.0.0.1:8332/
#
# If RPC.url is a relative path (i.e. RPC.url : lbc/),
# bitcoind at 127.0.0.1 shall be accessed by http://mydomain/jbc/lbc/
ProxyPass lbc/ http://127.0.0.1:8332/
#
# Apache can also proxy your access to any other IP by
# accessing to http://mydomain/jbc
ProxyPass /lbc/ http://www.worldbank.org:8332/

Please, note you are *not* required to set into the settings.json file the pair rcpuser/rcppassword. The required header with Basic Authentication is automatically generated by Apache when proxing, thanks for the above Auth directives.

Set RPC.user=rcpuser and RPC.password=rcppassword in the settings.json file if you are not able to configure your Apache webser; for instance, people using hosting instead of virtual or dedicated server. But, please, '''keep in mind''' settings.json file can be read by everybody: http://mydomain/jbc/settings.json

That's all. Restart your Apache web server.

=== Other interesting Apache directives: ===

To redirect all HTTP to HTTPS (of course, you need a well-configured ssl site).
!!! SSL access '''is extremely recommended''' to protect your Bitcoin data.
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

To avoid your log file from flooding
SetEnvIf Request_URI "^/jbc/" dontlog
SetEnvIf Request_URI "^/lbc/" dontlog
CustomLog myfile.log combined env=!dontlog

Finally, if you go in trouble, check proper access to bitcoin daemon with curl:
curl --trace-time --trace-ascii - \
--data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' \
--header 'content-type: text/plain;'\
http://myuser:mypass@127.0.0.1:8332/

[[Category:Frontends]]
[[Category:Free Software]]
[[Category:License/MIT-X11]]
[[Category:Open Source]]
[[Category:Mobile]]

Category:Frontends

2011-06-25T11:51:51Z

Prof7bit: Created page with "A frontend connects to a running client (for example via JSON-RPC) to provide a user interface for it, it does not implement the bitcoin protocol itself."

A frontend connects to a running [[:Category:Clients|client]] (for example via JSON-RPC) to provide a user interface for it, it does not implement the bitcoin protocol itself.

Category:Software

2011-06-25T11:48:38Z

Prof7bit:

Software that is related to Bitcoin.

==See Also==

* [[:Category:Clients|Clients]]
* [[:Category:Frontends|Frontends]]
* [[:Category:Developer|Developer]]

Category talk:Clients

2011-06-25T11:46:33Z

Prof7bit: Created page with "Here is a lot of software that does not fit the definition "Client" as given on the top of the page. They should be moved to a different category.~~~~"

Here is a lot of software that does not fit the definition "Client" as given on the top of the page. They should be moved to a different category.[[User:Prof7bit|Prof7bit]] 11:46, 25 June 2011 (GMT)

Category talk:Software

2011-06-25T11:41:31Z

Prof7bit: different system of categories

User:Prof7bit

2011-06-25T11:21:04Z

Prof7bit: Created page with "Contributors Award participant: 19KoKbNzcRHQaB7JfikMzgBM6CprjRuhRW"

Contributors Award participant: 19KoKbNzcRHQaB7JfikMzgBM6CprjRuhRW

Donation-accepting organizations and projects

2011-06-25T10:37:33Z

Prof7bit: added TorChat

Here is a list of organizations that accept bitcoin donations.
Only notable donation-accepting sites should be added here.

{| class="wikitable"
|-
! Organization
! Purpose
! Donation Page
|-
|[http://www.indiegogo.com/commonsense A Liberty Upgrade for America (IndieGoGo)]
|Join us as we reach 1.6 million Americans with a message of liberty!
|http://www.indiegogo.com/commonsense
|-
|[http://anapnea.org Anapnea]
|An open ethical shell network aiming to create a community with a spirit of productivity, learning and freedom, to give you a breath of fresh air. Operates an open Gentoo Linux shell network that is accessed daily by hundreds of ethical hackers, developers, designers and geeks around the world.
|[https://twitter.com/anapnea/status/78118988848185345 Bitcoin Donation Address]
|-
|[http://www.anonnews.org/ Anonnews.org]
|Open news platform for Anonymous
|http://anonnews.org/bitcoin.html
|-
|[http://awesome.naquadah.org/ awesome]
|Window manager for X11
|http://awesome.naquadah.org/community/
|-
|[http://www.ezyorg.com/ Organizing & Planning Tool]
|Great tool to organize your next party or business meeting
|http://ezyorg.com/
|-|-
|[https://iplayernotifier.appspot.com/ BBC iPlayer Notifier]
|Email and Google Talk notification of new content available on BBC iPlayer
|https://iplayernotifier.appspot.com/
|-
|[http://www.beatingdebt.org/ BeatingDebt.org]
|Teaching debt prevention by placing educational ads, supporting debt prevention groups, and providing online resources.
|http://www.beatingdebt.org/donate.php#BitCoinDonation
|-
|[http://www.bitcharity.org/ BitCharity]
|Use Bitcoins to donate to your favorite charity
|http://www.bitcharity.org
|-
|[http://www.bluetile.org Bluetile]
|Tiling window manager for GNOME
|http://www.bluetile.org/#development
|-
|[http://brmlab.cz/ Brmlab, hackerspace]
|The first hackerspace in the Czech Republic
|http://brmlab.cz/project/bitcoin
|-
|[http://c4ss.org/ Center for a Stateless Society]
|Builds public awareness of, and support for, market anarchism
|http://c4ss.org/support-the-center
|-
|[http://www.bitcoinsreview.com Consumer - Merchant Trust Project]
|An initiative to increase trust between Consumer and Bitcoin Merchants. All proceeds go to the websites fund, which pays for various things such as web-hosting and advertisement.
|http://www.bitcoinsreview.com/donate/
|-
|[http://www.degenernet.com/ Degenernet Radio]
|Online radio station founded in 2002 dedicated to promoting independent music from all genres. Music available from [http://www.degenernet.com www.degenernet.com]and on the [http://apps.facebook.com/degenernet Degenernet Radio Facebook App].
|http://www.degenernet.com/donate.php
|-
|[http://opensource.doppelstern.com Doppelstern Antispam]
|Doppelstern Antispam signatures for ClamAV
|http://opensource.doppelstern.com
|-
|[http://www.dosbox.com/ DOSBox]
|An x86 emulator with DOS
|http://www.dosbox.com/crew.php
|-
|[http://encyclopediadramatica.ch/Main_Page Encyclopedia Dramatica]
|4chan's Wikipedia
|http://encyclopediadramatica.ch/donate.php
|-
|[https://www.erowid.org/ Erowid]
|Online library of information about psychoactive plants and chemicals and other topics on altered states of consciousness such as meditation and lucid dreaming.
|https://www.erowid.org/donations/donations_bitcoin.php
|-
|[http://eudemocracia.org/english.html Eudemocracia] NGO
|Dedicated to the creation of a modern form of government that combines these two concepts: direct democracy and internet.
|http://wiki.eudemocracia.org/en/donaciones
|-
|[http://www.hayekinstitute.ca/ F.A. Hayek Institute of Canada]
|Study and promote Austrian Economics
|http://www.hayekinstitute.ca/home/index.php?option=com_content&view=article&id=54&Itemid=60
|-
|[http://www.foo.be/forban/ Forban]
|Filesharing protocol for local area networks
|http://www.foo.be/forban/
|-
|[http://freedomboxfoundation.org FreedomBox Foundation]
|Non-profit turning small plug computers into personal servers that guard your privacy, anonymity and security.
|https://freedomboxfoundation.org/donate
|-
|[http://www.fsf.org Free Software Foundation]
|Worldwide advocate for software freedom and host organization for the GNU Project.
|https://my.fsf.org/donate/other
|-
|[http://www.freetalklive.com/ Free Talk Live]
|Help spread the message of liberty by donating to a liberty leaning nationally syndicated radio show!
|http://www.freetalklive.com/bitcoin
|-
|[http://freedomainradio.com/ Freedomain Radio]
|Online philosophical conversation about freedom, religion, the state, and the family
|http://board.freedomainradio.com/forums/t/30241.aspx
|-
|[http://www.freehal.org/ FreeHAL]
|a self-learning artificial intelligence available as free software
|http://www.freehal.net/funds/?p=do&l=en
|-
|[http://privacyfoundation.de German Privacy Foundation]
|protecting privacy, manufacture and sell the CryptoStick (a smartcard on a usb stick)
|http://www.privacyfoundation.de/verein/spenden/
|-
|[http://www.reddit.com/r/hackbloc HackBloc on Reddit]
|Hacktivism, Crypto-anarchy, Darknets.
|http://www.reddit.com/r/hackbloc
|-
|[http://www.helplinux.ru Help Linux]
|Help Linux is the Russian volunteer project aimed to help people with linux. This projects helps anyone to find a skilled in some questions person and ask for help directly.
|http://helplinux.ourproject.org/wiki/about:start
|-
|[http://i2p2.de/ I2P Anonymous Network]
|Anonymising network similar to tor
|http://www.i2p2.de/donate.html
|-
|[http://www.infinitypfm.org/ Infinity PFM]
|Free/open source personal finance application with Bitcoin support.
|http://www.infinitypfm.org/#donate
|-
|[http://www.intercom.gs/ Intercom - Emergency Communications Division]
|We Build Censorship Resistant Phone and Communications Networks
|http://www.intercom.gs/support.html
|-
|[http://www.partito-pirata.it/ Italian Pirate Party]
|Italian Pirate Party - Associazione Partito Pirata Italia
|http://www.partito-pirata.it/magazzino/payBTC.html
|-
|[http://lifeboat.com Lifeboat Foundation]
|The Lifeboat Foundation is a nonprofit nongovernmental organization dedicated to encouraging scientific advancements while helping humanity survive existential risks and possible misuse of increasingly powerful technologies, including genetic engineering, nanotechnology, and robotics/AI, as we move towards the Singularity. (Currently offering to double all Bitcoin donations.)
|https://lifeboat.com/ex/summer.growth
|-
|[http://linuxoutlaws.com/ Linux Outlaws - we aim to misbehave]
|two pragmatic linux users talk about the latest developments in free and open software and culture
|http://linuxoutlaws.com/
|-
|[http://lorea.org/ Lorea]
|A distributed and federated nodal organization of entities working on integrating and pushing available free and open source technologies and networks, for social networking, social economy and autonomy of the people.
|https://n-1.cc/pg/pages/view/14888/
|-
|[http://biohackers.la/ Los Angeles Biohackers]
|Grass-roots biotechnology lab in downtown Los Angeles
|http://www.socal-diybio.org/Main_Page#Donate
|-
|[http://la.indymedia.org/ Los Angeles Indymedia]
|User-generated left-wing news.
|http://la.indymedia.org/
|-
|[http://love2d.org/ LÖVE]
|An open source 2D game engine.
|http://love2d.org/
|-
|[http://mars.radiome.me M.A.R.S. Radio Modern Alternative Rock Splendor ]
|M.A.R.S Radio is an online radio station playing 24/7/365 commercial free alternative rock at 192 Kbps. M.A.R.S. Radio is pleased to provide listeners FM+ audio quality. M.A.R.S. Radio is the first online music radio station to accept Bitcoin donations.
|http://radiome.me/
|-
|[https://github.com/FellowTraveler/Open-Transactions/ Open Transactions]
|Easy-to-use, Financial Crypto and Digital Cash Library.
|https://github.com/FellowTraveler/Moneychanger
|-
|[http://opengameart.org/ OpenGameArt.org]
|Produces and hosts freely licensed art for use in open source games
|http://opengameart.org/content/donate-bitcoins
|-
|[http://www.openwall.com Openwall Project]
|Development of information security related free software, information security research, publications, and community activities aimed at making existing free software safer to use.
|http://www.openwall.com/donations/
|-
|[https://www.operationanonymous.org/ Operation Anonymous]
|Anonymous Political Group
|http://www.operationanonymous.org/
|-
|[http://www.organicdesign.co.nz OrganicDesign]
|A group developing methods and tools to support open-source bottom-up peer-to-peer governance for the people!
|http://www.organicdesign.co.nz
|-
|[http://www.liberallibertario.org Partido Liberal Libertario]
|Libertarian Party of Argentina
|http://www.liberallibertario.org/aportes
|-
|[http://pioneerone.tv/ Pioneer One]
|TV series funded purely through donations
|https://twitter.com/pioneeronetv/status/36119594439544832
|-
|[http://plankhead.com/ Plankhead]
|Free/open source media and arts organization
|http://plankhead.com/donate
|-
|[http://plaztika.com/?lang=en Plaztika]
|Non-profit website (only runs on donations) that supports emerging visual artists. If you're an artist, this could be your website!
|http://plaztika.com/Who-are-we
|-
|[https://privacybox.de/index.en.html PrivacyBox]
|System for anonymous and non-trackable contact forms
|https://privacybox.de/donations.en.html
|-
|[http://prometheusfusionperfection.com/ Prometheus Fusion Perfection]
|Open source nuclear fusion research
|http://prometheusfusionperfection.com/2011/02/04/bitcoin-fundraiser/
|-
|[http://queeky.com/ Queeky]
|an online drawing community with special drawing tools and creative users from all around the world
|http://www.queeky.com/content/support-queeky-and-donate
|-
|[http://www.recycles.org/ Recycles.Org]
|Nonprofit Recycling and ReUse Network - Nationwide (USA) technology exchange clearinghouse for nonprofit organizations
|http://www.recycles.org/computer/donation/support/
|-
|[https://ripplepay.com/ Ripple]
|Payment system based on trust networks
|https://ripplepay.com/donate/
|-
| [https://riseup.net/ Riseup]
| Tech collective who aim to [https://help.riseup.net/en/about-us aid in the creation of a free society, (...) engaged in struggles against capitalism and other forms of oppression]
| https://help.riseup.net/en/donate#bitcoin
|-
|[http://rusinfo.cc/ RusInfo]
|Russian info agency
|http://rusinfo.cc/help
|-
|[http://singinst.org Singularity Institute]
|Artificial Intelligence
|http://singinst.org/donate
|-
| [http://www.sparkleshare.org/ SparkleShare]
| A Free and Open Source host it yourself replacement for file syncing services like Dropbox. It uses the distributed version control system Git as a backend.
| [http://www.sparkleshare.org/support-us/ Bitcoin Donation Address]
|-
|[http://wiki.sugarlabs.org Sugar Labs]
|[http://wiki.sugarlabs.org/go/What_is_Sugar%3F Sugar] is a learning environment that reinvents how computers are used for education.
|http://wiki.sugarlabs.org/go/Donate
|-
|[http://gorod-solnca.org/ Sun City]
|Ukrainian centre for children in difficult circumstances
|http://sms.gorod-solnca.org/
|-
|[http://www.symphonyofscience.com/ Symphony of Science]
|A musical project headed by John Boswell, to deliver scientific knowledge in musical form.
|http://www.symphonyofscience.com/
|-
|[http://tahoe-lafs.org/ Tahoe-LAFS]
|A distributed filesystem with funky redundancy properties
|http://tahoe-lafs.org/trac/tahoe-lafs/wiki/BitCoinPage
|-
|[http://tangorin.com Tangorin Japanese Dictionary]
|Tangorin is a free online Japanese dictionary in development since October 2007 by a former Japanology student. It makes use of files provided mainly by The Electronic Dictionary Research and Development Group established within the Faculty of Information Technology at Monash University, Australia.
|http://tangorin.com/bitcoin
|-
|[http://telecomix.org/ Telecomix]
|Internet freedom collective
|http://werebuild.eu/wiki/Donations
|-
|[http://theexperiments.com The Experiments]
|A rock / punk band who's music is free to download and licensed under the Creative Commons
|[http://theexperiments.com Bitcoin Donation Address]
|-
|[http://theicarusproject.net The Icarus Project]
|A mutual aid/peer support organization dedicated to radical mental health
|[http://theicarusproject.net/about-us/donate-to-the-icarus-project Bitcoin Donation Address]
|-
|[https://freenetproject.org/ The Freenet Project]
|The Free Network
|https://freenetproject.org/donate.html
|-
| [http://ThePythonGameBook.com ThePythonGameBook]
| An free creative-commons / GPL - licensed wikibook to learn open source game programming using the programming language Python.
| [http://thepythongamebook.com/en:help?&#donating_money Bitcoin Donation Address]
|-
|[http://torchat.googlecode.com/ TorChat]
|A serverless encrypted anonymous instant messenger running on top of the Tor network
|http://torchat.googlecode.com/
|-
|[https://www.torservers.net/ Torservers.net]
|Runs [http://www.torproject.org/ Tor] relays and bridges
|https://www.torservers.net/donate.html#anonymous
|-
|[https://vaizard.org/ Vaizard institute]
| Backing people who want to make the world a better place by making their ideas real.
|https://vaizard.org/en/about/contacts/
|-
|-
|[http://wikileaks.org wikileaks]
| Whistleblower website
|http://wikileaks.org/support.html
|-
|[http://wlcentral.org/ WL Central]
|News, analysis and action related to wikileaks the famous website . Media and human rights organization covering Wikileaks news, corruption and human rights.
|http://wlcentral.org/q-a
|}

==See Also==

* [http://witcoin.com/charities Charitable organizations] list on [[witcoin]]

Talk:Protocol documentation

2011-06-24T21:08:44Z

Prof7bit: /* Proposing additional protocol messages */

= Hexdumps =
I'm adding some hexdumps of messages and data structures and descriptions of how these are interpreted in order to help others understand these protocol and data structures. It's a bit redundant, so any ideas as to how to remove some of the redundancy while keeping the knowledge accessible are welcome (feel free to make the changes yourself!). -- [[User:X6763|X6763]]

= Checksum wrong? =
Is the checksum in the addr sample correct? Here's what I get using OpenSSL (sorry for long lines):
SHA256("\x01\xe2\x15\x10\x4d\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x0a\x00\x00\x01\x20\x8d") =
d6 88 65 c8 20 61 d5 e2 54 52 b5 5b 52 17 98 b1 11 50 85 96 2e 49 e8 fd da b7 f4 fb a3 9c d8 2c
and SHA256 of that is
ed 52 39 9b 56 8e d8 d5 9a 83 72 9c 11 6f 87 d0 be f2 84 e9 98 f3 47 7c 98 61 16 9a b1 2e ed 5c
It could easily be I'm using OpenSSL incorrectly, so wanted to get confirmation -- [[User:AndyParkins|AndyParkins]]
- The checksum for "addr" was not working for me neither, and I had the same results "ED 52 39 9B", so I fixed it on the page. --[[User:Robert|Robert]]

= What is "77x"? Header size wrong? =
The description for the headers command says "77x?" as the size for the block_headers[] returned. However, the description of the block_header structure is 81 bytes (4+32+32+4+4+4+1). What exactly is returned by the headers command? -- [[User:AndyParkins|AndyParkins]]

= Endianess on magic numbers =
The given magic numbers are the wrong way around. The magic numbers are little endian 32 bit numbers on the network, so Testnet.Magic = 0xdab5bffa and Prodnet.Magic = 0xd9b4bef9. The two examples are the order they come in from the wire, so at the very least should be shown with spaces between the bytes.
[[User:AndyParkins|AndyParkins]]

:I stumbled upon this as well and corrected the page. --[[User:Theo|Theo]] 10:13, 7 June 2011 (GMT)

= Version not advertised? =
Doing some experiments the version seems to be sent by the client, not the server as I think the page currently says.
"When a node receives an incoming connection, it will immediately advertise its version."
That is not true. --[[User:Bluecmd|Bluecmd]] 10:02, 5 June 2011 (GMT)

:You're right, net.h says in CNode constructor: --[[User:Theo|Theo]] 10:09, 7 June 2011 (GMT)
// Be shy and don't send version until we hear
if (!fInbound)
PushVersion();

= Version in getblocks? =
Apparently the official client sends the protocol version in getblocks messages, (possibly even in getheaders). This seems to me to be just weird --[[User:Bluecmd|Bluecmd]] 14:57, 6 June 2011 (GMT)

= Separate page for hexdumps? =

Does anyone else think it may be a good idea to put the hexdumps on a separate page? It'd be nice to have this page just describe the protocol, but at the same time, be able to have examples of each of the different messages and objects. On that node, would it also be helpful if I were to do a hexdump example of all of the different commands/structures? --[[User:Andrew12|Andrew12]] 23:26, 9 June 2011 (GMT)

= Proposing additional protocol messages =

According to the Bitcoin paper in order to do the simplified verification the client needs to store all headers of the entire chain but needs data only for those blocks that contain transactions of interest.

For this I propose the following new message types:

* '''setfilter''' this message contains a list of bitcoin addresses. After receiving this message on a connection the client will stop broadcasting any inv messages for transactions which don't have a matching address in its inputs or outputs. inv for new blocks will not be filtered.

* '''getblocksfiltered''' this message works exactly like getblocks but it will be answered with a filtered list of only those blocks that contain transactions with unspent outputs matching the filter list.

and the following new inventory type for getdata

* '''MSG_BLOCK_PRUNED''' this will be answered like a MSG_BLOCK but all transactions not matching the filter list and transactions that are already spent will be stripped from the block before transmitting it to the client.

When a client requests such filtering then all new blocks will still be advertised like normal but the client will have the opportunity to request only the absolute minimum necessary data to perform the simplified verification as outlined in the paper and new transactions will only be sent to it if they match the filter list. This should save a LOT of bandwidth.
[[User:Prof7bit|Prof7bit]] 21:03, 24 June 2011 (GMT)

Talk:Protocol documentation

2011-06-24T21:05:18Z

Prof7bit: /* Proposing additional potocol messages */

= Hexdumps =
I'm adding some hexdumps of messages and data structures and descriptions of how these are interpreted in order to help others understand these protocol and data structures. It's a bit redundant, so any ideas as to how to remove some of the redundancy while keeping the knowledge accessible are welcome (feel free to make the changes yourself!). -- [[User:X6763|X6763]]

= Checksum wrong? =
Is the checksum in the addr sample correct? Here's what I get using OpenSSL (sorry for long lines):
SHA256("\x01\xe2\x15\x10\x4d\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x0a\x00\x00\x01\x20\x8d") =
d6 88 65 c8 20 61 d5 e2 54 52 b5 5b 52 17 98 b1 11 50 85 96 2e 49 e8 fd da b7 f4 fb a3 9c d8 2c
and SHA256 of that is
ed 52 39 9b 56 8e d8 d5 9a 83 72 9c 11 6f 87 d0 be f2 84 e9 98 f3 47 7c 98 61 16 9a b1 2e ed 5c
It could easily be I'm using OpenSSL incorrectly, so wanted to get confirmation -- [[User:AndyParkins|AndyParkins]]
- The checksum for "addr" was not working for me neither, and I had the same results "ED 52 39 9B", so I fixed it on the page. --[[User:Robert|Robert]]

= What is "77x"? Header size wrong? =
The description for the headers command says "77x?" as the size for the block_headers[] returned. However, the description of the block_header structure is 81 bytes (4+32+32+4+4+4+1). What exactly is returned by the headers command? -- [[User:AndyParkins|AndyParkins]]

= Endianess on magic numbers =
The given magic numbers are the wrong way around. The magic numbers are little endian 32 bit numbers on the network, so Testnet.Magic = 0xdab5bffa and Prodnet.Magic = 0xd9b4bef9. The two examples are the order they come in from the wire, so at the very least should be shown with spaces between the bytes.
[[User:AndyParkins|AndyParkins]]

:I stumbled upon this as well and corrected the page. --[[User:Theo|Theo]] 10:13, 7 June 2011 (GMT)

= Version not advertised? =
Doing some experiments the version seems to be sent by the client, not the server as I think the page currently says.
"When a node receives an incoming connection, it will immediately advertise its version."
That is not true. --[[User:Bluecmd|Bluecmd]] 10:02, 5 June 2011 (GMT)

:You're right, net.h says in CNode constructor: --[[User:Theo|Theo]] 10:09, 7 June 2011 (GMT)
// Be shy and don't send version until we hear
if (!fInbound)
PushVersion();

= Version in getblocks? =
Apparently the official client sends the protocol version in getblocks messages, (possibly even in getheaders). This seems to me to be just weird --[[User:Bluecmd|Bluecmd]] 14:57, 6 June 2011 (GMT)

= Separate page for hexdumps? =

Does anyone else think it may be a good idea to put the hexdumps on a separate page? It'd be nice to have this page just describe the protocol, but at the same time, be able to have examples of each of the different messages and objects. On that node, would it also be helpful if I were to do a hexdump example of all of the different commands/structures? --[[User:Andrew12|Andrew12]] 23:26, 9 June 2011 (GMT)

= Proposing additional protocol messages =

According to the Bitcoin paper in order to do the simplified verification the client needs to store all headers of the entire chain but needs data only for those blocks that contain transactions of interest.

For this I propose the following new message types:

* '''setfilter''' this message contains a list of bitcoin addresses. After receiving this messaage on a connection the client will stop broadcasting any inv messages for transactions which don't have a matching address in its inputs or outputs. inv for new blocks will not be filtered.

* '''getblocksfiltered''' this message works exactly like getblocks but it will be answered with a filtered list of only those blocks that contain transactions with unspent outputs matching the filter list.

and the following new inventory type for getdata

* '''MSG_BLOCK_PRUNED''' this will be answered like a MSG_BLOCK but all transactions not matching the filter list and transactions that are already spent will be stripped from the block before transmitting it to the client.

When a client requests such filtering then all new blocks will still be advertised like normal but the client will have the opportunity to request only the absolute minumum necessary data to perform the simplified verification as outlined in the paper and new transactions will only be sent to it if they match the filter list. This should save a LOT of bandwidth.
[[User:Prof7bit|Prof7bit]] 21:03, 24 June 2011 (GMT)

Talk:Protocol documentation

2011-06-24T21:04:11Z

Prof7bit:

= Hexdumps =
I'm adding some hexdumps of messages and data structures and descriptions of how these are interpreted in order to help others understand these protocol and data structures. It's a bit redundant, so any ideas as to how to remove some of the redundancy while keeping the knowledge accessible are welcome (feel free to make the changes yourself!). -- [[User:X6763|X6763]]

= Checksum wrong? =
Is the checksum in the addr sample correct? Here's what I get using OpenSSL (sorry for long lines):
SHA256("\x01\xe2\x15\x10\x4d\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x0a\x00\x00\x01\x20\x8d") =
d6 88 65 c8 20 61 d5 e2 54 52 b5 5b 52 17 98 b1 11 50 85 96 2e 49 e8 fd da b7 f4 fb a3 9c d8 2c
and SHA256 of that is
ed 52 39 9b 56 8e d8 d5 9a 83 72 9c 11 6f 87 d0 be f2 84 e9 98 f3 47 7c 98 61 16 9a b1 2e ed 5c
It could easily be I'm using OpenSSL incorrectly, so wanted to get confirmation -- [[User:AndyParkins|AndyParkins]]
- The checksum for "addr" was not working for me neither, and I had the same results "ED 52 39 9B", so I fixed it on the page. --[[User:Robert|Robert]]

= What is "77x"? Header size wrong? =
The description for the headers command says "77x?" as the size for the block_headers[] returned. However, the description of the block_header structure is 81 bytes (4+32+32+4+4+4+1). What exactly is returned by the headers command? -- [[User:AndyParkins|AndyParkins]]

= Endianess on magic numbers =
The given magic numbers are the wrong way around. The magic numbers are little endian 32 bit numbers on the network, so Testnet.Magic = 0xdab5bffa and Prodnet.Magic = 0xd9b4bef9. The two examples are the order they come in from the wire, so at the very least should be shown with spaces between the bytes.
[[User:AndyParkins|AndyParkins]]

:I stumbled upon this as well and corrected the page. --[[User:Theo|Theo]] 10:13, 7 June 2011 (GMT)

= Version not advertised? =
Doing some experiments the version seems to be sent by the client, not the server as I think the page currently says.
"When a node receives an incoming connection, it will immediately advertise its version."
That is not true. --[[User:Bluecmd|Bluecmd]] 10:02, 5 June 2011 (GMT)

:You're right, net.h says in CNode constructor: --[[User:Theo|Theo]] 10:09, 7 June 2011 (GMT)
// Be shy and don't send version until we hear
if (!fInbound)
PushVersion();

= Version in getblocks? =
Apparently the official client sends the protocol version in getblocks messages, (possibly even in getheaders). This seems to me to be just weird --[[User:Bluecmd|Bluecmd]] 14:57, 6 June 2011 (GMT)

= Separate page for hexdumps? =

Does anyone else think it may be a good idea to put the hexdumps on a separate page? It'd be nice to have this page just describe the protocol, but at the same time, be able to have examples of each of the different messages and objects. On that node, would it also be helpful if I were to do a hexdump example of all of the different commands/structures? --[[User:Andrew12|Andrew12]] 23:26, 9 June 2011 (GMT)

= Proposing additional potocol messages =

According to the Bitcoin paper in order to do the simplified verification the client needs to store all headers of the entire chain but needs data only for those blocks that contain transactions of interest.

For this I propose the following new message types:

* '''setfilter''' this message contains a list of bitcoin addresses. After receiving this messaage on a connection the client will stop broadcasting any inv messages for transactions which don't have a matching address in its inputs or outputs. inv for new blocks will not be filtered.

* '''getblocksfiltered''' this message works exactly like getblocks but it will be answered with a filtered list of only those blocks that contain transactions with unspent outputs matching the filter list.

and the following new inventory type for getdata

* '''MSG_BLOCK_PRUNED''' this will be answered like a MSG_BLOCK but all transactions not matching the filter list and transactions that are already spent will be stripped from the block before transmitting it to the client.

When a client requests such filtering then all new blocks will still be advertised like normal but the client will have the opportunity to request only the absolute minumum necessary data to perform the simplified verification as outlined in the paper and new transactions will only be sent to it if they match the filter list. This should save a LOT of bandwidth.
[[User:Prof7bit|Prof7bit]] 21:03, 24 June 2011 (GMT)

Talk:Protocol documentation

2011-06-24T21:03:17Z

Prof7bit: /* Proposing additional potocol messages */ new section

= Hexdumps =
I'm adding some hexdumps of messages and data structures and descriptions of how these are interpreted in order to help others understand these protocol and data structures. It's a bit redundant, so any ideas as to how to remove some of the redundancy while keeping the knowledge accessible are welcome (feel free to make the changes yourself!). -- [[User:X6763|X6763]]

= Checksum wrong? =
Is the checksum in the addr sample correct? Here's what I get using OpenSSL (sorry for long lines):
SHA256("\x01\xe2\x15\x10\x4d\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x0a\x00\x00\x01\x20\x8d") =
d6 88 65 c8 20 61 d5 e2 54 52 b5 5b 52 17 98 b1 11 50 85 96 2e 49 e8 fd da b7 f4 fb a3 9c d8 2c
and SHA256 of that is
ed 52 39 9b 56 8e d8 d5 9a 83 72 9c 11 6f 87 d0 be f2 84 e9 98 f3 47 7c 98 61 16 9a b1 2e ed 5c
It could easily be I'm using OpenSSL incorrectly, so wanted to get confirmation -- [[User:AndyParkins|AndyParkins]]
- The checksum for "addr" was not working for me neither, and I had the same results "ED 52 39 9B", so I fixed it on the page. --[[User:Robert|Robert]]

= What is "77x"? Header size wrong? =
The description for the headers command says "77x?" as the size for the block_headers[] returned. However, the description of the block_header structure is 81 bytes (4+32+32+4+4+4+1). What exactly is returned by the headers command? -- [[User:AndyParkins|AndyParkins]]

= Endianess on magic numbers =
The given magic numbers are the wrong way around. The magic numbers are little endian 32 bit numbers on the network, so Testnet.Magic = 0xdab5bffa and Prodnet.Magic = 0xd9b4bef9. The two examples are the order they come in from the wire, so at the very least should be shown with spaces between the bytes.
[[User:AndyParkins|AndyParkins]]

:I stumbled upon this as well and corrected the page. --[[User:Theo|Theo]] 10:13, 7 June 2011 (GMT)

= Version not advertised? =
Doing some experiments the version seems to be sent by the client, not the server as I think the page currently says.
"When a node receives an incoming connection, it will immediately advertise its version."
That is not true. --[[User:Bluecmd|Bluecmd]] 10:02, 5 June 2011 (GMT)

:You're right, net.h says in CNode constructor: --[[User:Theo|Theo]] 10:09, 7 June 2011 (GMT)
// Be shy and don't send version until we hear
if (!fInbound)
PushVersion();

= Version in getblocks? =
Apparently the official client sends the protocol version in getblocks messages, (possibly even in getheaders). This seems to me to be just weird --[[User:Bluecmd|Bluecmd]] 14:57, 6 June 2011 (GMT)

= Separate page for hexdumps? =

Does anyone else think it may be a good idea to put the hexdumps on a separate page? It'd be nice to have this page just describe the protocol, but at the same time, be able to have examples of each of the different messages and objects. On that node, would it also be helpful if I were to do a hexdump example of all of the different commands/structures? --[[User:Andrew12|Andrew12]] 23:26, 9 June 2011 (GMT)

== Proposing additional potocol messages ==

According to the Bitcoin paper in order to do the simplified verification the client needs to store all headers of the entire chain but needs data only for those blocks that contain transactions of interest.

For this I propose the following new message types:

* '''setfilter''' this message contains a list of bitcoin addresses. After receiving this messaage on a connection the client will stop broadcasting any inv messages for transactions which don't have a matching address in its inputs or outputs. inv for new blocks will not be filtered.

* '''getblocksfiltered''' this message works exactly like getblocks but it will be answered with a filtered list of only those blocks that contain transactions with unspent outputs matching the filter list.

and the following new inventory type for getdata

* '''MSG_BLOCK_PRUNED''' this will be answered like a MSG_BLOCK but all transactions not matching the filter list and transactions that are already spent will be stripped from the block before transmitting it to the client.

When a client requests such filtering then all new blocks will still be advertised like normal but the client will have the opportunity to request only the absolute minumum necessary data to perform the simplified verification as outlined in the paper and new transactions will only be sent to it if they match the filter list. This should save a LOT of bandwidth.
[[User:Prof7bit|Prof7bit]] 21:03, 24 June 2011 (GMT)