If we fail to unmarshal the tx (shouldn't happen, but...) we must
not dereference NULL.
Also tighten the check: towire_ must send 0 or all inputs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We did this originally because these types are referred to in the bolts, and we
had no way of injecting the correct include lines into those. Now we do, so
there's less excuse for this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Transactions that we 'get' from bitciond don't have the input values
available on the transaction; for these cases we'll sum up the inputs
amounts using a different data source than the transaction's
`input_amounts`. So we need to expose it here.
We roll the `elements_add_fee_output` function and the cropping of
overallocated arrays into the `bitcoin_tx_finalize` function. This is supposed
to be the final cleanup and compaction step before a tx can be sent to bitcoin
or passed off to other daemons.
This is the cleanup promised in #3491
This sets the nLockTime to the tip (and accordingly each input's nSequence to
0xfffffffe) for withdrawal transactions.
Even if the anti fee-sniping argument might not be valid until some time yet,
this makes our regular wallet transactions far less distinguishable from
bitcoind's ones since it now defaults to using native Segwit transactions
(like us). Moreover other wallets are likely to implement this (if they
haven't already).
Changelog-Added: wallet: withdrawal transactions now sets nlocktime to the current tip.
this is unnecessary, and actually severely limits the functionality
of `wally_tx_add_input`, which will expand the allocated input
length if there's not enough room for the additional input
```external/libwally-core/src/transaction.c
if (tx->num_inputs >= tx->inputs_allocation_len) {
/* Expand the inputs array */
struct wally_tx_input *p;
p = realloc_array(tx->inputs, tx->inputs_allocation_len,
tx->num_inputs + 1, sizeof(*tx->inputs));
...
tx->inputs = p;
tx->inputs_allocation_len += 1;
```
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.
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>
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>
We use to use the non-elements ones and then patch them manually. By using the
correct ones right from the start we have less work on our side.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
If we are handling an elements transaction the value is not stored in the
satoshi field, rather it is stored in the `value` field which is prefixed with
a version (0x01) and is counted in `asset` units.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Skipping coinbase transactions and ensuring that the transaction is serialized
correctly when sending it onwards.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This was a bit of trial and error due to libwally not liking hints when it
comes to length measurements, also the parsing bumps against a masking issue
in libwally that I'd following up on their issue tracker.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is the normal convention for this type; it makes using converters
a little easier. See next patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the other origin, besides `bitcoin_tx`, where we create `bitcoin_tx`
instances, so add the context as soon as possible. Sadly I can't weave the
chainparams into the deserialization code since that'd need to change all the
generated wire code as well.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The way we build transactions, serialize them, and compute fees depends on the
chain we are working on, so let's add some context to the transactions.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is what all of this has been working towards: ripping out the handwoven
transaction handling. By removing the custom parsing we can finally switch
over to using `wally_tx` as sole representation of transactions in
memory. The commit is a bit larger but it's mostly removing setters and old
references to the input and output fields.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
These are handled internally in the `wally_tx` and do not conform to our usual
tallocated strings that can by inspected using `tal_bytelen`, and we don't
really want to litter our code with whitelisting comments for the
`amount_sat.satoshis` access, so these just do read-only on the fly conversions.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The `wally_tx_input`s do not keep track of their input value, which means we
need to track them ourselves if we try to sign these transactions at a later
point in time.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
These are used when grinding the feerate and signing. These are just simple
facades that keep both wally and old style transactions in sync.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
During the migration to `libwally` we want to make absolutely sure that both
transactions are generated identical, and can eventually be switched over.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We are slowly migrating towards a wally-transactions only world, but to make
this reviewable we start building both old and new style transactions in
parallel. In a second pass we'll then start removing the old ones and use
libwally only.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We need to do it in various places, but we shouldn't do it lightly:
the primitives are there to help us get overflow handling correct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We currently make sure that all the bitcoin_tx input scripts are NULL
and set the input script of the input we're signing, so we can easily
reuse the tx hashing code for signature checks. This means that we
sometimes jump through hoops to make sure input scripts are NULL, and
also means that the tx can't be const.
Put more logic inside bitcoin/tx so it can simply ignore things we
don't want to hash.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
tal_count() is used where there's a type, even if it's char or u8, and
tal_bytelen() is going to replace tal_len() for clarity: it's only needed
where a pointer is void.
We shim tal_bytelen() for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When a serialized length refers to an array of structures, the trivial
DOS prevention can be out by a factor of sizeof(serialized struct). Use
the size of the serialized structure as a multiplier to prevent this.
Transaction inputs are the motivating example, where the check is out by
a factor of ~40.
If no witnesses are present on any inputs, then extended serialisation
should not be used.
[ Amended to make adding new flags clearer in future -- RR ]
Signed-off-by: Jon Griffiths <jon_p_griffiths@yahoo.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The deserialization of bitcoin transactions in wire/ is rather
annoying in that we first allocate a new bitcoin_tx, then copy it's
contents onto the destination and then still carry the newly allocated
one around due to the tal-tree. This splits `pull_bitcoin_tx` into
two: one part that does the allocation and another one that proceeds
to parse.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
It's just a sha256_double, but importantly when we convert it to a
string (in type_to_string, which is used in logging) we use
bitcoin_txid_to_hex() so it's reversed as people expect.
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 signing code asserts these are NULL, and if we unmarshal from the
wire then sign them, it gets upset.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From doing a code walkthrough with Christian Decker; unnecessary const in
bitcoin/tx.c, an erroneous FIXME, a missing comment, and an unused struct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
BIP141 indicates that the rule for block size has changed: witness
bytes effectively count for 1, and non-witness bytes count for 4, but
the maximum total has increased to 4,000,000.
This means that fee estimates should use the witness cost (divided by
4), not the raw txlen.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We currently linearize and then measure the string; this is better since
we're about to do it in a second place.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need this for signing segwitness txs. Unfortunately, we don't have it
for transactions we received as hex, only ones we created; to make this safe
we use a pointer which is NULL if we don't know, and those will crash if
we try to sign or check their sigs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This could only happen via our RPC interface (bitcoind should not give
us bad txs!) but it's better to be robust.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Without Alpha, it's superfluous. We're about to add segwit support,
but linearization requires a more powerful approach, and segwit
signature checking is completely different and really deserves its
own function.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I had already disabled it, and this clears the decks for Segregated Witness
which gives us everything we want.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
All the members of the transaction should be allocated off the
transaction, as they have the same lifetime.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I got confused navigating these, especially since Alpha and Bitcoin
have diverged (BIP68 was proposed after Elements Alpha).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The format for both the nSequence field and the stack arg for
OP_CHECKSEQUENCEVERIFY is either:
Time-relative: [Bit 22 = 1] 00000 <time-shifted-by-9>
Block-relative: [Bit 22 = 0] 00000 <number of blocks>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The latest version of the BIP doesn't use inversion, but does use
bitshifts.
It also uncovered a bug in the test scripts: the block timestamps
creep forward when we generate large numbers of blocks (UpdateTime
insists it be > GetMedianTimePast() so it's valid). We need to take
this into account when waiting for the median to move (reduced it from
60 to 30 seconds, since that adds about 14 seconds).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
niftynei
Rusty Russell
Christian Decker
Ken Sedgwick
darosior
Yash Bhutwala
trueptolemy
practicalswift
Jon Griffiths