Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2014-10-01 📝 Original message:On Thursday, October 02, ...

📅 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