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>
Both sides elect a commitment fee, and the lowest is chosen. That means
you can't game the other side (but if you offer too low, then can error
out of course).
Fees are split 50-50 if possible: originally the whole fee has to be
paid by the (single) funder. Neither side can withdraw funds which
would make them unable to pay fees.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Most complex change was gather_updates(), which handles all the "what
is the current state of the channel" logic for our dumb test utils.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell