The wire protocol uses this, in the assumption that we'll never see feerates
in excess of 4294967 satoshi per kiloweight.
So let's use that consistently internally as well.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Used by the JSON-RPC for the listtransfers call. Currently does not
support any form of paging.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We save location where transaction was started, in case we try to nest.
There's now no error case; db_exec_mayfail() is the only one.
This means the tests need to override fatal() if they want to intercept
these errors.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're going to be always in a transaction soon.
Note the rollback we used to do was an optimization: the utxo destructors
would already clean up the new UTXOs in the database.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
we should never be doing two startups at once, but why take chances? Plus,
we can then assert that all db calls are in transactions.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the only case where we actually rely on the db to ensure we don't
do something twice: don't error out if it fails.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Otherwise we find ourselves outside a commitment. This is a bandaid
until we remove nested commitments again at the end of this series.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Nesting is provided by only actually performing the outermost
transaction and simulating the nested ones. This still allows us to
ensure on lower levels that we are in the context of a transaction
without having to resort to keeping explicitly track of it in the
calling code.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
In addition we also set some of the test values to a pattern instead
of just `memset`ting it to 0, which may hide some crossed lines.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We use these quite often and it is cumbersome having to do these
simple conversions inline, so just expose pseudo-sqlite3 methods to
bind and extract from/to a stmt.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Technically it's the caller that'll own the statement, but it is nice
to have db_exec_prepared dispose of it.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
"near \"AND\": syntax error"
This was caught by the "always keep errors for db_commit_transaction".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We'd like to not keep them in memory and retrieve them on-demand when
`onchaind` is launched. This uses the `channel_htlcs` table as backing
but only fetches the minimal necessary information.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This makes executing a query/command a two step process, but allows us
to use the native binding and avoid having to build queries as SQL
strings. Two major advantages are that we are no longer vulnerable to
SQL injections and that we do not have to hex-encode binary fields
like private keys, hashes, and routing onions, halving the storage
requirements for those.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This was causing me some trouble by making it look like the last query
failed, when it really was an old one. No need to drag failures around
for longer than needed.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is a necessary evil since at the time we load `struct htlc_out`
associated with a channel we might not have loaded the `struct
htlc_in` that it depends on, so we defer the rewiring until we have
loaded all HTLCs for all channels. At that point rewiring MUST work,
otherwise we report a failure.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
While loading HTLCs from the database we might not yet have all the
incoming HTLCs loaded when loading a dependent htlc_out. So we defer
the wiring of the HTLCs until we are sure we have them loaded.
This is also the first step towards keeping that association only in
the database, since otherwise we cannot selectively load channels from
DB.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Also added a small warning to one of the used enums not to reorder or
insert values. They'd break the update path.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Addresses #207 by adding a method to retrieve available funds from the
wallet.
Reported-by: @jl777
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This was causing some compilation trouble on 32bit systems, see #256.
Reported-by: @shsmith
Signed-off-by: Christian Decker <decker.christian@gmail.com>
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>
To avoid everything pulling in HTLCs stuff to the opening daemon, we
split the channel and commit_tx routines into initial_channel and
initial_commit_tx (no HTLC support) and move full HTLC supporting versions
into channeld.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The peer->seed needs to be unique for each channel, since bitcoin
pubkeys and the shachain are generated from it. However we also need
to guarantee that the same seed is generated for a given channel every
time, e.g., upon a restart. The DB channel ID is guaranteed to be
unique, and will not change throughout the lifetime of a channel, so
we simply mix it in, instead of a separate increasing counter.
We also needed to make sure to store in the DB before deriving the
seed, in order to get an ID assigned by the DB.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is the big one, and it's completely anticlimactic: it loads all
channels that have reached opening and are not marked as
closingd_complete into memory, that's it.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
They happen to advance at the same pace but mixing them may have
unforeseen consequences, and I have done so a few times already so
this explicitly separates them.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This was supposed to be a temporary solution anyway, and I had a
rather annoying mixup between peer_id and unique_id, the latter of
which is actually a connection identifier.
If we kill the daemon without performing any commits we ended up with
a 0 instead of UINT48_MAX which was expected.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
And store in peer->last_tx/peer->last_sig like all other places,
that way we broadcast it if we need to.
Note: the removal of tmpctx in funder_channel() is needed because we
use txs[0], which was allocated off tmpctx.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Definitely not as nice as it could be, but it works for now. This is
primarily intended as a simple dump method that just saves everything
to the database. We will later use smaller incremental updates to
update specific things. wallet_channel_save serves both to insert as
well as update.
Automatically exiting the DB transaction upon any failure is strange
since it'll kill any later attempt to commit. The commit itself should
be used to verify that everything was ok.
This needed a rather annoying hack since sqlite3 can only store
integers up to 2^63, so I just squash it down/invert it, and hope that
we never ever have more than 2^63 updates.
Now we're always sync, just use an fd. Put the hsm_sync_read() helper
here, too, and do HSM init sync which makes things much simpler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Splitting the detection for outputs that we own into a separate
`wallet_extract_owned_outputs` function and use it when the broadcast
succeeds to re-add the change output back to the database.
Wallet should really be the container for anything bip32 related, so
I'd like to slowly wean off of `ld->bip32_base` in favor of
`ld->wallet->bip32_base`
We'll re-use them a few times so having them at a central location is
nice. We also fix a bug that was unreserving UTXO entries upon free,
instead of promoting them to being spent.
Since we have a simple way to query the database for UTXOs we can
simplify some of the coin selection logic. That gets rid of the
in-memory list of UTXOs.
Not the nicest code, but it allows us to store the bip32_max_index so
that we don't forget our addresses upon restart. We could have done
the same by retrieving the max index from our index, but then we'd
forget addresses that don't have an associated output. Conversion
to/from string is so that we can store arbitrary one off values in the
DB in the future, independent of type.
