Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2014-10-01 📝 Original message:On Wednesday, October 01, ...
📅 Original date posted:2014-10-01
📝 Original message:On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
> I've written a reference implementation and BIP draft for a new opcode,
> CHECKLOCKTIMEVERIFY.
Thoughts on some way to have the stack item be incremented by the height at
which the scriptPubKey was in a block? 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.
I propose any stack item under 0x40000 be incremented by the height at which
the scriptPubKey was mined for comparison. Maybe there is a use case for doing
something similar for time too?
Luke
📝 Original message:On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
> I've written a reference implementation and BIP draft for a new opcode,
> CHECKLOCKTIMEVERIFY.
Thoughts on some way to have the stack item be incremented by the height at
which the scriptPubKey was in a block? 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.
I propose any stack item under 0x40000 be incremented by the height at which
the scriptPubKey was mined for comparison. Maybe there is a use case for doing
something similar for time too?
Luke