This could only happen via our RPC interface (bitcoind should not give
us bad txs!) but it's better to be robust.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Without Alpha, it's superfluous. We're about to add segwit support,
but linearization requires a more powerful approach, and segwit
signature checking is completely different and really deserves its
own function.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I had already disabled it, and this clears the decks for Segregated Witness
which gives us everything we want.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
