From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Thu, 22 Sep 2016 10:56:31 +0200
Message-ID: <1988067.b5KirJFSKj@garp>
In-Reply-To: <CAAS2fgT5izjzUVyd3-9sQEHx8rk8pEJWxT6-eDteuUkZdRokAg@mail.gmail.com>
References: <7844645.RLYLWYmWtM@garp>
	<CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
	<CAAS2fgT5izjzUVyd3-9sQEHx8rk8pEJWxT6-eDteuUkZdRokAg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Precedence: list

On Wednesday 21 Sep 2016 18:01:30 Gregory Maxwell via bitcoin-dev wrote:
> 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"

It refers to the external specification which is linked at the bottom.
In that spec you'll see that "Integer" is the standard var-int that Bitcoin 
has used for years.

> nor does it specify how the
> presence of the optional fields are signaled 

How does one signals an optional field except of in the spec? Thats the job of 
a specification.

> nor the cardinality of
> the inputs or outputs. 

Did you miss this in the 3rd table ?  I suggest clicking on the github bips 
repo link as tables are not easy to read in mediawiki plain format that the 
email contained.

> For clearly variable length elements
> ('bytearray') no mention is made of their length encoding. etc.

Also in the external CMF spec.
 
> Without information like this, I don't see how someone could
> realistically begin reviewing this proposal.

I agree, that would be bad. Luckily that you just missed the link :)
Here it is;
https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md

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

Being hardcoded and never communicated is what the current format does to. How 
does that "remove flexibility".

Also read my reply to Peter Todd on why this is flexible.

> If the goal is to simply have {snip}

It is not.

Thanks for asking, I understand that the CMF spec is useful to see as well. 
Hopefully you can now review it properly since I linked to it above.

Cheers!