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 1FF86B43 for ; Thu, 22 Sep 2016 12:09:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F9168A for ; Thu, 22 Sep 2016 12:09:44 +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-out01.mykolab.com (Postfix) with ESMTPS id 6B88161614; Thu, 22 Sep 2016 14:09:40 +0200 (CEST) From: Tom To: bitcoin-dev@lists.linuxfoundation.org Date: Thu, 22 Sep 2016 14:09:38 +0200 Message-ID: <6286144.BZfBM3Z3un@garp> In-Reply-To: <20160922111049.GA592@nex> References: <7844645.RLYLWYmWtM@garp> <1988067.b5KirJFSKj@garp> <20160922111049.GA592@nex> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 22 Sep 2016 12:40:26 +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 12:09:45 -0000 On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote= : > On Thu, Sep 22, 2016 at 10:56:31AM +0200, Tom via bitcoin-dev wrote: > > On Wednesday 21 Sep 2016 18:01:30 Gregory Maxwell via bitcoin-dev w= rote: > > > On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev > > >=20 > > > wrote: > > > > BIP number for my FT spec. > > >=20 > > > This document does not appear to be concretely specified enough t= o > > > review or implement from it. > > >=20 > > > For example, it does not specify the serialization of "integer" > >=20 > > It refers to the external specification which is linked at the bott= om. > > In that spec you'll see that "Integer" is the standard var-int that= > > Bitcoin > > has used for years. >=20 > I think BIPs should be self-contained, or rely on previous BIPs, > whenever possible. Referencing an external formatting document should= > be avoided=20 If luke-jr thinks I should submit CMF as a BIP, I can certainly do that= . Luke, what do you think? I don't have a preference either way. > > > nor does it specify how the > > > presence of the optional fields are signaled > >=20 > > How does one signals an optional field except of in the spec? Thats= the > > job of a specification. >=20 > So the presence is signaled by encountering the tag, which contains > both token type and name-reference. The encoder and decoder operation= s > could be described better. I'm sorry, I'm not following you here. Is there a question? > > > nor the cardinality of > > > the inputs or outputs. > >=20 > > Did you miss this in the 3rd table ? I suggest clicking on the git= hub > > bips > > repo link as tables are not easy to read in mediawiki plain format = that > > the > > email contained. >=20 > Minor nit: that table is not well-formed. I am not very well versed in mediawiki tables, and I found github has s= ome=20 incompatibilities too. The markdown one looks better; https://github.com/bitcoinclassic/documentation/blob/master/spec/transa= ctionv4.md > As was pointed out in the > normalized transaction ID BIP, your proposal only addresses > third-party malleability, since signers can simply change the > transaction and re-sign it. I have to disagree. That is not malleability. Creating a new document a= nd re- signing it is not changing anything. Its re-creating. Something that th= e owner=20 of the coin has every right to do. > This is evident from the fact that inputs > and outputs do not have a canonical order and it would appear that > tokens can be re-ordered in segments.=20 Sorry, what is evident? You seem to imply that it is uncommon that you = can=20 create two transactions of similar intent but using different bytes. You would be wrong with this implication as this is very common. You ca= n just=20 alter the order of the inputs, for instance. I am unable to see what the point is you are trying to make. Is there a= =20 question or a suggestion for improvement here? > Dependencies of tokens inside a > segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex, > TxOutScript <-> TxOutValue). Maybe you missed this line;=20 =ABTxInPrevHash and TxInPrevIndex Index can be skipped, but in any input the PrevHash always has to come first=BB If you still see something alarming, let me know. You can look at the code in Bitcoin Classic and notice that it really i= sn't=20 anything complicated or worrying. > Finally, allowing miners to reject transactions with unknown fields > makes the OP_NOPs unusable=20 Hmm, it looks like you are mixing terminology and abstraction-levels. = OP_NOP=20 is a field from script and there is no discussion about any rejection b= ased on=20 script in this BIP at all. Rejection of transactions is done on there being unrecognised tokens in= the=20 transaction formatting itself. Thank you for your email to my BIP, I hope you got the answers you were= =20 looking for :)