Update libsecp256k1 has a normalize function, which allows us to test
if the signature was in low-S form.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use libsecp256k1 to convert signatures to DER; we were creating a
temporary one, but we really should be handing the one we have in dstate
through. This does that, everywhere.
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>
We don't want to re-create them internally, ever.
The test-cli tools are patched to generate them all the time, but
they're not performance critical.
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>
The even-S check was based on https://github.com/sipa/bitcoin/commit/a81cd9680
which was replaced by a low-S check in commit e0e14e43d9586409e42919f6cb955540134cda2a
Abstract out and fix the check.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I had each side using the other side's hash secret. That's a very
dumb idea, since it means you can steal from a unilateral close!
A's secret applies to A's commit transaction: it needs the
secret and B's final signature to steal funds, and that should
never happen (since A doesn't have the B's final signature, and
once A has given B the secret, they never broadcast the commit tx).
This makes the update a 4 step dance, since you need the new
revocation hash to make the other side's TX to sign.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
DER encoding introduces problems for non-canonical encodings; we should
do that only at the lightning<->bitcoin interface.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell