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>
This happens for CSV, for example (3-byte encoding), and bitcoind treats
too-long encodings as non-standard.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1) Note incorrect label in txs in Fig1 of LN paper.
2) "an atomic-swap an on-chain.." -> "an atomic-swap *to* an on-chain"
3) "By using a dual anchor and escape transactions" -> "By using a rebalanced single anchor"
4) References to appendices fixed.
5) Move escape transaction scripts out to escape appendix.
6) Fix URL in bibliography (missing comma).
Reported-by: John Newbery
Closes: #11Closes: #12
Reported-by:
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The libsecp change broke signature checking. Disable it for now,
with a big FIXME. The next version should have a method for S value
checking, and also compact serialization.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
switched from pyelliptic to hmac/binascii/cryptography for standard
functions
use our own ECDH implementation to better match the one from secp256k1
finally, add function to create an encrypted onion
Rather than keeping each hop, we can generate it in place since we only
need the first hop result.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we can save the partial HMAC of the padding for each step,
rather than the padding itself, when generating it.
Each step now takes the *last*, not *first* part of the onion array.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Doesn't support getblockheader, also some occasional weirdness
with sequence enforcement for mempool? Occasionally I could get
my spend tx into the mempool (doesn't happen with bitcoin).
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>
Rusty Russell
Douglas Roark
Anthony Towns