MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
References: <7844645.RLYLWYmWtM@garp>
	<CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 21 Sep 2016 18:01:30 +0000
Message-ID: <CAAS2fgT5izjzUVyd3-9sQEHx8rk8pEJWxT6-eDteuUkZdRokAg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Precedence: list

On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> BIP number for my FT spec.

This document does not appear to be concretely specified enough to
review or implement from it.

For example, it does not specify the serialization of "integer" (is it
a 32 bit word in network byte order or?) nor does it specify how the
presence of the optional fields are signaled nor the cardinality of
the inputs or outputs. For clearly variable length elements
('bytearray') no mention is made of their length encoding. etc.

Without information like this, I don't see how someone could
realistically begin reviewing this proposal.

The motivation seems unclear to me as well: The scheme is described as
'flexible' but it appears to remove flexibility from the existing
system. The "schema" appears to be hardcoded and never communicated.
If the goal is to simply have a more compact on the wire
representation, this could be done without changing the serialization
used for hashing or the serialization used for costing.