On Thu, Sep 22, 2016 at 02:09:38PM +0200, Tom via bitcoin-dev wrote: > On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote: > > > > 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. > > > > > 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?
Nope, just clarifying how presence or absence is indicated :-) > > > > 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 It's just some rows have 3 columns, others have 2. It's a minor nit really. > > 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. Same thing I was arguing back then, however Luke pointed out that malleability just refers to the possibility of modifying a transaction after the fact. Always referring to "third-party malleability" avoids this ambiguity. > > 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» Nope, that is exactly the kind of dependency I was talking about. Instead of nesting a construct like the current transactions do, you rely on the order of tokens to imply that they belong together. > 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. Ah, thanks for clearing that up. However, the problem persists, if we add new fields that a non-upgraded node doesn't know about and it rejects transactions containing it, we'll have a hard-fork. It should probably not reject transactions with unknown fields if the transaction is included in a block. > Thank you for your email to my BIP, I hope you got the answers you were > looking for :) Cheers, Christian _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
