You need to be running a bitcoind modified with segregated witness:
https://github.com/sipa/bitcoin/tree/segwit4
It needs 432 blocks to activate it!
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're about to change the protocol again, and I don't want to do the
grunt work to update these. They were useful for pre-build protocol
testing, though.
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>
Use our own structure with the information we need about HTLCs,
and remove protobufs from the API.
The is_funder() helper goes inside gather_updates.h.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Hand anchor details and pubkeys directly; this is what we want
for the actual daemon which doesn't keep raw packets around.
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>
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>
For the moment, there's no way to remove an in-progress HTLC before
it's timed out. The other side can remove it with a routefail, but
you can't push for it to be removed.
We may add that later, but by definition it's only a polited request, and
normally we should rely on timeouts.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This gets truncated for on-chain transactions (thus, rounding may
contribute to fees).
This also means we currently have an upper bound of 0.04 BTC per HTLC;
this can be increased later if required.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our current proto_to_locktime actually handles relative locktimes,
and HTLCs use absolute. Fix that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For open transactions, locktime is a delay we require on the other
side's to-self commit transaction outputs to ensure we can cut them
off if necessary.
For HTLCs, it's an absolute expiry time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This shows where funds are going at any time (fees vs to each side).
funding.c is mainly rewritten, and should be clearer now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell