Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8019DD11 for ; Fri, 26 Feb 2016 16:05:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2C7A1A1 for ; Fri, 26 Feb 2016 16:05:40 +0000 (UTC) Received: by mail-wm0-f45.google.com with SMTP id g62so78385781wme.0 for ; Fri, 26 Feb 2016 08:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=EIcocvHLhnSjvdbm093NKi1z03Xyq4KSgsv6M7IvTNE=; b=K+3feFFtt8rYvkxZapF+KnUhOVod2IGtecUnOef8YvUXQODwTunJ3C0iB2k7far2oN UyoCAtsKOYYszJu7hlvtG9DvskBDgsK/OYqMMtmdJIhMazzd4iBlGa84yvf0Co5SKOrv ITG2ZPNo4f8DPBfKQHh+ZC8Lr36MdlF2SHGV74kiolDVwgxST3EcTDtX+evBDEfYBvRf 0miltBgLnxufgMyCWo6QXyRM1p1SY/ETGrIowrW3SDaW7N+C5V5O8PF/Sjc3/9XkkT3x NM7OU7Hat8RMyx4ED+VGza8bjqAh6DfcB6iwBGZG+c8domuMlkzrkSoGv2CjlfN4USZu QQOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=EIcocvHLhnSjvdbm093NKi1z03Xyq4KSgsv6M7IvTNE=; b=bpBuuoeWFRnsmdjcx+sqIm0y0UGAttJO5cu0eAXRTTfMU6TgEIFwODKY5kqTX+aoYF fVKBWYK0yAWSMC8Lfo37lUK6/HsBQPWUPsgps4rfIV+SRTshXAchEdIJHla73SNYmh8m vgPbUWxvnEQ4RMjksJQJ4vNu2YmSgc9w3Kx2stvWYVO6NN0uBs6RlEXiqHGG66CcHdok y4YdjbG09fIuRHGDm0DVrfq8LohwNT5Z1eriFzb84qkmZrKurgdvhCtGRBklnF+f/RwU JsPYLVXwOguw/5ISU/Na1dSfDJDzF3pP0HCeEP0yItTT4Rte9mpQKsFVSWFnDMWTGMta 4eYA== X-Gm-Message-State: AD7BkJIKITL5VuN2IcqjGonpxcQXR/llf6RclV04G1bk1PLTcigRUMXtos5TyaqUEjooOqAYyyxjKgSMOFJxhw== X-Received: by 10.28.182.136 with SMTP id g130mr4042509wmf.10.1456502739613; Fri, 26 Feb 2016 08:05:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.236.66 with HTTP; Fri, 26 Feb 2016 08:05:20 -0800 (PST) From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= Date: Fri, 26 Feb 2016 11:05:20 -0500 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a114b14e068c8a7052cae780e X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 26 Feb 2016 16:06:17 +0000 Cc: =?UTF-8?B?TWFsdGUgTcO2c2Vy?= , Ittay Eyal Subject: [bitcoin-dev] Bitcoin Vaults. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 16:05:42 -0000 --001a114b14e068c8a7052cae780e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable At the 3rd Bitcoin Workshop being held in conjunction with the Financial Cryptography Conference in Barbados, my group will be presenting a new idea for improving Bitcoin wallet security and deterring thefts today. The write-up is here: http://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-va= ults/ The paper with the nitty gritty details is here: http://fc16.ifca.ai/bitcoin/papers/MES16.pdf The core idea: Our paper describes a way to create vaults, special accounts whose keys can be neutralized if they fall into the hands of attackers. Vaults are Bitcoin=E2=80=99s decentralized version of you calling your bank to report = a stolen credit card -- it renders the attacker=E2=80=99s transactions null and void= . And here=E2=80=99s the interesting part: in so doing, vaults demotivate key the= ft in the first place. An attacker who knows that he will not be able to get away with theft is less likely to attack in the first place, compared to current Bitcoin attackers who are guaranteed that their hacking efforts will be handsomely rewarded. Operationally, the idea is simple. You send your money to a vault address that you yourself create. Every vault address has a vault key and a recovery key. When spending money from the vault address with the corresponding vault key, you must wait for a predefined amount of time (called the unvaulting period) that you established at the time you created the vault -- say, 24 hours. When all goes well, your vault funds are unlocked after the unvaulting period and you can move them to a standard address and subsequently spend them in the usual way. Now, in case Harry the Hacker gets a hold of your vault key, you have 24 hours to revert any transaction issued by Harry, using the recovery key. His theft, essentially, gets undone, and the funds are diverted unilaterally to their rightful owner. It=E2=80=99s like an =E2=80=9Cundo=E2=80=9D facility that t= he modern banking world relies on, but for Bitcoin. The technical trick relies on a single new opcode, CheckOutputVerify, that checks the shape of a redeem transaction. Note that fungibility is not affected, as the restrictions are at the discretion of the coin owner alone and can only be placed by the coin owner ahead of time. We suspect that this modest change could actually be a game-changer for bitcoin security: clients and keys are notoriously hard to secure, and a facility that allows you to possibly recover, and if not, permanently keep the hacker from acquiring your funds, could greatly deter Bitcoin thefts. As always, comments and suggestions are welcome. - egs, Ittay Eyal and Malte Moeser. --001a114b14e068c8a7052cae780e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the 3rd Bitcoin Workshop being held in conjunction with= the Financial Cryptography Conference in Barbados, my group will be presen= ting a new idea for improving Bitcoin wallet security and deterring thefts = today.=C2=A0

The write-up is here:

The paper wit= h the nitty gritty details is here:

The core idea:

Our paper describes a way to create vaults, special accounts = whose keys can be neutralized if they fall into the hands of attackers. Vau= lts are Bitcoin=E2=80=99s decentralized version of you calling your bank to= report a stolen credit card -- it renders the attacker=E2=80=99s transacti= ons null and void. And here=E2=80=99s the interesting part: in so doing, va= ults demotivate key theft in the first place. An attacker who knows that he= will not be able to get away with theft is less likely to attack in the fi= rst place, compared to current Bitcoin attackers who are guaranteed that th= eir hacking efforts will be handsomely rewarded.

O= perationally, the idea is simple. You send your money to a vault address th= at you yourself create. Every vault address has a vault key and a recovery = key. When spending money from the vault address with the corresponding vaul= t key, you must wait for a predefined amount of time (called the unvaulting= period) that you established at the time you created the vault -- say, 24 = hours. When all goes well, your vault funds are unlocked after the unvaulti= ng period and you can move them to a standard address and subsequently spen= d them in the usual way. Now, in case Harry the Hacker gets a hold of your = vault key, you have 24 hours to revert any transaction issued by Harry, usi= ng the recovery key. His theft, essentially, gets undone, and the funds are= diverted unilaterally to their rightful owner. It=E2=80=99s like an =E2=80= =9Cundo=E2=80=9D facility that the modern banking world relies on, but for = Bitcoin.

The technical trick relies on= a single new opcode, CheckOutputVerify, that checks the shape of a redeem = transaction. Note that fungibility is not affected, as the restrictions are= at the discretion of the coin owner alone and can only be placed by the co= in owner ahead of time.=C2=A0

We suspect that this= modest change could actually be a game-changer for bitcoin security: clien= ts and keys are notoriously hard to secure, and a facility that allows you = to possibly recover, and if not, permanently keep the hacker from acquiring= your funds, could greatly deter Bitcoin thefts.=C2=A0

=
As always, comments and suggestions are welcome.
- egs, Itta= y Eyal and Malte Moeser.

--001a114b14e068c8a7052cae780e--