Since messages in TLV's are optional, the ideal way to deal with
them is to have a 'master struct' object for every defined tlv, where
the presence or lack of a field can be determined via the presence
(or lack thereof) of a struct for each of the optional message
types.
In order to do this, appropriately, we need a struct for every
TLV message. The next commit will make use of these.
Note that right now TLV message structs aren't namespaced to the
TLV they belong to, so there's the potential for collision. This
should be fixed when/where it occurs (should fail to compile).
Add tlv-messages to the general messages set so that their parsing
messages get printed out.
FIXME: figure out how to account for partial message length processing?
Version 1.1 of the lightning-rfc spec introduces TLVs for optional
data fields. This starts the process of updating our auto-gen'd
wireformat parsers to be able to understand TLV fields.
The general way to declare a new TLV field is to add a '+' to the
end of the fieldname. All field type declarations for that TLV set
should be added to a file in the same directory by the name
`gen_<field_name>_csv`.
Note that the FIXME included in this commit is difficult to fix, as
we currently pass in the csv files via stdin (so there's no easy
way to ascertain the originating directory of file)
If we asked `bitcoind` for a txout and it failed we were not storing that
information anywhere, meaning that when we see the channel announcement the
next time we'd be reaching out to `lightningd` and `bitcoind` again, just to
see it fail again. This adds an in-memory cache for these failures so we can
just ignore these the next time around.
Fixes#2503
Signed-off-by: Christian Decker <decker.christian@gmail.com>
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.
Otherwise we can't really return a variable sized message with more than 65k
results. This was causing an integer overflow in `listchannels` (see #2504 for
details).
Signed-off-by: Christian Decker <decker.christian@gmail.com>
gossipd in l1 might not have registered l2 reconnecting, thus considering
the channel local-disabled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- This will make a channel loop when 'id' argument was "all".
- The response will now contain an array of objects (peer_id, scid, ...)
- It will skip channels in invalid states.
- Moves iffy channel/peer param stuff to param_channel_or_all
We set the version BIP32_VER_TEST_PRIVATE for testnet/regtest
BIP32 privkey generation with libwally-core, and set
BIP32_VER_MAIN_PRIVATE for mainnet.
For litecoin, we also set it like bitcoin else.
1. amount operations should force you to check validity, rather than
needing a separate call, so make amount_msat_to_u32 return bool,
and WARN_UNUSED_RESULT it.
2. Create a special parsing function for this; not only does this mean
we now only need that one amount call, but also 'check' will correctly
fail with invalid amounts (it only does the parsing step).
3. If we create a primitive which we immediately take(), we allocate it
off NULL to make it clear we expect its lifetime to end here.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Intrduce DB update `channel` values: `feerate_base` and `feerate_ppm`
- Make fist use of now context realted DB migration
- Add `struct channel` members of the same name
- Use struct values instead of config when commiting new channels
This will add the testnet config copyNpaste to test_utils.c,
so that the test stups can set these.
Alternatively, to reduce code duplication, we can move the
testnet_config and mainnet_config from options.c to options.h.
==12787== Uninitialised byte(s) found during client check request
==12787== at 0x450AAC: memcheck_ (mem.h:247)
==12787== by 0x450B17: towire (towire.c:19)
==12787== by 0x45103D: towire_u8_array (towire.c:159)
==12787== by 0x443235: towire_wireaddr_internal (wireaddr.c:79)
==12787== by 0x46E6F2: towire_connectctl_init (gen_connect_wire.c:229)
==12787== by 0x40D6C8: connectd_init (connect_control.c:369)
==12787== by 0x4186D3: main (lightningd.c:701)
==12787== Address 0x682d8a9 is 361 bytes inside a block of size 568 alloc'd
==12787== at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12787== by 0x4867A5: tal_resize_ (tal.c:694)
==12787== by 0x41F3EE: opt_add_addr_withtype (options.c:143)
==12787== by 0x41F4D7: opt_add_bind_addr (options.c:155)
==12787== by 0x47E364: parse_one (parse.c:121)
==12787== by 0x47F9C8: opt_parse (opt.c:210)
==12787== by 0x4212F9: handle_opts (options.c:892)
==12787== by 0x41864C: main (lightningd.c:667)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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
lightning_connectd(19780): STATUS_FAIL_INTERNAL_ERROR: Failed to bind on 2 socket: Address family not supported by protocol
"Untested code is buggy code"
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* Improved plugin install in docker
- All files generated by 'make install' are copied
- Fixes issues with incomplete installation.
- Example: New executables created by build but are missing in docker.
With the preceeding UTF-8 fix, I'd like to detect UTF-8 support. But
AFAICT Python doesn't have a standard way of doing version exposure.
So I added __version__, but now we need to make sure it matches. I
used the hackiest possible method.
[ Christian Decker fixed version to be sane, so previous comment no longer
applies! --RR ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. We need to read in as a byte string, then decode into utf8 once we
have a marker. Otherwise we seem to mangle it horribly, and we
might have a bad utf8 string anyway.
2. We need to suppress the JSON \u escapes on output.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We should be able to pass UTF-8 strings to and from plugins without
python turning them into JSON-\u escapes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
