Date: Fri, 24 Apr 2020 15:00:16 +0000
To: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <Dc8XgZU3_W8pUwgCBfL4uo9wLWlZOWBG9Q8iBUTcq9V4DRzItDzlEB5nNq8a6U64k2wVD4gPWrsYmnv3I2DEB7pXydGToN32UHUnrL5faa0=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Revault: a multi-party vault architecture
Precedence: list

Hi all,

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


Intended usage and limitations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

The aim is to secure the shared storage of coins without relying on a trust=
ed third party and by disincentivizing theft attempts, while not restrictin=
g 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 a=
ssumes 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 attem=
pt 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 =E2=80=9Cvault=E2=80=9D transaction which pays to a N-of-N, by which =
funds are received.
- The =E2=80=9Cemergency=E2=80=9D transaction, which spends the vault outpu=
t and pays to a [here goes a
high value]-days timelocked N-of-N (with N differents but statics keys, ass=
umed to be physically stored in hard(/long) to access locations).
- The =E2=80=9Cunvault=E2=80=9D transaction, which spends the vault output =
and pays to [either the vault=E2=80=99s N-of-N, or *after X blocks* to a su=
bset of the stakeholders AND a co-signing server].
- The =E2=80=9Cunvault emergency=E2=80=9D transaction, which spends the unv=
ault output and pays to the
same script as the first emergency transaction.
- The =E2=80=9Ccancel=E2=80=9D transaction, which spends the unvault output=
 and pays back to a new vault utxo.
- The =E2=80=9Cspend=E2=80=9D transaction, which spends the unvault output =
and pays to an external address (potentially contained in a list of destina=
tions previously agreed-upon by all the stakeholders).


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

The stakeholders would exchange the signatures of all the revaulting transa=
ctions after the reception of a new vault utxo, and then exchange the signa=
tures of the unvaulting transaction. Before doing so, the coins are not ava=
ilable to be spent.

In order to spend a vault, the subset of the stakeholders who manages the f=
unds (for example, the traders of an investment fund) would make the cosign=
ing 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" transacti=
on. 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 knowin=
g about its child =E2=80=9Cspend=E2=80=9D transaction, it triggers an autom=
atic =E2=80=9Ccancel=E2=80=9D transaction (not encumbered by the timelock).

At any point -even in the middle of a spend- any of the stakeholder can tri=
gger an emergency transaction if anything nasty is happening.
Any network watcher noticing the broadcast of an emergency transaction woul=
d also broadcast all other vaults=E2=80=99 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 | ANYONECA=
NPAY signatures for the revaulting transactions and append their own as SIG=
HASH_ALL before broadcasting.
They can add another input (and potentially output) in order to bump the fe=
es before doing so.

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

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


Worth mentioning
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The original draft of this architecture was first designed by Kevin Loaec w=
ho was hired by NOIA to do so. It was inspired by Bryan Bishop=E2=80=99s si=
ngle-party vault architecture (https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2019-August/017229.html), who published a demo implementation o=
f it last week (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
0-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 =E2=80=9Cinsecure=E2=80=
=9D meaning] implementation is available at https://github.com/re-vault/rev=
ault-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 t=
he emergency scripts.
The transactions used are detailed in the doc/ directory of the same repo, =
and are coded in the revault/transactions/ module.

The =E2=80=9Crevault=E2=80=9D name was coined by Lea Thiebaut (Lexyon).


Thanks for reading,
Antoine / Darosior