<oembed><type>rich</type><version>1.0</version><author_name>npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_name><author_url>https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-09-17&#xA;📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----&#xA;Hash: SHA512&#xA;&#xA;&#xA;&#xA;On 17 September 2015 12:14:38 GMT-07:00, &#34;Jorge Timón via bitcoin-dev&#34; &lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt;Fill or kill us normally used for trades and I think it can be&#xA;&gt;confusing.&#xA;&gt;Previous times this has been discussed it has been discussed under&#xA;&gt;nExpiryTime or op_height (which enables expiration), for example, in&#xA;&gt;the&#xA;&gt;freimarkets white paper.&#xA;&gt;&#xA;&gt;As Mark points out this can be made safe by requiring that all the&#xA;&gt;outputs&#xA;&gt;of a transaction that can expire have op_maturity/csv/rcltv of 100.&#xA;&gt;That&#xA;&gt;makes them as reorg-safe as coinbase transactions. Unfortunately this&#xA;&gt;doesn&#39;t play very well with p2sh...&#xA;&#xA;Why wouldn&#39;t that work with p2sh? It can be implemented by a &#34;treat like Coinbase&#34; flag in the UTXO set, set when the output is created.&#xA;-----BEGIN PGP SIGNATURE-----&#xA;&#xA;iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV+0Ip&#xA;AAoJEMCF8hzn9Lncz4MIAIQpz7tKbmjEuETX6BnPatJ50I+kS6CQ4eE+e1irXpbb&#xA;OCMe0A2TGzw9G5t7DgMU1lCcbcbuqOxMOrHYXuGsGkpVtRrLFbkS/F9vCS2RJT0w&#xA;kRkL2ecN8riAjh1lUUgY1CEgVyhkwh6Rw1ZALu3Ba2tISysMfXjAW1GiLHlgxP7g&#xA;xD6zS0OTTokG/7+s1hGK2Nd4q/ZHnfOO1JgiBzrykGNq4enp7nRhiZKhnc/0ILJA&#xA;3WAsAMI14ZUxs95onjey7J3100tZBetYr14jzLRvf+w1klBNSvcen9dr+VhdyXYk&#xA;MPMOwuUtq4OI1vt3HDoMjNFT6olg0gTxzWe8Grn96S4=&#xA;=pP3Q&#xA;-----END PGP SIGNATURE-----</html></oembed>