What is Nostr?
Jorge Tim贸n [ARCHIVE] /
npub1fx9鈥2d8
2023-06-07 17:40:46
in reply to nevent1q鈥9uf

Jorge Tim贸n [ARCHIVE] on Nostr: 馃搮 Original date posted:2015-09-18 馃摑 Original message:On Sep 17, 2015 6:48 PM, ...

馃搮 Original date posted:2015-09-18
馃摑 Original message:On Sep 17, 2015 6:48 PM, "Peter Todd" <pete at petertodd.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Tim贸n via bitcoin-dev" <
bitcoin-dev at 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=
> =pP3Q
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/b761932c/attachment-0001.html>;
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8