This is a (WIP) demo implementation of Revault, a multiparty vault architecture relying on pre-signed and revocable (revaultable) transactions.
This repo is a basic and insecure PoC.
Revault is a vault architecture designed for securing the storage and usage of consequent amount of bitcoins held my multiple parties (such as managers of an investment fund).
It aims at discouraging a theft in the first place as much as preventing it by going further a simple N-of-N multisig between the stakeholders where they either have full control over the multisig (and there is a strong incentive to try to theft them as there is a high chance to get full control over the coins), or they share this power to a trusted third party, on which they rely for a non-trivial amount of money.
It does not protect about intentional locking of funds (key erasure, for example, or refusal to sign), and thus targets users who are able to resolve this kind of problems outside the Bitcoin network (such as court, say).
Finally, it keeps some flexibility as it allows some of the stakeholders to emit day-to-day transactions without requiring the whole N holders to verify and sign.
The trick is to use N-of-N vaults for receiving funds, and to pre-sign at reception a so-called "emergency transaction" which sends funds to a "deep vault", i.e. a timelocked N-of-N with N different keys [1]. At fund reception are also signed 3 other transactions:
- The unvaulting transaction, which spends a vault output and spends to a relatively-timelocked M-of-N output OR to a N-of-N composed of the keys used for the initial vault.
- The cancel transaction, which spends an unvaulting transaction and sends back the coins to a "normal" vault.
- The emergency transaction, which spends the unvaulting transaction to the emergency deep vault. Of course, transactions are signed backward (à la payment channels).
A stakeholder can revoke a spend to an (unknown / untrusted address) during the CSV delay.
More details are available in the architecture document.
[1] These N keys are preferably held by each stakeholder in some place which are both hard to access and geographically distant.
This PoC (/ demo / whatever insecure) is an implementation of such an architecture for 4 stakeholders (to simulate the needs of the first client, see below).
Currently WIP it serves both to demonstrate the operation of a re-vault in practice with a big emphasis on being explicit and clear instead of secure (hence Python), and to hopefully convince some people that it's worth financing the development of Revault (but we need a nice GUI before this :/).
I tried to document as much as possible, begining with the transactions. Everything is in the doc/ directory, which I'll try to fill with more informations.
Of course, both the architecture and the demo are still in active development, and may (read will) be perfected in the near future !
My focus is currently the feerate problem.
The architecture was first designed by Kevin Loaec from Chainsmiths and has been worked (eventually somewhat implemented), and improved by both of us (I'm @darosior, or Antoine Poinsot from Leonod).
This architecture was at first comissioned by NOIA, a trading fund with bitcoin holdings. They were the first to sponsor this work, so big shoutout to them !
Credit is also due to Alekos Filini (Github, Twitter) and another person who prefered we not mention their name, for their feedback on early version of the architecture draft.
Finally, we are actively looking for either investors or potential users interested in sponsoring the development of an usable and secure implementation of Revault, instead of this toy ! If you might be interested, or just want to know more about Revault, feel free to drop me a mail at darosior@protonmail.com / drop a mail to Kevin at kevin@chainsmiths.com