Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-23 📝 Original message:On Thu, Sep 22, 2016 at ...
📅 Original date posted:2016-09-23
📝 Original message: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
📝 Original message: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