From: Christian Decker <decker.christian@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Date: Fri, 23 Sep 2016 13:42:36 +0200 [thread overview]
Message-ID: <20160923114236.GA17871@nex> (raw)
In-Reply-To: <6286144.BZfBM3Z3un@garp>
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
next prev parent reply other threads:[~2016-09-23 11:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 17:15 Tom
2016-09-20 21:31 ` Luke Dashjr
2016-09-21 9:32 ` Tom
2016-09-20 21:56 ` Peter Todd
2016-09-21 9:32 ` Tom
2016-09-22 18:26 ` Peter Todd
2016-09-22 18:47 ` Tom
2016-09-21 12:00 ` Andreas Schildbach
2016-09-21 12:58 ` Tom
[not found] ` <CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
2016-09-21 18:01 ` Gregory Maxwell
2016-09-22 8:56 ` Tom
2016-09-22 11:10 ` Christian Decker
2016-09-22 12:09 ` Tom
2016-09-23 11:42 ` Christian Decker [this message]
2016-09-23 13:17 ` Tom
2016-09-21 22:45 adiabat
2016-09-22 8:47 ` Tom
2016-09-22 18:27 ` Peter Todd
2016-09-22 18:37 ` Tom
2016-09-22 19:59 ` Jonas Schnelli
2016-09-22 20:07 ` Tom
2016-09-23 11:55 ` Christian Decker
2016-09-23 13:13 ` Tom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160923114236.GA17871@nex \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox