📅 Original date posted:2015-09-22 📝 Original message:On Fri, Sep 18, 2015 at ...

Jorge Timón [ARCHIVE] /

npub1fx9…l2d8

2023-06-07 17:40:46

in reply to nevent1q…af6c

📅 Original date posted:2015-09-22
📝 Original message:On Fri, Sep 18, 2015 at 12:44 AM, 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.

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

Author Public Key

npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8

Show more details

Published at

2023-06-07 17:40:46

Kind type

1 Short Text Note

Event JSON

{ "id": "430201ac481be590411212cd1c97c7d823b6c3a3bcc9528ba8fdd34bb42c61c7", "pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84", "created_at": 1686159646, "kind": 1, "tags": [ [ "e", "d245f3cd2427d9c30e488b3eacebf2ae42b122d633366f33db323c8696dd9375", "", "root" ], [ "e", "01a9e103f848afaa8a12275075868fcb908d26726a31f14a6425ed133d15bf07", "", "reply" ], [ "p", "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84" ] ], "content": "📅 Original date posted:2015-09-22\n📝 Original message:On Fri, Sep 18, 2015 at 12:44 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA512\n\u003e\n\u003e\n\u003e\n\u003e On 17 September 2015 12:14:38 GMT-07:00, \"Jorge Timón via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003eFill or kill us normally used for trades and I think it can be\n\u003e\u003econfusing.\n\u003e\u003ePrevious times this has been discussed it has been discussed under\n\u003e\u003enExpiryTime or op_height (which enables expiration), for example, in\n\u003e\u003ethe\n\u003e\u003efreimarkets white paper.\n\u003e\u003e\n\u003e\u003eAs Mark points out this can be made safe by requiring that all the\n\u003e\u003eoutputs\n\u003e\u003eof a transaction that can expire have op_maturity/csv/rcltv of 100.\n\u003e\u003eThat\n\u003e\u003emakes them as reorg-safe as coinbase transactions. Unfortunately this\n\u003e\u003edoesn't play very well with p2sh...\n\u003e\n\u003e 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.\n\nThat would work. I was thinking about requiring OP_MATURITY 100 (or\ngreater than 100) in all the scriptPubKey's of the expiry transaction.", "sig": "caf7e9ad7e82eec7f52c90b7ee6a209fd825ad99154d06be897594d302cca2e80c16551424a166a3a795ae45f45d2aefb5f6792e22b787575b1cf7594e2e7229" }