public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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


  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 [bitcoin-dev] Requesting BIP assignment; Flexible Transactions 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.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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