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 <mark@friedenbach.org>) 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 <bitcoin-development@lists.sourceforge.net>; 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: <CAAS2fgTY5cqwj5XuKtkD8Z8N1vF=PZMba8EtGkbWnEackOcN8Q@mail.gmail.com> References: <87k2vhfnx9.fsf@rustcorp.com.au> <CAAS2fgRgWZX_O_2O1bgdFd_04xVp5Lnpw4hf=v6RSTXmsbdzPQ@mail.gmail.com> <87r3pdembs.fsf@rustcorp.com.au> <CAAS2fgTY5cqwj5XuKtkD8Z8N1vF=PZMba8EtGkbWnEackOcN8Q@mail.gmail.com> From: Mark Friedenbach <mark@friedenbach.org> Date: Sun, 14 Jun 2015 19:47:15 -0700 Message-ID: <CAOG=w-tJjzrR_REJOShULfSO=T3ueHko-oQHdhqMCdZD0G_BDA@mail.gmail.com> To: Gregory Maxwell <gmaxwell@gmail.com> 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 <bitcoin-development@lists.sourceforge.net> 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: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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 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 <div dir=3D"ltr"><div><div>There's another important use case which you= mentioned Greg, that also requires special exemption: compact commitments = via mid-state compression.<br><br>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.<br><br></div>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.<br><br></div>= 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.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot= e">On Sun, Jun 14, 2015 at 7:33 PM, Gregory Maxwell <span dir=3D"ltr"><<= a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</= a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On = Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell <<a href=3D"mailto:rusty@rus= tcorp.com.au">rusty@rustcorp.com.au</a>> wrote:<br> > The softfork argument I find the most compelling, though it's temp= ting<br> > to argue that every ordering use (including SIGHASH_SINGLE) is likely<= br> > a mistake.<br> <br> </span>Oh.<br> <br> Hm.<br> <br> It is the case that the generalized sighash flag design I was thinking<br> about was actually completely neutral about ordering, and yet still<br> replaced SINGLE.<br> <br> I need to think a bit on that.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> ---------------------------------------------------------------------------= ---<br> _______________________________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/= listinfo/bitcoin-development</a><br> </div></div></blockquote></div><br></div> --047d7bdcab34f7435f0518857aa1--