This is the command an actual user would use: it figures out the fee
and route, and pays it if it can.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're about to change the code so that if it can't route, it will fail
the HTLC. The current low-level tests will hate this, so have a dev switch
to turn that off.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A new 'accept-payment' command tells the node to fulfill HTLCs using
the R value if the amount is correct. It's not wired in yet.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need to control the *inputs* to the anchor tx, to make sure they
pay to witness scripts (thus the anchor is immalleable). The easiest
way to do this is to hand out P2SH addresses for the user, and have
them pay into those. Then they hand us that tx and we use it to
create the anchor.
This is not a long-term solution!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We now keep a list of commitment transaction states for "us" and
"them", as well as a "struct channel_state" for staged changes.
We manipulate these structures as we send out packets, receive
packets, or receive acknowledgement of packets. In particular, we
update the other nodes' staging_cstate as we send out our requests,
and update our own staging_cstate are we receive acks. When we
receive a request, we update both (as we immediately send out our
ack).
The RPC output is changed; rather than expose the complexity, we
expose our last committed state: what would happen if we have to drop
to the blockchain now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
