From: Tom <tomz@freedommail.ch>
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"
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Precedence: list

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
> > > <bitcoin-dev@lists.linuxfoundation.org> 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 :)