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

Mark Friedenbach mark at friedenbach.org
Mon Jun 15 02:47:15 UTC 2015


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 <gmaxwell at gmail.com> wrote:

> On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell <rusty at rustcorp.com.au>
> 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
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/cd07104d/attachment.html>


More information about the bitcoin-dev mailing list