From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 61C05C07FF for ; Fri, 8 May 2020 10:35:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 4AA2687491 for ; Fri, 8 May 2020 10:35:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysc6MYnXHuhJ for ; Fri, 8 May 2020 10:35:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 32BF6871A7 for ; Fri, 8 May 2020 10:35:03 +0000 (UTC) Date: Fri, 08 May 2020 10:34:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1588934099; bh=Wl1Vll/RUu+5r2tkJxO+7nzkLHiAYaOk+f6vNNggeBs=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=CLUDneyGqGhzMg+G/izD9ini1F0jZ6lT6vRdWYpCfNX89FVnMFDMfCbcijqAUCBNz VKQR+AZHEeoU3qf2NuvEz2a5VLrjWB1Ytnr35a8IjbMgzXtL/mj2dBy/ohr6J4PVQJ LJrU8s0RjsNIW0rDYH1ri8k8pGyA6/v7FDs9HFU4= To: "bitcoin-dev@lists.linuxfoundation.org" From: darosior Reply-To: darosior Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 08 May 2020 13:35:53 +0000 Subject: Re: [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, 08 May 2020 10:35:08 -0000 The fee bumping construction I described in the previous post is potentiall= y vulnerable to transaction pinning. We shared a SINGLE | ANYONECANPAY signature for the first (and only) input = of revaulting transactions to allow any party to append an input and an output in order t= o bump the transaction fees. An user would either append an input signed with ALL, or replace their SING= LE | ANYONECANPAY signature with one using ALL before broadcasting the transaction. This allowed one party to decrease the transaction fees down to the minimum= relay fees, and possibly pin the transaction by spending their added single-pubkey outp= ut. We now exchange ALL | ANYONECANPAY signatures for revaulting transactions t= o restrict the creation of a new output only spendable by one party. The fee bumping is now done in two stages (to avoid consuming an entire utx= o) : Unvaulting transaction -------------------------------- | vault prevout | unvault output |------------------ -------------------------------- \ \ Revaul= ting transaction \ ----------------= ----------------------- | unvault prevout= | new vault output | ----------------= ----------------------- | fee bump prevou= t | / ----------------= ---- Single-party wallet transaction / ----------------------------------------- / | wallet prevout | fee bump output |---------- ----------------------------------------- | wallet change output | ------------------------ This construction isn't perfect as a malicious party could still pin its fe= e bumping transaction and prevent the other stakeholders from **immediatly** replacing this input= , because of the second rule of BIP125 : > The replacement transaction may only include an unconfirmed input if that= input was included > in one of the original transactions. However, I think it's preferable as : - Depending on the unvault CSV, the honest party might pay a high fee to ha= ve the fee-bumping transaction confirm in one of the next two blocks, and then use this now = confirmed output as an additional input of the revaulting transaction. - If the amount is consequent, the honest party may sacrifice an entire con= firmed utxo from its wallet (effectively skipping the fee bumping transaction). - It's realistic to expect, for such an application, users' wallets to have= a pool of confirmed utxo that might be sacrificed if the amount is consequent AND the CSV is = so small (which is anyway a bad idea in the first place) that you are not sure to have the f= ee bumping transaction to be confirmed before its maturity, ). Thanks, Antoine / Darosior =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Le vendredi, avril 24, 2020 5:00 PM, darosior a = =C3=A9crit : > Hi all, > > Kevin Loaec and I have been working on a new multiparty vault architectur= e 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=3D > > The aim is to secure the shared storage of coins without relying on a tru= sted third party and by disincentivizing theft attempts, while not restrict= ing the usage of the funds for day-to-day operations. > > Revault uses N-of-N multisigs and thus does not protect against intention= al locking of funds (such as refusal to sign, or key erasure). Therefore it= assumes its users (likely companies with already on-going agreements betwe= en shareholders) to be able to solve intentional blockage outside the Bitco= in 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=3D > > We called it revault as it relies on pre-signed and revocable (revaultabl= e) 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 att= empt or lock the funds for some time beforehand. The funds are always bette= r locked for a long time than stolen. > > The transactions > > ---------------- > > The system is composed of mainly 6 transaction types (with N the number o= f stakeholders) : > > - The =E2=80=9Cvault=E2=80=9D transaction which pays to a N-of-N, by wh= ich funds are received. > - The =E2=80=9Cemergency=E2=80=9D transaction, which spends the vault o= utput and pays to a [here goes a > high value]-days timelocked N-of-N (with N differents but statics key= s, assumed to be physically stored in hard(/long) to access locations). > > - The =E2=80=9Cunvault=E2=80=9D transaction, which spends the vault out= put and pays to [either the vault=E2=80=99s N-of-N, or after X blocks to a = subset of the stakeholders AND a co-signing server]. > - The =E2=80=9Cunvault emergency=E2=80=9D transaction, which spends the= unvault output and pays to the > same script as the first emergency transaction. > > - The =E2=80=9Ccancel=E2=80=9D transaction, which spends the unvault ou= tput and pays back to a new vault utxo. > - The =E2=80=9Cspend=E2=80=9D transaction, which spends the unvault out= put and pays to an external address (potentially contained in a list of des= tinations previously agreed-upon by all the stakeholders). > > The process > > > The stakeholders would exchange the signatures of all the revaulting tran= sactions after the reception of a new vault utxo, and then exchange the sig= natures of the unvaulting transaction. Before doing so, the coins are not a= vailable 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 cosi= gning server (which only signs a transaction once) sign the spend transacti= on. > They would then present it to the other watchers which would ACK the spen= d (if paying to an authorized address), and broadcast the "unvault" transac= tion. Finally, and after X blocks have passed they would be able to broadca= st the spend transaction. > If a stakeholder's watcher detects an unvaulting transaction without know= ing about its child =E2=80=9Cspend=E2=80=9D transaction, it triggers an aut= omatic =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 t= rigger an emergency transaction if anything nasty is happening. > Any network watcher noticing the broadcast of an emergency transaction wo= uld 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 th= e value of the feerate in the future, stakeholders exchange SINGLE | ANYONE= CANPAY signatures for the revaulting transactions and append their own as S= IGHASH_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) onl= y 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 feerat= e increase after the broadcast. Anyhow, a significant breathing room can be= added to the feerate as these transactions are not intended to be used und= er 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= who was hired by NOIA to do so. It was inspired by Bryan Bishop=E2=80= =99s single-party vault architecture (https://lists.linuxfoundation.org/pip= ermail/bitcoin-dev/2019-August/017229.html), who published a demo implement= ation 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 =E2=80=9Cinsecure= =E2=80=9D meaning] implementation is available at https://github.com/re-vau= lt/revault-demo, which uses 4 stakeholders, 2 or 3 traders (doing the day-t= o-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 =E2=80=9Crevault=E2=80=9D name was coined by Lea Thiebaut (Lexyon). > > Thanks for reading, > Antoine / Darosior