From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4KR9-0004w7-7L for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 02:47:47 +0000 X-ACL-Warn: Received: from mail-ig0-f175.google.com ([209.85.213.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4KR5-0005Dq-Nc for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 02:47:47 +0000 Received: by igblz2 with SMTP id lz2so41533787igb.1 for ; Sun, 14 Jun 2015 19:47:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MFYgPDrcPN7+exCmmBmmBdkQ8UFJL6Jq/4pUk1363ag=; b=hLfOtpX0kR9d+dM/634iBkr8OJoozorre/kJ5DL8QcWfTATfFHX1lUKjCMxVAOnmhM NPPFdEg+X2TN1QjamodWPNYOU+o+4YL+jifXW+L+WChUbRlsSXTOZH2ZZOQSz7kTeuF3 dibhW8V3jnVMhB6YAsrg275kVeCYPlABkSX4Zd9h1/4X8UZX06udUgY06IMygIWMRpjZ SaBm6gHX4LIi2AFq17Ai4rYiV+goHjKaFiGZCUSfnTaId6HvJF8UOswL1Ov1AFtmenfj Em4HUauPAHbJVmmKhRSS38HeWee7I6ukNu7DX4sei6L8f3itI90gLdbvqjuu7AEORdMa jEOQ== X-Gm-Message-State: ALoCoQn/hRgeaEruKhxuCsAp9egtFBCR/8NlHW0YQ+5hqko08mtqx8auj/D32RO0BhXNzpru6tQG X-Received: by 10.50.62.148 with SMTP id y20mr17688028igr.17.1434336456274; Sun, 14 Jun 2015 19:47:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.20 with HTTP; Sun, 14 Jun 2015 19:47:15 -0700 (PDT) X-Originating-IP: [50.0.37.37] In-Reply-To: References: <87k2vhfnx9.fsf@rustcorp.com.au> <87r3pdembs.fsf@rustcorp.com.au> From: Mark Friedenbach Date: Sun, 14 Jun 2015 19:47:15 -0700 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7bdcab34f7435f0518857aa1 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z4KR5-0005Dq-Nc Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 02:47:47 -0000 --047d7bdcab34f7435f0518857aa1 Content-Type: text/plain; charset=UTF-8 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 wrote: > On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7bdcab34f7435f0518857aa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 sorte= d last, whose last N bytes are a commitment of some kind. A proof of the co= mmitment can then use mid state compression to elide the beginning of the t= ransaction.

How do you make a special exemption for this categ= ory of outputs? I can't think of a very clean way of doing so that does= n'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 <<= a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com> wrote:
On = Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> The softfork argument I find the most compelling, though it's temp= ting
> to argue that every ordering use (including SIGHASH_SINGLE) is likely<= br> > 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development

--047d7bdcab34f7435f0518857aa1--