I've written a reference implementation and BIP draft for a new opcode,
CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:
https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
The reference implementation, including a full-set of
Very nice, semantics are clear and use cases are compelling.
Can we defer discussion of how to roll this out for a little bit, and see
if there is consensus that:
a) benefits of having this outweigh risks
b) we're all happy with exact semantics
Then we can have a knock-down drag-out argument
I like the proposal.
I suggest that applications and nodes should only broadcast transactions
having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value.
If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is
equal to the current height and equal to the timeout value,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Yeah, there are lots of upper-level details to consider; I'm not going to
pretend that BIP is complete yet. My thinking is that the first release should
include my NOPx blacklist pull-req, and leave NOP2/CHECKLOCKTIMEVERIFY in that
blacklist for
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
On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr l...@dashjr.org wrote:
houghts 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
On 10/01/2014 04:58 PM, Gavin Andresen wrote:
If the first transaction is P2SH, then the miner won't know there is
an advantage to holding it until it is too late (the scriptPubKey is
an opaque hash until the second transaction is final and
relayed/broadcast).
If you're doing some kind of
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com wrote:
On 10/01/2014 04:58 PM, Gavin Andresen wrote:
If the first transaction is P2SH, then the miner won't know there is
an advantage to holding it until it is too late (the scriptPubKey is
an opaque hash until the second
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
wrote:
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com
wrote:
No, the burner would supply the funding transaction plus the redeeming
script as the
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen gavinandre...@gmail.com
wrote:
Very nice, semantics are clear and use cases are compelling.
Thanks!
Can we defer discussion of how to roll this out for a little bit, and
see
if there is
https://bitcointalk.org/index.php?topic=145066.0
The idea proposed in the above article seemed like an excellent idea. What
is holding this up from being implemented? Does someone need to code it, or
write a BIP first?
--
It already is https://bitcointalk.org/index.php?topic=766190.0;all.
Well, ok, a variation on the idea is.
Matt
On 10/02/14 04:39, Rebroad (sourceforge) wrote:
https://bitcointalk.org/index.php?topic=145066.0
The idea proposed in the above article seemed like an excellent idea.
What is
14 matches
Mail list logo
