Needed for applications where the tweak and the secret key material are on different
devices (and the one with the secret material does not want to know how to compute
the tweak itself).
This code was unmaintained, is unlikely to work on the majority of systems
(since it holds the whole utxoset in RAM, and not in a terribly efficient
manner), and has a dependency on `eventual` which has been broken for a
long time.
The library no longer compiles on nightly because of this, and without any
known usecases for `UtxoSet`, nor good ability to test it, I'm simply
removing the code.
I recommend anyone who cares about this extracts the code from the previous
commit and creates a new crate. It should be more featureful anyway, e.g.
support a backing store.
This is just a convenience type for the (txid, vout) pairs that get produced
a lot in Bitcoin code. To the best of my knowledge there is nowhere this can
be used in the actual library (in particular, TxOutRef.index is a usize for
convenience while TxIn.prev_index is a u32 for correct consensus encoding,
so there is not redundancy here).
A fixed buffer of 12 bytes was unsafely copied from the bytes of a
string - if the string was shorter than that, memory from outside would
leak into the packet.
Replace the unsafe copy by a safe loop. Also add a panic if
an attempt is made to use a command string longer than 12 bytes.
Rather than having methods taking &mut self, have them consume self
and return another Builder, so that methods can be chained.
Bump major version number.
This is easy to satisfy given that the template-to-script code takes a
slice of keys. Just do &keys[..n_keys] if you have too many keys. (If
you have too few you're SOL no matter what.) This way we can catch
likely configuration errors without putting much of a burden on users
who legitimately have more keys than the template requires.
Also add a method required_keys() to Template so that users can check
how many keys they ought to have.
This is easy for downstream to add, not easy for them to remove. Plus scripts
have a pretty recognizable form and are usually obvious from context anyway.
Andrew Poelstra
Nicholas Alan Cardin
Julius Naperkowski
Julius Naperkowski
Wladimir J. van der Laan