From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F17A9B02 for ; Thu, 22 Sep 2016 08:56:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2472A135 for ; Thu, 22 Sep 2016 08:56:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out03.mykolab.com (Postfix) with ESMTPS id E312A237DE for ; Thu, 22 Sep 2016 10:56:32 +0200 (CEST) From: Tom To: bitcoin-dev@lists.linuxfoundation.org Date: Thu, 22 Sep 2016 10:56:31 +0200 Message-ID: <1988067.b5KirJFSKj@garp> In-Reply-To: References: <7844645.RLYLWYmWtM@garp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 22 Sep 2016 09:13:33 +0000 Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 08:56:41 -0000 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 > > 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!