3ffdc54ca5
Define 'is satisfied by' - this is a classic off-by-one problem, if a relative lock is satisfied does that mean it can go in this block or the next? Its most useful if it means 'it can go in the next' and this is how relative height and MTP are used in Core. Ramifications: - When checking a time based lock we check against the chain tip MTP, then when Core verifies a block with the output in it it uses the previous block (and this is still the chain tip). - When checking a height base lock we check against chain tip height + 1 because Core checks against height of the block being verified. Additionally we currently have a false negative in the satisfaction functions when the `crate` type (height or MTP) is to big to fit in a u16 - in this case we should return true not false because a value too big definitely is > the lock value. One final API paper cut - currently if the caller puts the args in the wrong order they get a false negative instead of an error. Fix all this by making the satisfaction functions return errors, update the docs to explicitly define 'satisfaction'. For now remove the examples in rustdocs, we can circle back to these once the dust settles. API test of Errors: Some of the errors are being 'API tested' tested in `primitives` but they should be being done in `units/tests/api.rs` - put all the new errors in the correct places. |
||
|---|---|---|
| .. | ||
| address | ||
| blockdata | ||
| consensus | ||
| crypto | ||
| merkle_tree | ||
| network | ||
| p2p | ||
| psbt | ||
| taproot | ||
| bip32.rs | ||
| bip152.rs | ||
| bip158.rs | ||
| consensus_validation.rs | ||
| hash_types.rs | ||
| internal_macros.rs | ||
| lib.rs | ||
| policy.rs | ||
| pow.rs | ||
| serde_utils.rs | ||
| sign_message.rs | ||