Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

[Tom <tomz@freedommail.ch>]

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 wrote:
> > > On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
> > > 
> > > <bitcoin-dev@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 

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
> > 
> > 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.

I'm sorry, I'm not following you here. Is there a question?


> > > 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.

I am not very well versed in mediawiki tables, and I found github has some 
incompatibilities too.
The markdown one looks better;
https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.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 and re-
signing it is not changing anything. Its re-creating. Something that the owner 
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. 

Sorry, what is evident? You seem to imply that it is uncommon that you can 
create two transactions of similar intent but using different bytes.
You would be wrong with this implication as this is very common. You can just 
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 
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; 
  «TxInPrevHash and TxInPrevIndex
   Index can be skipped, but in any input the PrevHash always has
   to come first»

If you still see something alarming, let me know.
You can look at the code in Bitcoin Classic and notice that it really isn't 
anything complicated or worrying.


> Finally, allowing miners to reject transactions with unknown fields
> makes the OP_NOPs unusable 

Hmm, it looks like you are mixing terminology and abstraction-levels.  OP_NOP 
is a field from script and there is no discussion about any rejection based on 
script in this BIP at all.

Rejection of transactions is done on there being unrecognised tokens in the 
transaction formatting itself.

Thank you for your email to my BIP, I hope you got the answers you were 
looking for :)