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 wrote: > > On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev > > > > <[email protected]> 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.
I think BIPs should be self-contained, or rely on previous BIPs, whenever possible. Referencing an external formatting document should be avoided and requiring readers to reverse engineer a reference implementation doesn't seem too user friendly either. Publishing a BIP with CMF would certainly help, and completing this spec with the details that are missing, or only "defined" in the implementation, would be better. > > 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. So the presence is signaled by encountering the tag, which contains both token type and name-reference. The encoder and decoder operations could be described better. > > 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. Minor nit: that table is not well-formed. 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. 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. Dependencies of tokens inside a segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex, TxOutScript <-> TxOutValue). Finally, allowing miners to reject transactions with unknown fields makes the OP_NOPs unusable since they'd result in forks: non-upgraded nodes would reject blocks from upgraded nodes. Regards, Christian _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
