📅 Original date posted:2014-10-01
📝 Original message:On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke at dashjr.org> wrote:
> >Thoughts on some way to have the stack item be incremented by the
> >height at
> >which the scriptPubKey was in a block?
>
> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
> scriptPubKey would be:
> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
> (fails unless top stack item is equal to the txin block height)
> <delta height> ADD
> (top stack item is now txin height + delta height)
> CHECKLOCKTIMEVERIFY
This sounds do-able, although it doesn't address using timestamps.
> > A limitation of encoding the target
> >height/time directly, is that miners may choose not to mine the first
> >transaction until they can also take the "burn to fee". So, one may
> >prefer to
> >say "cannot be spent until 100 blocks after the first transaction is
> >mined",
> >in effect reproducing the generation maturity rule.
>
> You'd want these sacrifices to unlock years into the future to thoroughly
> exceed any reasonable business cycle; that's so far into the future that
> miners are almost certain to just mine them and collect the fees.
For many use cases, short maturity periods are just as appropriate IMO.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 15:26:06
in reply to nevent1q…8s9z
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 15:26:06Event JSON
{
"id": "8af6cb574939f69429b401d927ee5fd64909289b70e6cca85f870244a4f59e1f",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686151566,
"kind": 1,
"tags": [
[
"e",
"b0d4dbe43a898155b6750ed1dce6a700ce007fe7f2dce49b1bbfe7e2cca60c4c",
"",
"root"
],
[
"e",
"f134c9c4112e1b98269c21ac8b09ebe274d8642c74d500e2eea62c9c21c31f40",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2014-10-01\n📝 Original message:On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:\n\u003e On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003eThoughts on some way to have the stack item be incremented by the\n\u003e \u003eheight at\n\u003e \u003ewhich the scriptPubKey was in a block?\n\u003e \n\u003e Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.\n\u003e scriptPubKey would be:\n\u003e GET-TXIN-BLOCKHEIGHT-EQUALVERIFY\n\u003e (fails unless top stack item is equal to the txin block height)\n\u003e \u003cdelta height\u003e ADD\n\u003e (top stack item is now txin height + delta height)\n\u003e CHECKLOCKTIMEVERIFY\n\nThis sounds do-able, although it doesn't address using timestamps.\n\n\u003e \u003e A limitation of encoding the target\n\u003e \u003eheight/time directly, is that miners may choose not to mine the first\n\u003e \u003etransaction until they can also take the \"burn to fee\". So, one may\n\u003e \u003eprefer to\n\u003e \u003esay \"cannot be spent until 100 blocks after the first transaction is\n\u003e \u003emined\",\n\u003e \u003ein effect reproducing the generation maturity rule.\n\u003e \n\u003e You'd want these sacrifices to unlock years into the future to thoroughly\n\u003e exceed any reasonable business cycle; that's so far into the future that\n\u003e miners are almost certain to just mine them and collect the fees.\n\nFor many use cases, short maturity periods are just as appropriate IMO.\n\nLuke",
"sig": "bd8526ed417a829471ef9db345fee116aece59ee0c7f8d8ddfe6e9501a586819280fd9dc02bcdf37588e4f55887f76d96195af20d39cbb161c7264b5af6f145b"
}