Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4504010DF for ; 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 ; Fri, 18 Sep 2015 13:08:32 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so30358533wic.1 for ; 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: References: Date: Fri, 18 Sep 2015 15:08:30 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Peter Todd 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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


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 bi= tcoin-dev" <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 t= his
> >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 cre= ated.

I said require all scrptPubkeys to have op_maturity/rcltv/cs= v 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 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.

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.
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.

>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip
> AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb
> OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w
> kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g
> xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA
> 3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk
> MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4=3D
> =3DpP3Q
> -----END PGP SIGNATURE-----
>

--f46d0444e9e97086540520053aac--