updates the bolt version to 6639cef095a2ecc7b8f0c48c6e7f2f906fbfbc58.
this requires us to use the new bolt parser at generate-bolt.py
and updates to all of the type specifications (ie. from u8 -> byte)
This allows you to prepare a tx, then release or discard it later.
Shares almost all the code with json_withdraw (which is now technically
superfluous).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: #2659
Value randomization is not implemented since `pay` was made into a plugin.
Nobody has been asking for it, so do not implement it and just remove
from documentation.
Shadow routes is implemented, and not describe, so describe it now.
This was deeply surprising to me; there's a difference between a value not being
specified, and it being specified as "".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* remove libbase58, use base58 from libwally
This removes libbase58 and uses libwally instead.
It allocates and then frees some memory, we may want to
add a function in wally that doesn't or override
wally_operations to use tal.
Signed-off-by: Lawrence Nahum lawrence@greenaddress.it
If we have plugins configured in the default config location, then
`check-manpages` may fail due to plugin cli options being added to the
`--help` output.
This also allows plugins to do "hold invoices" a-la LND, useful for
just-in-time inventory handling.
We're careful to handle the invoice getting paid behind our backs, and
the incoming HTLC going away.
Once @cdecker's sphinx rework is in, we can also hand the raw payload
to the invoice_payment_hook, for special effects.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For online services, shorter may be fine, but for casual use I'm usually
in a different timezone than the payer, so needs to be at least 1 day.
Certainly 1 hr is short if they have to open a channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Plugins don't do it right anyway, and we're about to remove it from
lightningd. Produces same format as json_pp.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In theory we could allow a db_write-using plugin to have other
hooks/commands by embargoing their other responses until the exclusive
period is over. That would be nice for a 'dbmirrorinfo' command, for
example.
The other option would be to *always* go exclusive on a db_write-using
plugin, so responses can never get intermingled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Case 5 in the Tor documentation currently states that if you use `--bind-addr=autotor:127.0.0.1:9051`, you can get your onion address by running `lightning-cli getinfo`. I have not found that to be the case; with that flag no onion address will be generated.
On the other hand, if `--addr=autotor:127.0.0.1:9051` is used instead, an onion address is generated and `lightning-cli getinfo` behaves as the docs say.
We document how to bind to them, just not how to connect to them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1diff --git a/doc/lightning-connect.7 b/doc/lightning-connect.7
index f143563ca..53619c44f 100644
This is a separate commit, as it describes the results (as sha256sum)
of doing a test on the previous commit. Obviously these values will
have to updated after a rebase!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And fix trivial typo in MAKING-RELEASES.md, and date retreival in
build-release.sh and repro-build.sh (real git tags start with v!)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
New name is less confusing, and most people should be transitioning to
listpays rather than this anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is to future-proof against multi-part-payments: the low-level commands
will start returning multiple results once we have that, so prepare
transition plan now.
Closes: #2372
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the same deprecation, but one level up. For the moment, we
still support invoices with a `h` field (where description will be
necessary) but that will be removed once this option is removed.
Note that I just changed pylightning without backwards compatibility,
since the field was unlikely to be used, but we could do something
more complex here?
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This field was used by `pay` to hold the bolt11 description if the bolt11
string used `h` to hash the description (which nobody ever did). If the
`h` field wasn't present, it could contain anything, as it wasn't checked.
It's really useful to have a label for payments (eg. '1 Cuban'), but adding
yet-another option would be painful, so we simply rename 'description'
to 'label' except inside the db.
This means we need to do some tricky parameter parsing to handle array
and keyword JSON arguments, but only until we remove the old name.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
darosior
lisa neigut
Juraj Bednar
Rusty Russell
trueptolemy
Christian Decker
Rene Pickhardt
Kristaps Kaupe
ZmnSCPxj
GreenAddress
Michael Schmoock
andrewtoth
Jeff Vandrew Jr