Hi all,

Kevin Loaec and I have been working on a new multiparty vault architecture and 
I think it reached the point where we’d welcome some feedback.


Intended usage and limitations
==============================

The aim is to secure the shared storage of coins without relying on a trusted 
third party and by disincentivizing theft attempts, while not restricting the 
usage of the funds for day-to-day operations.

Revault uses N-of-N multisigs and thus does not protect against intentional 
locking of funds (such as refusal to sign, or key erasure). Therefore it 
assumes its users (likely companies with already on-going agreements between 
shareholders) to be able to solve intentional blockage outside the Bitcoin 
network (such as through legal contracts).


The actual architecture
=======================

We called it revault as it relies on pre-signed and revocable (revaultable) 
transactions.
The users pre-sign a transaction chain as the only used way to spend from a 
vault output.
They would have signed a set of transactions to either cancel a spend attempt 
or lock the funds for some time beforehand. The funds are always better locked 
for a long time than stolen.


The transactions
----------------

The system is composed of mainly 6 transaction types (with N the number of 
stakeholders) :

- The “vault” transaction which pays to a N-of-N, by which funds are received.
- The “emergency” transaction, which spends the vault output and pays to a 
[here goes a
high value]-days timelocked N-of-N (with N differents but statics keys, assumed 
to be physically stored in hard(/long) to access locations).
- The “unvault” transaction, which spends the vault output and pays to [either 
the vault’s N-of-N, or *after X blocks* to a subset of the stakeholders AND a 
co-signing server].
- The “unvault emergency” transaction, which spends the unvault output and pays 
to the
same script as the first emergency transaction.
- The “cancel” transaction, which spends the unvault output and pays back to a 
new vault utxo.
- The “spend” transaction, which spends the unvault output and pays to an 
external address (potentially contained in a list of destinations previously 
agreed-upon by all the stakeholders).


The process
-----------

The stakeholders would exchange the signatures of all the revaulting 
transactions after the reception of a new vault utxo, and then exchange the 
signatures of the unvaulting transaction. Before doing so, the coins are not 
available to be spent.

In order to spend a vault, the subset of the stakeholders who manages the funds 
(for example, the traders of an investment fund) would make the cosigning 
server (which only signs a transaction once) sign the spend transaction.
They would then present it to the other watchers which would ACK the spend (if 
paying to an authorized address), and broadcast the "unvault" transaction. 
Finally, and after X blocks have passed they would be able to broadcast the 
spend transaction.
If a stakeholder's watcher detects an unvaulting transaction without knowing 
about its child “spend” transaction, it triggers an automatic “cancel” 
transaction (not encumbered by the timelock).

At any point -even in the middle of a spend- any of the stakeholder can trigger 
an emergency transaction if anything nasty is happening.
Any network watcher noticing the broadcast of an emergency transaction would 
also broadcast all other vaults’ emergency transactions.

This network watching and revaulting power can be replicated (watchtowers) to 
further decrease the reliance on a single machine or internet access.


Pre-signed transactions fun
---------------------------

In order to avoid our security assumptions to be as weak as betting on the 
value of the feerate in the future, stakeholders exchange SINGLE | ANYONECANPAY 
signatures for the revaulting transactions and append their own as SIGHASH_ALL 
before broadcasting.
They can add another input (and potentially output) in order to bump the fees 
before doing so.

We protect ourselves from the bug by leveraging the fact the revaulting (namely 
the "emergency", "unvault emergency", and "cancel" transactions) only have 
*strictly* one input and one output. The change being part of the spend 
transaction.

In addition, revaulting transactions may signal for RBF to cover a feerate 
increase after the broadcast. Anyhow, a significant breathing room can be added 
to the feerate as these transactions are not intended to be used under normal 
circumstances.


Worth mentioning
================

The original draft of this architecture was first designed by Kevin Loaec who 
was hired by NOIA to do so. It was inspired by Bryan Bishop’s single-party 
vault architecture 
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html),
 who published a demo implementation of it last week 
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html,
 https://github.com/kanzure/python-vaults).
Kevin and I since detailed and reworked our new architecture together.

A WIP draft / demo / PoC / [enter adjective with “insecure” meaning] 
implementation is available at https://github.com/re-vault/revault-demo, which 
uses 4 stakeholders, 2 or 3 traders (doing the day-to-day moves) a CSV of 6 
blocks for the unvault script and a CSV of ~1 month for the emergency scripts.
The transactions used are detailed in the doc/ directory of the same repo, and 
are coded in the revault/transactions/ module.

The “revault” name was coined by Lea Thiebaut (Lexyon).


Thanks for reading,
Antoine / Darosior
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to