MIME-Version: 1.0
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: Tue, 22 Sep 2015 19:45:00 +0200
Message-ID: <CABm2gDrqLf_YmG9BtxfANkfbXpA_7sm79ZoG5cJHog0a2O=4BA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: =?UTF-8?Q?Jorge_Tim=C3=B3n_via_bitcoin=2Ddev?=
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fill-or-kill transaction
Precedence: list

On Fri, Sep 18, 2015 at 12:44 AM, 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.

That would work. I was thinking about requiring OP_MATURITY 100 (or
greater than 100) in all the scriptPubKey's of the expiry transaction.