All the members of the transaction should be allocated off the
transaction, as they have the same lifetime.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I got confused navigating these, especially since Alpha and Bitcoin
have diverged (BIP68 was proposed after Elements Alpha).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The format for both the nSequence field and the stack arg for
OP_CHECKSEQUENCEVERIFY is either:
Time-relative: [Bit 22 = 1] 00000 <time-shifted-by-9>
Block-relative: [Bit 22 = 0] 00000 <number of blocks>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The latest version of the BIP doesn't use inversion, but does use
bitshifts.
It also uncovered a bug in the test scripts: the block timestamps
creep forward when we generate large numbers of blocks (UpdateTime
insists it be > GetMedianTimePast() so it's valid). We need to take
this into account when waiting for the median to move (reduced it from
60 to 30 seconds, since that adds about 14 seconds).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It doesn't matter until we start setting sequence numbers properly,
so hasn't been noticed until now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Otherwise valgrind tells you when you test a hash; you want to
know if you hash uninitialized memory long before that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
