* Modifies invoice command to have the following format
invoice <msatoshi> <label> <desc> <?expiry> <?fallbackaddr>
* Adds support for Segwit bcrt1 addresses for withdraw
* Add test case for fallback address in invoice creation
* Create a common json_tok_address_scriptpubkey to be used
by invoice and withdraw commands.
We now keep a list of commands for the jcon instead of a simple
'current' pointer: the assertions become a bit more complex, but
the rest is fairly mechanical.
Fixes: #1007
Reported-by: @ZmnSCPxj
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We move it into jsonrpc where it belongs, and make it fail the command.
This means it can tell us exactly what was wrong.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This can be used for upgrades to make sure you're not using deprecated
options, JSON commands, JSON fields, etc.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's just a sha256_double, but importantly when we convert it to a
string (in type_to_string, which is used in logging) we use
bitcoin_txid_to_hex() so it's reversed as people expect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I prefer the typesafety of specific functions, rather than having the
caller know that txids are traditionally reversed in bitcoin.
And we already have a bitcoin_txid_to_hex() function for this.
Closes: #411
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
jsonrpc handlers usually directly call command_success or
command_fail; not doing that implies they're waiting for something
async.
Put an explicit call (currently a noop) there, and add debugging
checks to make sure it's used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In future it will have TOR support, so the name will be awkward.
We collect the to/fromwire functions in common/wireaddr.c, and the
parsing functions in lightningd/netaddress.c.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Some fields were redundant, some are simply moved into 'struct lightningd'.
All routines updated to hand 'struct lightningd *ld' now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also, we split the more sophisticated json_add helpers to avoid pulling in
everything into lightning-cli, and unify the routines to print struct
short_channel_id (it's ':', not '/' too).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Other than being neater (no more global list to edit!), this lets the
new daemon and old daemon have their own separate routines.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't need it for testing at the moment, and if we do it'll have
to change to relative anyway now we're going to use time_mono().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
getnodes returns an object containing a single array of 'nodes'. Each
element contains the node's ID, its hostname and its port. If
unknown (because we haven't seen a node announcement yet) then the port
is 0 and the hostname is null.
'getchannels' returns a 'channels' array containing an object for each
known channel. Each channel object represents one direction of a
bidirectional channel, with a from and a to node ID along with the fees
for that direction. This matched the internal storage of channels and
allows unbalanced fees for each direction.
Rename the structs to match (and remove dev-echo).
This makes it clear that they're not the normal API.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is less convenient to use, but makes far more sense for a real
user (like a wallet). It can ask about the route, then decide whether
to use it or not.
This will make even more sense once we add a parameter to control how
long we let the HTLC be delayed for, so a client can query for high,
medium and low tolerances and compare results.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To do this we keep an order counter so we know how to retransmit. We
could simply keep old packets, but this is a little clearer for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
ZmnSCPxj
John Barboza
Rusty Russell
practicalswift
Christian Decker