1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
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--
|
