Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-22 📝 Original message:On Thu, Sep 22, 2016 at ...

📅 Original date posted:2016-09-22
📝 Original message: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
> >
> > <bitcoin-dev at 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.

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