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
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?
--
-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
-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
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 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
-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.
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
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 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 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
-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
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
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'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
15 matches
Mail list logo
