📅 Original date posted:2015-06-02
📝 Original message:>
> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time. That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>
Very good point.
>
> (Not a huge flexibility loss as you can implement "not after" by
> making it the previous holders responsibility to spend a "not before"
> back to themselves.)
>
Do you mean something like the below?
scriptPubKey:
IF
{A's pub} CHECKSIGVERIFY
ELSE
{curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY
This ensures that Alice has to spend the output in the next 100 blocks or
risk it being taken from her (she just has to put an OP_TRUE on the end of
her scriptSig). So, it seems we can forget about an inverted CLTV/CSV,
great!
Best,
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/16a5e2ae/attachment.html>;
Stephen Morse [ARCHIVE] /
npub1ja…q0j2u
2023-06-07 15:36:29
in reply to nevent1q…2drk
Author Public Key
npub1ja0fa5k6j04r2h7jp33lvdy2kzpv5yj60ce4wvcca7fvxe99hw5qqq0j2uPublished at
2023-06-07 15:36:29Event JSON
{
"id": "1df2df73a1099f598d79f78535e29cc6a8f9fafab8a2cacf47863aa00e8c769e",
"pubkey": "975e9ed2da93ea355fd20c63f6348ab082ca125a7e33573318ef92c364a5bba8",
"created_at": 1686152189,
"kind": 1,
"tags": [
[
"e",
"c9cd3767924703c60bb1997e362d632367ff7c2eb45cc07fa7ae094ab6e4a3f3",
"",
"root"
],
[
"e",
"e43abff71ba878f1d9df35f7b3b53df9f218a5af88b1054af5dae405cca32fc0",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2015-06-02\n📝 Original message:\u003e\n\u003e That would also introduce the anomaly of a script that was once valid\n\u003e becoming later invalid, when nothing varies other than time. That is\n\u003e not super compatible with the current model of reprocessing\n\u003e transactions in later blocks if the block they were first in gets\n\u003e reorged.\n\u003e\n\nVery good point.\n\n\n\u003e\n\u003e (Not a huge flexibility loss as you can implement \"not after\" by\n\u003e making it the previous holders responsibility to spend a \"not before\"\n\u003e back to themselves.)\n\u003e\n\nDo you mean something like the below?\n\nscriptPubKey:\n IF\n {A's pub} CHECKSIGVERIFY\n ELSE\n {curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY\n\nThis ensures that Alice has to spend the output in the next 100 blocks or\nrisk it being taken from her (she just has to put an OP_TRUE on the end of\nher scriptSig). So, it seems we can forget about an inverted CLTV/CSV,\ngreat!\n\nBest,\nStephen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/16a5e2ae/attachment.html\u003e",
"sig": "f6cd8465d9e04766415cc91ea4bd56df2b378f911f59da9762e1360a340948612082cb17024303a390b2bea74887a1010ad7e660c9ac02a61a90289f98d2b11d"
}