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.
next prev parent 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 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$(echo .)com.au \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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