馃搮 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.
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 17:40:46
in reply to nevent1q鈥f6c
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Seen on
wss://relay.nostr.bandPublished at
2023-06-07 17:40:46Event 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"
}