wally offers up `wally_clone_psbt` but it's a bit clunky (requires
checking return value, starting/stopping the wally_allocation context)
Helper method wraps this all up nice + neat!
We should actually be including this (as it may define _GNU_SOURCE
etc) before any system headers. But where we include <assert.h> we
often didn't, because check-includes would complain that the headers
included it too.
Weaken that check, and include config.h in C files before assert.h.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our new "decode" command will also handle bolt11. We make a few cleanups:
1. Avoid type_to_string() in JSON, instead use format functions directly.
2. Don't need to escape description now that JSON core does that for us.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In a couple of places we accept arrays of strings and don't validate
them. If we forward them, e.g., call a JSON-RPC method from the
plugin, we end up embedding the unverified string in the JSON-RPC
call without escaping, which then leads to invalid JSON being passed
on.
This at least partially causes #4238
We assert() this in onchaind while grinding fees; better to free newtx.
Before this we hit 530MB, after a mere 2.5MB.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: onchaind uses much less memory on unilateral closes for old channels.
Avoids much cut & paste. Some tests don't need any of it, but most
want at least some of this infrastructure.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If a tx is larger than 2k, libwally will do an alloc:
```
lightning_hsmd: common/setup.c:11: wally_tal: Assertion `wally_tal_ctx' failed.
0x11c283 wally_tal
common/setup.c:11
0x15ebd1 wally_malloc
../../../libwally-core/src/internal.c:233
0x171e9e tx_to_bip143_bytes
../../../libwally-core/src/transaction.c:1918
0x172cda tx_to_bytes
../../../libwally-core/src/transaction.c:2086
0x1759df tx_get_signature_hash
../../../libwally-core/src/transaction.c:2776
0x175afd wally_tx_get_signature_hash
../../../libwally-core/src/transaction.c:2800
0x175b62 wally_tx_get_btc_signature_hash
../../../libwally-core/src/transaction.c:2810
0x1297d9 bitcoin_tx_hash_for_sig
bitcoin/signature.c:139
0x1298ca sign_tx_input
bitcoin/signature.c:161
0x10e701 handle_sign_remote_commitment_tx
hsmd/hsmd.c:1011
0x110f7f handle_client
hsmd/hsmd.c:1968
0x147a71 next_plan
ccan/ccan/io/io.c:59
0x1485ee do_plan
ccan/ccan/io/io.c:407
0x14862c io_ready
ccan/ccan/io/io.c:417
0x14a7f2 io_loop
ccan/ccan/io/poll.c:445
0x111125 main
hsmd/hsmd.c:2040
```
I reduced that constant in libwally to 200, and ran the entire
test suite, and found no other places.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Note that check-whitespace and check-bolt already do this, so we
can eliminate redundant lines in common/Makefile and bitcoin/Makefile.
We also include the plugin headers in ALL_C_HEADERS so they get
checked.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We force use of tal_wally_start/tal_wally_end around every wally
allocation, and with "end" make the caller choose where to reparent
everything.
This is particularly powerful where we allocate a tx or a psbt: we
want that tx or psbt to be the parent of the other allocations, so
this way we can reparent the tx or psbt, then reparent everything
else onto it.
Implementing psbt_finalize (which uses a behavior flag antipattern)
was tricky, so I ended up splitting that into 'psbt_finalize' and
'psbt_final_tx', which I think also makes the callers clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we've already got a scriptSig field filled out for a PSBT input, we
use that instead of 'deriving' the scriptSig from the redeemscript
(finalizing a PSBT removes the redeemscript field)
This covers the obvious ones, but the later patches fix this more
seriously.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Some memory leaks in transaction and PSBT manipulate closed.
Elements requires the witness utxo to include the asset and value info,
in order for the signing hash to be constructed correctly
Changelog-Fixed: elementsd: PSBTs include correct witness_utxo struct for elements transactions
Changelog-Added: We now have `multifundchannel` as a builtin plugin command to fund multiple channels to different peers all in a single onchain transaction.
Header from folded patch 'fixup-use-json_add_psbt.patch':
fixup!
Header from folded patch 'use-goto-no-ok-chain.patch':
fixup!
Header from folded patch 'destinations-at-parse-time.patch':
fixup!
Header from folded patch 'multifundchannel__use_jsmntoks_to_pass_through_json_string,_not_strings.patch':
multifundchannel: use jsmntoks to pass through json string, not strings
Passing in "" for utxos would crash lightningd on the command-line
otherwise. Now returns an error.
Header from folded patch 'update_plugins-multifundchannel.c.patch':
Update plugins/multifundchannel.c
Co-authored-by: Darosior <darosior@protonmail.com>
In the case of `donateutxo`, this is needed since a simple spend of a P2WPKH to an `OP_RETURN` would be below the minimum transaction size.
Sizes below 20 are not plausible as commitments.
We're not going to mutate transactions in a block, so computing the txids
every time we need them is a waste, let's compute them upfront and use them
afterwards.
We create ALL_PROGRAMS, ALL_TEST_PROGRAMS, ALL_C_SOURCES and
ALL_C_HEADERS. Then the toplevel Makefile knows which are
autogenerated (by wildcard), so it can have all the rules to clean
them or check the source as necessary.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Most of what it does was actually a function of adding the input metadata
to the PSBT, so call that and simply copy out the tx input it creates.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Until it gains miniscript support, wally doesn't know how to
finalize P2WSH. This happens with `option_anchor_outputs` for
to-remote, which requires a 1 block delay to force use of
anchor outputs for CPFP.
So we finalize this ourselves.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This also means we subtract 660 satoshis more everywhere we subtract
the base fee (except for mutual close, where the base fee is still
used).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Includes:
psbt: Use renamed functions for new wally version
psbt: Set the transaction directly to avoid script workarounds
psbt: Use low-S grinding when computing signatures
tx: Use wally_tx_clone from libwally now that its exported
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>
Technically, they could do this themselves, but it's much nicer to have one
place to do it (and it makes sure we get the required information into the
PSBT, which is actually not entirely accessible through listfunds, as that
doesn't want to consult with the HSM for close outputs).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON RPC: new low-level coin selection `fundpsbt` routine.
PSETs have a bit different requirements. The witness_utxo needs
the asset tag + values, and these should also be added to the PSET
struct separately as well. To do this, we create a new 'init' method for
elements inputs, which takes care of the elements specific things.
We don't preserve detailed asset information at the moment, so provide a
way to convert from a sat to an amount_asset struct.
We also need a way to convert from an 'amount_asset' to a 'value' for
elements, which for explicit (i.e. non-blinded) asssets is a 0x01 prefix
plus the big-endian encoded value.
These are pulled from wallet/wallet.c, with the fix now that we grind sigs.
This reduces the fees we pay slightly, as you can see in the coinmoves changes.
I now print out all the coin moves in suitable format before we match:
you only see this if the test fails, but it's really helpful.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
most likely unused since the switch to libwally for internal blockchain
things.
these method names were clashing with ones that are to be introduced
with some libwally cleanups, so getting rid of them pre-emptively keeps
us libwally compatible
Our existing coin_moves tracking logic assumed that any tx we had an
input in belonged to *all* of our wallet (not a bad assumption as long
as there was no way to update a tx that spends our wallets)
Now that we've got `signpsbt` implemented, however, we need to be
careful about how we account for withdrawals. For now we do a best guess
at what the feerate is, and lump all of our spent outputs as a
'withdrawal' when it's impossible to disambiguate
the bitcoin_tx version is basically a wrapper for the wally_tx script
extraction -- here we pull it apart so we can easily get a tal'd script
for a wally_tx_output
The main change here is that the previously-optional open/accept
fields and reestablish fields are now compulsory (everyone was
including them anyway). In fact, the open/accept is a TLV
because it was actually the same format.
For more details, see lightning-rfc/f068dd0d8dfa5ae75feedd99f269e23be4777381
Changelog-Removed: protocol: support for optioned form of reestablish messages now compulsory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
will either use a temporary psbt (and not munge the passed in psbt)
or will finalize in place -- finalization erases most of the signature
metadata from the psbt struct
We're not using the change_outnum for withdraw tx's (and the way
we were calculating it was broken as of the addition of 'multiple
outputs'). This removes the change output knowhow from withdraw_tx
entirely, and pushes the responsibility up to the caller to
include the change output in the output set if desired.
Consequently, we also remove the change output knowhow from hsmd.