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>
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>
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 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>
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>
Depending on the network we end up with different signature hash algorithms,
so we just collect that decision in one place.
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>
The header is not a contiguous section of memory in elements, and it is of
variable length, so the simple trick of hashing in-memory data won't work
anymore. Some of the datafields would have been wrong on big-endian machines
anyway, so this is better anyway.
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>
Since the difference between non-elements and elements block headers is just
the middle 2 fields, I split the old parsing code so I could add the middle
part.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Using a global variable is a bit lazy, but weaving the network type through
the entire stack is a daunting task. Maybe we can make that happen at a later
stage.
Most of the changes in `chainparams.c` are just formatting the
`genesis_blockhash` a bit nicer (`clang-format` to the rescue).
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The math is a bit tricky, so encapsulate it.
Includes the extra 'e' in 'announcable' as noted by @cdecker :)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This will never be reliable under high load, without making it unable
to detect real errors. But the test is useful because if we don't
have this test we'll never notice if we break the const-timedness of
our implementation.
So, move the calloc out of the test loop (which seems to make it more
reliable), and then after we've run it, check the 1-minute load
average. Too high, we don't complain about results. It's not
perfect, but it's better.
Running 100 times (-O3) serially gave 100 successes with the following results:
Constant: Within 5% 562-926(832.89+/-73)/1000 times
Non-constant: More than 5% slower 860-990(956.35+/-26)/1000 times
More importantly, if we swap the const and non-const tests, we get
the expected 100 failures:
Non-constant: Within 5% 14-79(41.17+/-14)/1000 times
Constant: More than 5% slower 44-231(111.89+/-33)/1000 times
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 more reliable under load now: shorten the times so it is
likely to run in a single timeslice, and add a nanosleep so it's
likely to be at the start of the timeslice.
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>
Simplifying some operations, erroring in some cases and moving to global
defines for constants.
Suggested-by: Rusty Russell <@rustyrussell>
Signed-off-by: Christian Decker <decker.christian@gmail.com>
'bip70_name' is corresponding to the 'chain' field of
the API 'getblockchaininfo'.
At the beginning of lightningd, we use the 'chain' field of 'getblockchaininfo' to check if we are on right blockchain.
Christian Decker
lisa neigut
Yash Bhutwala
Rusty Russell
trueptolemy
Karl-Johan Alm
trueptolemy