path: root/a1/65db0dc055f09efd7e56a1d80d7b34cd79889b

Return-Path: <darosior@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 61C05C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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"
 <bitcoin-dev@lists.linuxfoundation.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <g6iy_hC7_s-9cCJLAf0hB7lhuRGBosezs_g3NDu2U3rWbFInRDOVuZYx9go9kSSWzo6n6fnA0pVSwCR8FAlLjDXn5Tx3-bhFxh7XwUt3GYU=@protonmail.com>
In-Reply-To: <Dc8XgZU3_W8pUwgCBfL4uo9wLWlZOWBG9Q8iBUTcq9V4DRzItDzlEB5nNq8a6U64k2wVD4gPWrsYmnv3I2DEB7pXydGToN32UHUnrL5faa0=@protonmail.com>
References: <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, 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 <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, 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 <darosior@protonmail.com> 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