This triple join should be efficient to read, and to process. We have a
one-to-many (tx-to-annotations), followed by a
one-to-one (annotation-to-channel) join, so we are limited to annotations x
transactions results.
We have split the iteration over the txs and the output in different
functions, so pushing the annotation down, while keeping the transaction
addition atop. This showcases the need to not have the txid reference the
transactions.id in the DB: we annotate in a function that doesn't have the tx
index context, but only add the TX after we have finished extracting.
* Add compatibility with the new shortchannelid syntax with x as separator
* Add an error message in case the parse failed, instead of receveing an unrelated error from the bitcoin-cli
WIRE_REQUIRED_CHANNEL_FEATURE_MISSING anticipates a glorious Wumbo future,
and is closer to correct (it's a PERM failure).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
On master I get a crash and the following from valgrind, which
seems like a libwally bug. Upgrading made it go away.
==45076== Invalid read of size 1
==45076== at 0x1191A1: topo_add_utxos (chaintopology.c:657)
==45076== by 0x11935F: add_tip (chaintopology.c:681)
==45076== by 0x1197E6: have_new_block (chaintopology.c:761)
==45076== by 0x114BB0: process_rawblock (bitcoind.c:480)
==45076== by 0x1140A0: bcli_finished (bitcoind.c:227)
==45076== by 0x1A4CA2: destroy_conn (poll.c:244)
==45076== by 0x1A4CC2: destroy_conn_close_fd (poll.c:250)
==45076== by 0x1B28CD: notify (tal.c:235)
==45076== by 0x1B2DBC: del_tree (tal.c:397)
==45076== by 0x1B3148: tal_free (tal.c:481)
==45076== by 0x1A34C1: io_close (io.c:450)
==45076== by 0x1A53DD: io_loop (poll.c:449)
==45076== Address 0x59fc658 is 4 bytes after a block of size 4 alloc'd
==45076== at 0x483874F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==45076== by 0x1BD3A5: tx_from_bytes (in /home/rusty/lightning-ltest/lightningd/lightningd)
==45076== by 0x1715C3: pull_bitcoin_tx (tx.c:411)
==45076== by 0x16B25A: bitcoin_block_from_hex (block.c:54)
==45076== by 0x114B45: process_rawblock (bitcoind.c:473)
==45076== by 0x1140A0: bcli_finished (bitcoind.c:227)
==45076== by 0x1A4CA2: destroy_conn (poll.c:244)
==45076== by 0x1A4CC2: destroy_conn_close_fd (poll.c:250)
==45076== by 0x1B28CD: notify (tal.c:235)
==45076== by 0x1B2DBC: del_tree (tal.c:397)
==45076== by 0x1B3148: tal_free (tal.c:481)
==45076== by 0x1A34C1: io_close (io.c:450)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Make --announce-addr with autotor: also
a meaningful use case.
The option --announce-addr=autotor: is more
intuitive than to use the --addr=autotor: option
Signed-off-by: Saibato <saibato.naga@pm.me>
Declare opt_add_addr at top of option.c
We we use opt_add_addr and opt_announce_addr vice versa.
To make compiler happy, we declare it at top.
Signed-off-by: Saibato <saibato.naga@pm.me>
Currently the only source for amount_asset is the value getter on a tx output,
and we don't hand it too far around (mainly ignoring it if it isn't the
chain's main currency). Eventually we could bubble them up to the wallet, use
them to select outputs or actually support assets in the channels.
Since we don't hand them around too widely I thought it was ok for them to be
pass-by-value rather than having to allocate them and pass them around by
reference. They're just 41 bytes currently so the overhead should be ok.
Signed-off-by: Christian Decker <@cdecker>
We now have a pointer to chainparams, that fails valgrind if we do anything
chain-specific before setting it.
Suggested-by: Rusty Russell <@rustyrussell>
We used to match specifically on `is_elements && coinbase`, but we can just
hand off responsibility to libwally and then make sure we handle it correctly.
The fundchannel plugin needs to know how to build a transaction, so we need to
tell it which chainparams to use. Also adds `chainparams` as a global, since
that seems to be the way to do things in plugins.
Turns out that if we have the init message contain both the chainparams as
well as a transaction that needs to be parsed we need to set the parser to
elements mode before we reach the transaction...
This is the main reason we started weaving the chainparams everywhere: being
able to compare the asset type with the fee paying asset tag, thus determining
the value of the asset correctly (we still treat any non-fee-paying assets as
having value 0).
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is required since liquid-regtest and liquidv1 have different asset tags
for L-BTC which is the fee-paying asset.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
In elements we add an explicit fee output, if we don't consider it when
selecting coins, we end up underpaying the fees.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Since elements addresses look quite different from the bitcoin mainnet
addresses I just added a sample to the chainparams fixture. In addition I
extracted some of the fixed strings to reference chainparams instead.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We were checking against hardcoded hrp and prefixes. Now we parametrize via
the chainparams.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Especially when we grind fees we may end up setting the fees several times, so
instead of always adding a new fee output look for an existing one and set its
value.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Elements requires us to have an explicit fee output instead of bitcoin's
implied fee. We add the fee output mostly after sorting the other outputs
since that matches the behavior in elements itself.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We are checking against chain-dependent constants, so let's make sure we are
using the ones for the correct chain.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Christian Decker
darosior
Yash Bhutwala
Rusty Russell
Luca Ambrosini
Saibato