Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

From: Mark Friedenbach <[email-masked]>
Date: Sun, 14 Jun 2015 19:47:15 -0700

There's another important use case which you mentioned Greg, that also
requires special exemption: compact commitments via mid-state compression.

The use case is an OP_RETURN output sorted last, whose last N bytes are a
commitment of some kind. A proof of the commitment can then use mid state
compression to elide the beginning of the transaction.

How do you make a special exemption for this category of outputs? I can't
think of a very clean way of doing so that doesn't require an ugly
advertising of sort-order exemptions.

The fact that we have two different existing use cases which conflict with
soft-fork enforcement, I'm quiet concerned that there are either other
things we aren't thinking of or haven't invented yet which would be
affected.

On Sun, Jun 14, 2015 at 7:33 PM, Gregory Maxwell <[email-masked]> wrote:

> On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell <[email-masked]>
> wrote:
> > 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.
>
> Oh.
>
> Hm.
>
> It is the case that the generalized sighash flag design I was thinking
> about was actually completely neutral about ordering, and yet still
> replaced SINGLE.
>
> I need to think a bit on that.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>