path: root/83/fbf6215a86263fc94bce63e87d3c01a0664295

Return-Path: <darosior@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A3866C0175
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Apr 2020 15:00:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 86FF987858
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Apr 2020 15:00:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VYYxvIZcrQzr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Apr 2020 15:00:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
 [185.70.40.132])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 37BDF8779F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 24 Apr 2020 15:00:26 +0000 (UTC)
Date: Fri, 24 Apr 2020 15:00:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1587740423;
 bh=9CXlYkAMrcWZogKhh/WIdoUCpKlw+RqYPT5GJVRpdA4=;
 h=Date:To:From:Reply-To:Subject:From;
 b=ndtW/1iaOnevaJu0iZIxiD845Ya22iVH+rf4xICDbNOlwE++zjoBu564iJyJLO/Vl
 9Wcov85bnimz7wsKWDaJCM1Gfx9/LcgHKU0x0lty6e59Z6hwg2PIL6d6cV5ED/0iMd
 hPxxzZN7n5HI32J63wwr5PtkT6EysFld3iO1lCps=
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
X-Mailman-Approved-At: Fri, 24 Apr 2020 15:48:45 +0000
Subject: [bitcoin-dev] Revault: a multi-party vault architecture
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 15:00:28 -0000

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