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 unittest
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 abo
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, but
-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 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
> transaction until
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 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 transaction is f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr 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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 14:34:33 GMT-07:00, Gavin Andresen
wrote:
>On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner
>wrote:
>No, the burner would supply the funding transaction plus the redeeming
>script as the proof-of-burn to whoever needed the proof.
N
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr 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)-EQ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 08:01:28 GMT-07:00, Gavin Andresen
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 consensus that:
>
>a) ben
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr wrote:
>On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
>> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr
>wrote:
>> >Thoughts on some way to have the stack item be incremented by t
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 ho
15 matches
Mail list logo
