summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEmin Gün Sirer <el33th4x0r@gmail.com>2016-02-26 11:05:20 -0500
committerbitcoindev <bitcoindev@gnusha.org>2016-02-26 16:05:42 +0000
commit4c877a7b0a416b1b666952ea75746f0908d6c2ef (patch)
tree1616f8cdfd2c32a40f8e53488c5bebc3b924951c
parente445e7bc85d89d761892ebf875070ff43d10a84c (diff)
downloadpi-bitcoindev-4c877a7b0a416b1b666952ea75746f0908d6c2ef.tar.gz
pi-bitcoindev-4c877a7b0a416b1b666952ea75746f0908d6c2ef.zip
[bitcoin-dev] Bitcoin Vaults.
Diffstat
-rw-r--r--87/b5b891d1b7157ff191f3843c393859db7bfab9173
1 files changed, 173 insertions, 0 deletions
diff --git a/87/b5b891d1b7157ff191f3843c393859db7bfab9 b/87/b5b891d1b7157ff191f3843c393859db7bfab9
new file mode 100644
index 000000000..576a997ea
--- /dev/null
+++ b/87/b5b891d1b7157ff191f3843c393859db7bfab9
@@ -0,0 +1,173 @@
+Return-Path: <el33th4x0r@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 8019DD11
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ 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 <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 26 Feb 2016 16:05:40 +0000 (UTC)
+Received: by mail-wm0-f45.google.com with SMTP id g62so78385781wme.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ 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?= <el33th4x0r@gmail.com>
+Date: Fri, 26 Feb 2016 11:05:20 -0500
+Message-ID: <CAPkFh0vuLsoNQUEdH-kGqXYvFJt1tXLvt0eMEuFZGm7Pus-_2g@mail.gmail.com>
+To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
+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?= <malte.moeser@uni-muenster.de>,
+ Ittay Eyal <ittay.eyal@cornell.edu>
+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 <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, 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
+
+<div dir=3D"ltr">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<div><br></div><div>The write-up is here:</div><div>=C2=A0 =C2=
+=A0=C2=A0<a href=3D"http://hackingdistributed.com/2016/02/26/how-to-impleme=
+nt-secure-bitcoin-vaults/">http://hackingdistributed.com/2016/02/26/how-to-=
+implement-secure-bitcoin-vaults/</a></div><div><br></div><div>The paper wit=
+h the nitty gritty details is here:</div><div>=C2=A0 =C2=A0=C2=A0<a href=3D=
+"http://fc16.ifca.ai/bitcoin/papers/MES16.pdf">http://fc16.ifca.ai/bitcoin/=
+papers/MES16.pdf</a></div><div><br></div><div>The core idea:<br><div><br></=
+div><div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div><div>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</div><div><br></div><div>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</div><div><br></div>=
+<div>As always, comments and suggestions are welcome.</div><div>- egs, Itta=
+y Eyal and Malte Moeser.</div><div><br></div></div>
+
+--001a114b14e068c8a7052cae780e--
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-26 05:58:09 +0000