serai/coins/bitcoin
Luke Parker 7ac0de3a8d
Correct binding properties of Bitcoin eventuality
Eventualities need to be binding not just to a plan, yet to the execution of
the plan (the outputs). Bitcoin's Eventuality definition short-cutted this
under a honest multisig assumption, causing the following issue:

If multisig n+1 is verifying multisig n's actions, as detailed in
multi-multisig's document on multisig rotation, it'll check no outstanding
eventualities exist. If we solely bind to the plan, a malicious multisig n
could steal outbound payments yet cause the plan to be marked as successfully
completed.

By modifying the eventuality to also include the expected outputs, this is no
longer possible. Binding to the expected input is preserved in order to remain
binding to the plan (allowing two plans with the same output-set to co-exist).
2023-09-08 05:21:18 -04:00
..
src Correct binding properties of Bitcoin eventuality 2023-09-08 05:21:18 -04:00
tests Support no-std builds of bitcoin-serai 2023-08-21 08:56:37 -04:00
Cargo.toml Support no-std builds of bitcoin-serai 2023-08-21 08:56:37 -04:00
LICENSE Re-license bitcoin-serai to MIT 2023-01-31 09:45:25 -05:00
README.md Bump crate versions 2023-03-20 20:34:41 -04:00

bitcoin-serai

An application of modular-frost to Bitcoin transactions, enabling extremely-efficient multisigs.