From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 21AE6C0172 for ; Mon, 13 Apr 2020 15:51:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id F3B9F203A0 for ; Mon, 13 Apr 2020 15:51:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG5+fPsiKbKS for ; Mon, 13 Apr 2020 15:51:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by silver.osuosl.org (Postfix) with ESMTPS id BEB8D20006 for ; Mon, 13 Apr 2020 15:51:56 +0000 (UTC) Received: by mail-vs1-f53.google.com with SMTP id j65so5660610vsd.12 for ; Mon, 13 Apr 2020 08:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=V00y60E9FTDtGwCXTyA3qmt8wGmuoQaCeglZOp29zY0=; b=fe7Me+Ar48IGQGdDCzraLGu46x33YcIwkpC+THZ0eNwv4j3FxjBxrOEWT+Ke/yCvgf bV879tgQEmrOgcQvrTgTfImLQZVpr9iRc8usIL2gtVTdUelhK6WZGu5wHoNlCslHGugw e6hyNgMW5KXIpGCJSCcYsjDN7LM0iU02Mv/ICbILIuhd57gtOzThMqQ2aadkDNUCYSyO KAd86Obo4PY3IiA4tAx+z3iMxAUm/AcCUWSDn6XbR6tJGZHAmmFX4Y4kbBHPGUSBDdC/ mL89k3gY/IQ0ACxowRbo6x78K6Td36SXTxfA7KeAl1ecM+Nxsjdjk2FeOpinZItUg6a3 28Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=V00y60E9FTDtGwCXTyA3qmt8wGmuoQaCeglZOp29zY0=; b=BgOncVh8rLVF8PsNHmzT8MqH2uZp4RSTQxsnZDDiEmgU+s7MYPGwL5ZpCTr//B0dtS NRlzfUP4y7nySTIfdSeUZcfHy5oJU7ITU8ar6c40//KGJ9DEZ/QK4yy7JkgWEmyYVAqI YU9pSt5M9qIwKDYwD6R57y4eaLRsWqFA8mY0yiifNVj6Y0hd34D6ApA4jqqifPsphaVC 3SoH9asVRYLzdkBvEl7wJXl+MzfpjNAFTVnRixku+vz6dHkdavMEQDKmmP8gKsMyaOUo O1MTMx3LQrzL9445brQXxdbkF2IyB+Ty5L8dmhXw1X4B52db4f3Gq9HzDVA9fG0ejj5E 9WrQ== X-Gm-Message-State: AGi0PubZB5z7v3i4AnOSQumTRNhbWi0O+Rz+tVYsbg5/DCwfyNPNEs+e PqIBwTzjYBpe2i0gEGcSAuqLvK8gGrTl/CPFqbC1KBMp X-Google-Smtp-Source: APiQypIWiVrYtIXGPEppAxhNJzQ1PN9Xe6JNSyBlP7vbCy0cN97xzb4EevFutt4jYBvvQC8ERXXnKTW65C55p8FEolY= X-Received: by 2002:a67:2dc5:: with SMTP id t188mr12215279vst.3.1586793115151; Mon, 13 Apr 2020 08:51:55 -0700 (PDT) MIME-Version: 1.0 From: Bryan Bishop Date: Mon, 13 Apr 2020 10:50:00 -0500 Message-ID: To: Bitcoin Dev , Bryan Bishop Content-Type: multipart/alternative; boundary="000000000000f5f1cc05a32e0f49" Subject: [bitcoin-dev] On-chain vaults prototype 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: Mon, 13 Apr 2020 15:51:58 -0000 --000000000000f5f1cc05a32e0f49 Content-Type: text/plain; charset="UTF-8" Hi, High-security protection against theft depends on multisig and timelocks, but more tools are possible. Last year I discussed one method where would-be attackers are discouraged by specially designed vault covenants [1] allowing re-vaulting transactions, where a watchtower can override a proposed delayed-spend transaction during a public observation delay period. Splitting coins into multiple timelocked UTXOs can give a user time to react to theft of a much smaller portion of the total amount. If better and better cold storage designs can be shared openly, reviewed, and used easily, this can increase security for all bitcoin users. When the understanding among the general public includes "bitcoin is extremely valuable" then it becomes more urgent that the understanding in the general public also includes "bitcoin cold storage security is impenetrable". Today I would like to announce the release of an open-source prototype for on-chain bitcoin vaults using pre-signed transactions and secure key deletion. I am hoping for feedback and discussion around these concepts. To be very clear, this is a prototype and not fit for production use. https://github.com/kanzure/python-vaults During the delay period, this design allows initiation of a recovery or clawback which triggers funds being moved to deeper cold storage. Reviewers: Generally interested in your feedback about the concept. My hope is that the prototype and its source code helps answer some questions about how this might work. I would suggest to also pay close attention to the script templates for both outputs and witnesses. Also included is an implementation of this same bitcoin vault using bip119 OP_CHECKTEMPLATEVERIFY. I have also been working with Spencer Hommel, Jacob Swambo, and Bob McElrath on two related manuscripts, one addressing the topic of bitcoin covenants and the other addressing the topic of vaults based on pre-signed transactions. As part of that project, there is a separate vault implementation that is already available on Fidelity's github account [2]. A more bare bones implementation of python vaults can be found at [3]. Also, Kevin Loaec has an unrelated implementation using pre-signed transactions. Thank you, - Bryan [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html [2] https://github.com/fmr-llc/Vault-mbed [3] https://github.com/JSwambo/bitcoin-vault --000000000000f5f1cc05a32e0f49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

High-security protection against theft depends = on multisig and timelocks, but more tools are possible. Last year I discuss= ed one method where would-be attackers are discouraged by specially designe= d vault covenants [1] allowing re-vaulting transactions, where a watchtower= can override a proposed delayed-spend transaction during a public observat= ion delay period. Splitting coins into multiple timelocked UTXOs can give a= user time to react to theft of a much smaller portion of the total amount.=

If better and better cold storage designs can be shared openly, rev= iewed, and used easily, this can increase security for all bitcoin users. W= hen the understanding among the general public includes "bitcoin is ex= tremely valuable" then it becomes more urgent that the understanding i= n the general public also includes "bitcoin cold storage security is i= mpenetrable".

Today I would like to announce the release of an = open-source prototype for on-chain bitcoin vaults using pre-signed transact= ions and secure key deletion. I am hoping for feedback and discussion aroun= d these concepts. To be very clear, this is a prototype and not fit for pro= duction use.

https://github.com/kanzure/python-vaults

During = the delay period, this design allows initiation of a recovery or clawback w= hich triggers funds being moved to deeper cold storage.

Reviewers: G= enerally interested in your feedback about the concept. My hope is that the= prototype and its source code helps answer some questions about how this m= ight work. I would suggest to also pay close attention to the script templa= tes for both outputs and witnesses.

Also included is an implementati= on of this same bitcoin vault using bip119 OP_CHECKTEMPLATEVERIFY.

I= have also been working with Spencer Hommel, Jacob Swambo, and Bob McElrath= on two related manuscripts, one addressing the topic of bitcoin covenants = and the other addressing the topic of vaults based on pre-signed transactio= ns. As part of that project, there is a separate vault implementation that = is already available on Fidelity's github account [2]. A more bare bone= s implementation of python vaults can be found at [3]. Also, Kevin Loaec ha= s an unrelated implementation using pre-signed transactions.

Thank y= ou,

- Bryan

[1] https://li= sts.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html[2] h= ttps://github.com/fmr-llc/Vault-mbed
[3] https://github.com/JSwambo/bitc= oin-vault
--000000000000f5f1cc05a32e0f49--