BIP 0060 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/979ee894b8a4a2e9/bip-0060.mediawiki

2024-04-23T21:22:56Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/979ee894b8a4a2e9/bip-0060.mediawiki

← Older revision		Revision as of 21:22, 23 April 2024
Line 27:		Line 27:
	One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one.		One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one.

	As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict ~~adherance~~ to standard messages with field length compliance with every protocol version.		As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherence to standard messages with field length compliance with every protocol version.

	Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader.		Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader.
Line 34:		Line 34:
	=== version ===		=== 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.		When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

	Payload:		Payload:

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0060.mediawiki

2019-09-24T18:00:58Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0060.mediawiki

@@ Line 1: / Line 1: @@
 {{bip}}
 <pre>
    BIP: 60
    Title: Fixed Length "version" Message (Relay-Transactions Field)
    Author: Amir Taaki <genjix@riseup.net>
    Status: Draft
    Type: Standards Track
-   Created: 16-06-2013
+   Created: 2013-06-16
 </pre>
-{{BipMoved|bip-0060.mediawiki}}
+==Abstract==
-[[Category:Developer]]
+This document is placed in the public domain.

934: Removing redundant parameter.

2015-12-29T13:47:01Z

Removing redundant parameter.

← Older revision		Revision as of 13:47, 29 December 2015
Line 10:		Line 10:
	</pre>		</pre>

	{{BipMoved\|bip-0060.mediawiki~~\|BIP 0060~~}}		{{BipMoved\|bip-0060.mediawiki}}

	[[Category:Developer]]		[[Category:Developer]]
	[[Category:Technical]]		[[Category:Technical]]
	[[Category:BIP\|D]]		[[Category:BIP\|D]]

Wumpus: Github move

2013-12-06T08:16:36Z

Github move

@@ Line 10: / Line 10: @@
 </pre>
-==Abstract==
+{{BipMoved|bip-0060.mediawiki|BIP 0060}}
 [[Category:Developer]]
 [[Category:Technical]]
 [[Category:BIP|D]]

Genjix: /* Code Updates */

2013-06-18T17:41:23Z

Code Updates

← Older revision		Revision as of 17:41, 18 June 2013
Line 82:		Line 82:
	PushMessage("version", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe,		PushMessage("version", PROTOCOL_VERSION, nLocalServices, nTime, addrYou, addrMe,
	nLocalHostNonce, FormatSubVersion(CLIENT_NAME, CLIENT_VERSION, std::vector<string>()),		nLocalHostNonce, FormatSubVersion(CLIENT_NAME, CLIENT_VERSION, std::vector<string>()),
	nBestHeight, ~~fRelayTxes~~);		nBestHeight, true);
	}		}
	</pre>		</pre>

Genjix: /* version */

2013-06-16T09:37:26Z

version

@@ Line 27: / Line 27: @@
 ==Specification==
-== version ==
+=== version ===
 When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.
@@ Line 66: / Line 66: @@
 | 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
 |}
 ==Copyright==

Genjix: /* version */

2013-06-16T09:34:17Z

version

← Older revision		Revision as of 09:34, 16 June 2013
Line 27:		Line 27:

	==Specification==		==Specification==
	=== version ===		== version ==

	When a node creates an outgoing connection, it will immediately [[Version Handshake\|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.		When a node creates an outgoing connection, it will immediately [[Version Handshake\|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.

Genjix: /* Specification */

2013-06-16T09:34:01Z

Specification

← Older revision		Revision as of 09:34, 16 June 2013
Line 27:		Line 27:

	==Specification==		==Specification==
			=== version ===

			When a node creates an outgoing connection, it will immediately [[Version Handshake\|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_recv \|\| net_addr \|\| The network address of the node receiving this message
			\|-
			\|colspan="4"\| version >= 106
			\|-
			\| 26 \|\| addr_from \|\| net_addr \|\| The network address of the node emitting this message
			\|-
			\| 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.
			\|-
			\| ? \|\| user_agent \|\| [[#Variable length string\|var_str]] \|\| [[BIP_0014\|User Agent]] (0x00 if string is 0 bytes long)
			\|-
			\| 4 \|\| start_height \|\| int32_t \|\| The last block received by the emitting node
			\|-
			\| 1 \|\| relay \|\| bool \|\| Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
			\|}

			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.
			\|}

	==Copyright==		==Copyright==

Genjix: /* Design rationale */

2013-06-16T09:31:41Z

Design rationale

← Older revision		Revision as of 09:31, 16 June 2013
Line 25:		Line 25:

	Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader.		Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader.

	~~==Design rationale==~~

	==Specification==		==Specification==

Genjix: /* Motivation */

2013-06-16T09:31:29Z

Motivation

← Older revision		Revision as of 09:31, 16 June 2013
Line 19:		Line 19:

	==Motivation==		==Motivation==

			One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one.

			As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherance to standard messages with field length compliance with every protocol version.

			Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader.

	==Design rationale==		==Design rationale==