public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Danny Thorpe <danny.thorpe@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Date: Wed, 21 Oct 2015 11:22:25 -0700	[thread overview]
Message-ID: <CAJN5wHXSbZPuXN7PQRyOgOMuk2Ogooiww3hW93uNipQJnfkeOg@mail.gmail.com> (raw)
In-Reply-To: <201510210846.43988.luke@dashjr.org>

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

A signer modifying the order of inputs or changing outputs when
"re-signing" a transaction (which already has dependent child transactions
spending its outputs) seems like quite a different hazard than a malicious
third party modifying a transaction in the mempool by twiddling opcodes in
the signature scripts.  The former seems like more a matter of keeping your
own house in order (an internal affair) while the latter is an external
threat beyond the transaction writer's control.

While I agree that having a canonical ordering for inputs and outputs might
be useful in some cases, there are also use cases where the relative
positions of inputs and outputs are significant, where reordering would
change the semantics of the transaction.  SIGHASH_SINGLE, for example,
makes an association between an input index and an output index. Open Asset
colored coins are identified by the order of inputs and outputs.

Let's keep canonical ordering separate from the normalized transaction ID
proposal. Baby steps. Normalized transaction IDs provide an immediate
benefit against the hazard of third party manipulation of transactions in
the mempool, even without canonical ordering.

-Danny





On Wed, Oct 21, 2015 at 1:46 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wednesday, October 21, 2015 8:44:53 AM Christian Decker wrote:
> > Hm, that is true as long as the signer is the only signer of the
> > transaction, otherwise he'd be invalidating the signatures of the other
> > signers.
>
> Or he can just have the other signers re-sign with the modified version.
> Even if it only worked with a single signer, it's still a form of
> malleability
> that your BIP does not presently solve, but would be desirable to solve...
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2717 bytes --]

  reply	other threads:[~2015-10-21 18:22 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19 14:01 [bitcoin-dev] [BIP] Normalized transaction IDs Christian Decker
2015-10-19 15:23 ` Tier Nolan
2015-10-19 19:28   ` Christian Decker
2015-10-19 22:22   ` s7r
2015-10-20 10:30     ` Christian Decker
2015-10-21  6:18 ` Luke Dashjr
2015-10-21  7:39   ` Christian Decker
2015-10-21  7:52     ` Luke Dashjr
2015-10-21  8:31       ` Christian Decker
2015-10-21  8:39         ` Luke Dashjr
2015-10-21  8:44           ` Christian Decker
2015-10-21  8:46             ` Luke Dashjr
2015-10-21 18:22               ` Danny Thorpe [this message]
2015-10-21 19:27                 ` Gregory Maxwell
2015-10-21 23:20                 ` Luke Dashjr
2015-10-22  8:26                   ` Christian Decker
2015-10-22  8:57                     ` Gregory Maxwell
2015-10-22 11:54                       ` Christian Decker
2015-10-22  9:05                     ` Luke Dashjr
2015-11-03 20:37                       ` Christian Decker
2015-11-03 20:48                         ` Luke Dashjr
2015-11-03 21:44                           ` Christian Decker
2015-11-03 22:01                             ` Luke Dashjr
2015-11-05 15:27                               ` Jorge Timón
2015-11-05 19:36                                 ` Luke Dashjr
2015-11-05 20:25                                   ` Jorge Timón
2015-11-05 22:46                                     ` s7r
2015-11-05 22:29                                   ` Adam Back
2015-11-06 14:52                                 ` Christian Decker
2015-11-04  4:00                             ` Peter Todd
2015-11-05  9:38                               ` Christian Decker
2015-10-21  7:48   ` Gregory Maxwell
2015-10-21  8:26     ` Gregory Maxwell
2015-10-21  8:49       ` Christian Decker
2015-10-21  8:50         ` Christian Decker
2015-10-21 10:14         ` Gregory Maxwell

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=CAJN5wHXSbZPuXN7PQRyOgOMuk2Ogooiww3hW93uNipQJnfkeOg@mail.gmail.com \
    --to=danny.thorpe@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.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