public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
Date: Mon, 15 Jun 2015 11:59:11 +0930	[thread overview]
Message-ID: <87r3pdembs.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAAS2fgRgWZX_O_2O1bgdFd_04xVp5Lnpw4hf=v6RSTXmsbdzPQ@mail.gmail.com>

Gregory Maxwell <gmaxwell@gmail.com> writes:
> I'm not a great fan of this proposal for two reasons: The first is
> that the strict ordering requirements is incompatible with future
> soft-forks that may expose additional ordering constraints. Today we
> have _SINGLE, which as noted this interacts with poorly, but there
> have been other constraints proposed that this would also interact
> with poorly.

Yes, I hit this when I implemented an IsStandard change; upon input
evaluation the scriptsigs which used _SINGLE get disregarded from
ordering.  

> The second is that even absent consensus rules there may be invisible
> constraints in systems-- e.g. hardware wallets that sign top down,

I think that one's pretty easy to fix (and they should fix it anyway, to
avoid leaking information due to ordering): they can receive an
unordered tx and sign it as if it were ordered canonically.

> or
> future transaction covenants that have constraints about ordering,  or
> proof systems that use (yuck) midstate compression for efficiency.

The softfork argument I find the most compelling, though it's tempting
to argue that every ordering use (including SIGHASH_SINGLE) is likely
a mistake.

> I think perhaps the motivations here are understated. We have not seen
> any massive deployments of accidentally broken ordering that I'm aware
> of-- and an implementation that got this wrong in a harmful way would
> likely make far more fatal mistakes (e.g. non random private keys).

I was prompted to propose something by this:

https://blog.blocktrail.com/2015/05/getting-your-change-in-order/

If that's the only one though, it's less compelling.

> As an alternative to this proposal the ordering can be privately
> derandomized in the same way DSA is, to avoid the need for an actual
> number source.  If getting the randomness right were really the only
> motivation, I'd suggest we propose a simple derandomized randomization
> algorithm--- e.g. take the order from (H(input ids||client secret)).
>
> I think there is actually an unstated motivation also driving this
> (and the other) proposal related to collaborative transaction systems
> like coinjoins or micropayment channels; where multiple clients need
> to agree on the same ordering. Is this the case? If so we should
> probably talk through some of the requirements there and see if there
> isn't a better way to address it.

Indeed.  I was implementing deterministic permutations for lightning
(signature exchange requires both sides agree on ordering).

Cheers,
Rusty.



  reply	other threads:[~2015-06-15  2:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-06  4:42 [Bitcoin-development] [RFC] Canonical input and output ordering in transactions Rusty Russell
2015-06-06  4:46 ` Mark Friedenbach
2015-06-06  6:44   ` Rusty Russell
2015-06-06  8:24   ` Wladimir J. van der Laan
2015-06-06  9:45     ` Mark Friedenbach
2015-06-08 21:25 ` Danny Thorpe
2015-06-08 21:36   ` Peter Todd
2015-06-14 23:04   ` Gregory Maxwell
2015-06-14 23:02 ` Gregory Maxwell
2015-06-15  2:29   ` Rusty Russell [this message]
2015-06-15  2:33     ` Gregory Maxwell
2015-06-15  2:47       ` Mark Friedenbach
2015-06-15 21:01         ` Rusty Russell
2015-06-16  7:10           ` Jorge Timón
2015-06-16  8:06             ` Rusty Russell
     [not found]               ` <CABm2gDpkwHvrsB8Dh-hsO6H9trcweEX9XGB5Jh5KLPsPY5Z1Sw@mail.gmail.com>
2015-06-21  7:27                 ` [Bitcoin-development] Fwd: " Jorge Timón
2015-06-15  4:01   ` [Bitcoin-development] " Kristov Atlas
2015-06-24 22:09     ` [bitcoin-dev] " Kristov Atlas

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=87r3pdembs.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gmaxwell@gmail.com \
    /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