BIP 0060: Difference between revisions
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== |
Revision as of 09:31, 16 June 2013
This page describes a BIP (Bitcoin Improvement Proposal). |
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
Abstract
BIP 0037 introduced a new flag to version messages which says whether to relay new transaction messages to that node.
The protocol version was upgraded to 70001, and the (now accepted) BIP 0037 became implemented.
The implementation is problematic because the RelayTransactions flag is an optional part of the version message stream.
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
Specification
Copyright
This document is placed in the public domain.