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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4504010DF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 13:08:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 817BA235
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 13:08:32 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so30358533wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 06:08:31 -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:date
:message-id:subject:from:to:cc:content-type;
bh=o+n9YKqSWufaY8f1LmUlxfc1ZqXaAEMUhjtnbc2gT3g=;
b=feMPgyXJARja9Ebit4VylaX+9ARbQ+H9ror+psE1pYJcGb2G0Ndqjj1K5SFxTgLj4X
nwKbQ6/BOgQazEg3OJishZbntacsRNqbSMuoztRLR8Q5xisZmB/dgi/LDYxPIW1DAJ+i
4rnn+C6BokhD5XciMEfFeNaXegwivYfeII7yoHiA6O2f4/sEgmalDcQ0g5GkPh0VNNda
NT1zn7hHmwK8XD4rmiTgq4+rcf91fssZO7qNmxp2Cdszb7UGrLv8kEC7m1MEX+J3xakw
5YlE6srez6cJzX0bfCNVIBA059wCLiCABtGDfNLIWs5aReDTTkTsmOcs2hzmq5W8iuDz
4Tqw==
X-Gm-Message-State: ALoCoQkHZOHDfmBpdFVVm+zGuNVfu4z/JXMqxuBW7Teo8ZNdoHdNwSlLkH62HAD05sMot8EJvc55
MIME-Version: 1.0
X-Received: by 10.180.103.72 with SMTP id fu8mr38565560wib.7.1442581710924;
Fri, 18 Sep 2015 06:08:30 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Fri, 18 Sep 2015 06:08:30 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Fri, 18 Sep 2015 06:08:30 -0700 (PDT)
In-Reply-To: <C9A1D16E-03F7-4860-8E9B-32A98E06CE49@petertodd.org>
References: <a50b82c156c805a284386d80a42cc926@xbt.hk>
<CAOG=w-vGqsAcw5vdY8SaGVe4Q6XX1J=GCsZftWgjES_N_5c2pA@mail.gmail.com>
<CABm2gDp_afyqskEV8QmO43=-6R_2OJm36GVQxcQO_3ao2jC1gw@mail.gmail.com>
<C9A1D16E-03F7-4860-8E9B-32A98E06CE49@petertodd.org>
Date: Fri, 18 Sep 2015 15:08:30 +0200
Message-ID: <CABm2gDroAU7ovq_qEOw6sCTYM+a7cYHAAkjM5uL6ajPH9aDmHQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=f46d0444e9e97086540520053aac
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fill-or-kill transaction
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2015 13:08:33 -0000
--f46d0444e9e97086540520053aac
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sep 17, 2015 6:48 PM, "Peter Todd" <pete@petertodd.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Tim=C3=B3n via bitcoin-de=
v" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Fill or kill us normally used for trades and I think it can be
> >confusing.
> >Previous times this has been discussed it has been discussed under
> >nExpiryTime or op_height (which enables expiration), for example, in
> >the
> >freimarkets white paper.
> >
> >As Mark points out this can be made safe by requiring that all the
> >outputs
> >of a transaction that can expire have op_maturity/csv/rcltv of 100.
> >That
> >makes them as reorg-safe as coinbase transactions. Unfortunately this
> >doesn't play very well with p2sh...
>
> Why wouldn't that work with p2sh? It can be implemented by a "treat like
Coinbase" flag in the UTXO set, set when the output is created.
I said require all scrptPubkeys to have op_maturity/rcltv/csv 100+, but
yeah, that would work.
Regarding nKillTime, please call it nExpiryTime. And instead of fill or
kill transactions, ttansactions that expire. It is not only more accurate
(ie fill or kill is for market orders that complete in their full amount
now or are cancelled, not for transfers) and it is the term we have been
using for years.
Reinventing the wheel by changing its name it's something we do often (for
example, rcltv was op_maturity in February 2014 and was "reinvented" as
rcltv recently. This makes it harder for people to learn and follow up.
Please don't insist in fok, that's for market orders and works differently
than expiries. Expiry is the old name and it's also much more accurate.
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip
> AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb
> OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w
> kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g
> xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA
> 3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk
> MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4=3D
> =3DpP3Q
> -----END PGP SIGNATURE-----
>
--f46d0444e9e97086540520053aac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Sep 17, 2015 6:48 PM, "Peter Todd" <<a href=3D"mailto:pete@=
petertodd.org">pete@petertodd.org</a>> wrote:<br>
><br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA512<br>
><br>
><br>
><br>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Tim=C3=B3n via bi=
tcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> >Fill or kill us normally used for trades and I think it can be<br>
> >confusing.<br>
> >Previous times this has been discussed it has been discussed under=
<br>
> >nExpiryTime or op_height (which enables expiration), for example, =
in<br>
> >the<br>
> >freimarkets white paper.<br>
> ><br>
> >As Mark points out this can be made safe by requiring that all the=
<br>
> >outputs<br>
> >of a transaction that can expire have op_maturity/csv/rcltv of 100=
.<br>
> >That<br>
> >makes them as reorg-safe as coinbase transactions. Unfortunately t=
his<br>
> >doesn't play very well with p2sh...<br>
><br>
> Why wouldn't that work with p2sh? It can be implemented by a "=
;treat like Coinbase" flag in the UTXO set, set when the output is cre=
ated.</p>
<p dir=3D"ltr">I said require all scrptPubkeys to have op_maturity/rcltv/cs=
v 100+, but yeah, that would work.</p>
<p dir=3D"ltr">Regarding nKillTime, please call it nExpiryTime. And instead=
of fill or kill transactions, ttansactions that expire. It is not only mor=
e accurate (ie fill or kill is for market orders that complete in their ful=
l amount now or are cancelled, not for transfers) and it is the term we hav=
e been using for years.</p>
<p dir=3D"ltr">Reinventing the wheel by changing its name it's somethin=
g we do often (for example, rcltv was op_maturity in February 2014 and was =
"reinvented" as rcltv recently. This makes it harder for people t=
o learn and follow up.<br>
Please don't insist in fok, that's for market orders and works diff=
erently than expiries. Expiry is the old name and it's also much more a=
ccurate.<br></p>
<p dir=3D"ltr">><br>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip<br>
> AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb<br>
> OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w<br>
> kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g<br>
> xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA<br>
> 3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk<br>
> MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4=3D<br>
> =3DpP3Q<br>
> -----END PGP SIGNATURE-----<br>
><br>
</p>
--f46d0444e9e97086540520053aac--
|
