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>
This is a major change; instead of creating a mutual anchor (funding)
transaction, each side creates its own. We use escape transactions in
case anything goes wrong; these will be revoked later.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As documented in the paper; it's also two bytes shorter, and allows
us to use the exact same script for three cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Which emerged clearly when setting one side's locktime differently than
the other.
Each side specifies the (minimum) time they need to notice a fraud attempt:
this constrains the *other* side.
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>