calling `wally_psbt_finalize` doesn't return a status indicator; instead
you must call `psbt_is_finalized` to check that it's eligible for
'extraction' -- extraction will fail if the psbt is not in a finalized
state.
when re-populating a channel's data from the database, since we don't
store the psbt data (with input scripts + amounts), we need to
re-populate it.
the right solution is to patch the psbt into the database; for now we
'monkey-patch' it in.
Update the `bitcoin_tx_add_input` interface to accept a witness script
and or scriptPubkey.
We save the amount + witness script + witness program (if known) to
the PSBT object for a transaction when creating an input.
the PPA is no longer maintained, the new hotness is the snapd install.
except that snapd does some weirdness with the binary names, calling it
bitcoin-core.daemon and bitcoin-core.cli. To get around this, you can
create a symbolic link to the snap binaries, which is what we outline
here.
According to #3226, it looks like clang's LD error format has changed.
This patch adds the new format so we can parse the mocks successfully.
Apple clang version 11.0.3 (clang-1103.0.32.29)
```
checking for ANSI C header files... Undefined symbols for architecture x86_64:
"_fromwire_amount_msat", referenced from:
_fromwire_tlv_test_n1_tlv3 in ccj4zKdV.o
"_fromwire_bool", referenced from:
_fromwire_test_msg in ccj4zKdV.o
_fromwire_test_msg_option_short_id in ccj4zKdV.o
_fromwire_test_msg_option_one in ccj4zKdV.o
_fromwire_test_msg_option_two in ccj4zKdV.o
"_fromwire_test_enum", referenced from:
_fromwire_test_msg in ccj4zKdV.o
_fromwire_test_msg_option_short_id in ccj4zKdV.o
_fromwire_test_msg_option_one in ccj4zKdV.o
_fromwire_test_msg_option_two in ccj4zKdV.o
"_fromwire_tlvs", referenced from:
_fromwire_test_tlv1 in ccj4zKdV.o
_fromwire_test_tlv2 in ccj4zKdV.o
_fromwire_test_tlv3 in ccj4zKdV.o
"_fromwire_tu32", referenced from:
_fromwire_tlv_test_n2_tlv2 in ccj4zKdV.o
"_fromwire_tu64", referenced from:
_fromwire_tlv_test_n1_tlv1 in ccj4zKdV.o
_fromwire_tlv_test_n2_tlv1 in ccj4zKdV.o
"_fromwire_u16", referenced from:
_fromwire_test_features in ccj4zKdV.o
_fromwire_subtype_var_assign in ccj4zKdV.o
_fromwire_subtype_arrays in ccj4zKdV.o
_fromwire_tlv_test_n1_tlv4 in ccj4zKdV.o
_fromwire_tlv_test_n3_tlv3 in ccj4zKdV.o
_fromwire_test_msg in ccj4zKdV.o
_fromwire_test_tlv1 in ccj4zKdV.o
...
"_fromwire_u32", referenced from:
_fromwire_tlv_test_n3_tlv3 in ccj4zKdV.o
_fromwire_test_msg in ccj4zKdV.o
_fromwire_test_msg_option_short_id in ccj4zKdV.o
_fromwire_test_msg_option_one in ccj4zKdV.o
_fromwire_test_msg_option_two in ccj4zKdV.o
"_fromwire_u64", referenced from:
_fromwire_test_short_id in ccj4zKdV.o
_fromwire_tlv_test_n3_tlv3 in ccj4zKdV.o
"_fromwire_u8", referenced from:
_fromwire_subtype_var_assign in ccj4zKdV.o
_fromwire_subtype_var_len in ccj4zKdV.o
_fromwire_subtype_varlen_varsize in ccj4zKdV.o
_fromwire_tlv_test_n3_tlv3 in ccj4zKdV.o
"_fromwire_u8_array", referenced from:
_fromwire_test_features in ccj4zKdV.o
_fromwire_subtype_arrays in ccj4zKdV.o
_fromwire_tlv_test_n3_tlv3 in ccj4zKdV.o
_fromwire_test_msg in ccj4zKdV.o
_fromwire_test_msg_option_short_id in ccj4zKdV.o
_fromwire_test_msg_option_one in ccj4zKdV.o
_fromwire_test_msg_option_two in ccj4zKdV.o
...
```
Changelog-Fixed: Build for macOS Catalina / Apple clang v11.0.3 fixed
Spec is wrong (it says it should be compulsory), and Eclair doesn't set it
at all, leading to an error when they send their announcement_signatures.
Fixes: #3703
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-changed: large-channels: negotiate successfully with Eclair nodes.
There are various places where our tests failed with
--enable-expimental-features. And our plugin test overlapped an
existing feature.
We make our expected_feature functions more generic, and use them
everywhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For the moment it's a complete tx, but in future designs we might only
be given the specific input which closes the channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Otherwise this creates noise for the next patch which switches the initial
`struct bitcoin_tx` into a `struct tx_parts`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
`struct tx_parts` is just a txid and a bunch of inputs and outputs,
some of which may be NULL.
This is both a nod towards a future where we (or our peer) can combine
HTLCs or (in an eltoo world) commitments, although for the moment all
our tx_parts will be complete.
It also matches our plan to split `bitcoin_tx` into two types: this
`struct tx_parts` where we don't know input amounts etc, and `psbt`
where we do.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These are useful for tx_parts:
1. wally_txid.
2. linearize_wtx.
3. wally_tx_input_spends
4. wally_tx_output_get_amount
5. wally_tx_input_get_txid
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
now that witness script data is saved into the tx/psbt which is
serialized across the wire, there's no reason to use witscript to do
this. good bye witscript!
Move all psbt creation into single method, new_psbt
note that if a psbt is init'd for a transaction that's
deserialized with scripts etc already attached, then set_global_tx
will fail. instead, we empty all of this out first.
if the tx is being re-init'd from a tx source that had a psbt attached
(e.g. fromwire_) then the script/witness data will get populated
appropriatel from there.
niftynei
Rusty Russell
fiatjaf
Glen Cooper
Antoine Poinsot