From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A3866C0175 for ; 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 ; 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 ; 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 ; 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" From: darosior Reply-To: darosior Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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