diff options
| author | Jérôme Legoupil <jjlegoupil@gmail.com> | 2016-04-24 12:05:52 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-04-24 10:06:02 +0000 |
| commit | ab08e26514ff5a6a4d08440745125c1d72d65157 (patch) | |
| tree | 05775f94f2c8a1891cb96c16061eb46dae5cd1eb | |
| parent | f24c626bb770ffbda6e94880d39a99eb9ac848ad (diff) | |
| download | pi-bitcoindev-ab08e26514ff5a6a4d08440745125c1d72d65157.tar.gz pi-bitcoindev-ab08e26514ff5a6a4d08440745125c1d72d65157.zip | |
[bitcoin-dev] Private "Merkle" Vaults for the Bitcoin system
| -rw-r--r-- | af/50792bd75ead4e206b25cc2b05e962cb70427f | 916 |
1 files changed, 916 insertions, 0 deletions
diff --git a/af/50792bd75ead4e206b25cc2b05e962cb70427f b/af/50792bd75ead4e206b25cc2b05e962cb70427f new file mode 100644 index 000000000..a42a0f128 --- /dev/null +++ b/af/50792bd75ead4e206b25cc2b05e962cb70427f @@ -0,0 +1,916 @@ +Return-Path: <jjlegoupil@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 1ADFC74 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 24 Apr 2016 10:06:02 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 942F9D2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 24 Apr 2016 10:05:56 +0000 (UTC) +Received: by mail-wm0-f66.google.com with SMTP id e201so14787687wme.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 24 Apr 2016 03:05:56 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=from:message-id:mime-version:subject:date:references:to:in-reply-to; + bh=xiN6b33csxhu7Gu6Bff6d+R48Z8JGYbBuGSajglgo2g=; + b=miBujndaoFbAi2oNnZsqUdY4w7qdtc+6iaHuscFqDjX/G3Ag4xRVgJ4r28yVqW9KN+ + Gb+9Su8QLOvP74ByQlic42M8wy64X4uLkaLc0BCWN2PAeLCgcavbTiz3PdiPKozavzOD + D4G7spnuR5an4U5U+5I/GRwVgq0udshvFwReNMNrEWs5/PqCvRr3mhtmbmKLJydSMKP4 + iy1DmwwIOerY4fZF/Bjab+qkjn/8nEj8JvJXEHMKYTULfBxwBQvD6vFaM1U/PmxVBLk3 + 3KXpmBZqGK0WZK4/DZOXmiGcx9pz8m+NgSZsrKPGLGnghVgW6sb4MnKI8bsluSY1sicb + 6jGA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:from:message-id:mime-version:subject:date + :references:to:in-reply-to; + bh=xiN6b33csxhu7Gu6Bff6d+R48Z8JGYbBuGSajglgo2g=; + b=h6ow1jN3+koJiupCwobH9FkLzT5XrxpOiEH23EprisdrzO1MfAOe6Oa/1lqyWjvF45 + 7aIAv/zmwWqWGm0qCZNz4S4T5gLcFQHOQV95x3+vPuUVUB9tF6IkTUknjtq+DXAj+huA + gEAO0tl9i8TyepIZhfQAXh/RCHzvuCosx/D4dbGQtNSOttokiwlYwzaUpDBvr+SyglQ0 + E+6/Zlvi3yxzTnrlF1KyOkXK2mpGzCTUuo61CHHC8oyxQ6YX76je6px9cmFpshff91Qu + qHPbNqqjIb3zeoWaNrjX1swrZsNKIxukDmqdlJvnqYwZl0BwwcvRizbnDP7AqdSostVN + Kd7w== +X-Gm-Message-State: AOPr4FX1mjFD8Rus/D+jpKGlC1FyJPmSZj38zqdOre8DUhdRehWCQMKaB1Edkk+/0JdjiQ== +X-Received: by 10.28.226.213 with SMTP id z204mr5883932wmg.99.1461492354849; + Sun, 24 Apr 2016 03:05:54 -0700 (PDT) +Received: from [192.168.1.3] (46-127-102-197.dynamic.hispeed.ch. + [46.127.102.197]) by smtp.gmail.com with ESMTPSA id + by7sm17638817wjc.18.2016.04.24.03.05.53 + for <bitcoin-dev@lists.linuxfoundation.org> + (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); + Sun, 24 Apr 2016 03:05:53 -0700 (PDT) +From: =?utf-8?Q?J=C3=A9r=C3=B4me_Legoupil?= <jjlegoupil@gmail.com> +Content-Type: multipart/alternative; + boundary="Apple-Mail=_B1F27580-A11F-4313-AC39-091FAC96BB0B" +Message-Id: <86B5737C-2B2A-45F3-998C-4CD6818AEE83@gmail.com> +Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) +Date: Sun, 24 Apr 2016 12:05:52 +0200 +References: <mailman.4068.1456528991.1673.bitcoin-dev@lists.linuxfoundation.org> +To: bitcoin-dev@lists.linuxfoundation.org +In-Reply-To: <mailman.4068.1456528991.1673.bitcoin-dev@lists.linuxfoundation.org> +X-Mailer: Apple Mail (2.3124) +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + MIME_QP_LONG_LINE, + 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: Sun, 24 Apr 2016 11:43:32 +0000 +Subject: [bitcoin-dev] Private "Merkle" Vaults for the Bitcoin system +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: Sun, 24 Apr 2016 10:06:02 -0000 + + +--Apple-Mail=_B1F27580-A11F-4313-AC39-091FAC96BB0B +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=utf-8 + +In Febuary, an email intitled "Bitcoin Vaults" was addressed to this = +mailing list linking to a paper on =E2=80=9Ccovenants=E2=80=9D (see mail = +below) describing a way to apply recursive restrictions temporarily or = +permanently on bitcoins (for digital asset use-cases) and Bitcoin Vaults = +were offered as an application (thanks to the authors for sharing their = +work with the community, I personally found this paper insightful and = +inspiring). Unfortunately, this proposal isn=E2=80=99t fungibility = +friendly and could lead Bitcoin to undesirable outcomes. + +What follows is an attempt to design Vaults that preserve Bitcoin=E2=80=99= +s fungibility and keep their defensive attributes private from = +blockchain observers and from potential insider participants: the = +Vault=E2=80=99s defence is incrementally revealed when executed. If I am = +a war chief defending a castle, I=E2=80=99m certainly not going to show = +my defence strategy to the world and if it leaked to the enemy, it would = +greatly weaken my chances to succeed: greater privacy leads to greater = +security. +=20 +Vaults enable important use-cases for Bitcoin as a store of value, in = +particular the tricky but critical use-case of successions (heritages). + + +=E2=80=94 General idea =E2=80=94=20 + +This design restricts the bitcoins in a Vault to a private, predefined, = +finite (no patterns) and unforgeable set of authorized actions defined = +by the Vault creator at the setup. + +Definition: an authorized action (or action) is an authorized address = +the bitcoins inside a Vault can be sent to, with an authorized timelock. +Action =3D <pubKeyHash> < timelock> + +The Vault can be defined as a set of parent/child authorized actions. = +This enables the Vault creator to construct a Merkle tree of his Vault. = +During the setup, the creator computes the hashs of every authorized = +action, and builds his Merkle tree from the bottom, up to the top Merkle = +root. The Vault creator must give the appropriate Merkle proofs = +(authorizations) to the Vault participants (if any) according to the = +authorizations he grants them, and when someone wants to move funds = +inside or out of the Vault, he needs to provide to the network (in = +addition of a valid signature) the Merkle proof that demonstrates that = +his action is authorized by the Vault. The network can verify that: =20= + +Hash [ Merkle_proof(Action) + Hash(Action) ] =3D=3D = +Merkle_proof(Parent_Action) + +The Merkle tree must be destroyed once the setup is completed. Storing = +the tree anywhere is unnecessary and endangers the Vault's privacy. + + +=E2=80=94 Example =E2=80=94=20 + +In this example, the Vault is composed of the actions A, B, C, D: + +A--->B--->C + \ + `--->D + +If H is the hash function, the Merkle tree is: + = + Merkle_root =20 + = + / \ + H(H(H(H(D)+H(1)) + H(H(C)+H(1))) + H(B)) H(A) + / \ = + =20 +H(H(H(D)+H(1)) + H(H(C)+H(1))) H(B) = + =20 + / \ =20 + H(H(D)+H(1)) H(H(C)+H(1)) =20 + / \ + 1 1 + +Note: 1 are terminations to signal to the network that the coins are now = +allowed to exit the Vault. If the 1-terminations were not added, the = +bitcoins would be locked forever in the Vault because it would require = +to reverse H to spend them. + +With notations: + = + Merkle_root =20 + = + / \ + = +Merkle_Proof(A) H(A) + = +/ \ =20 +Merkle_Proof(parent of C) =3D Merkle_Proof(B) H(B) = + =20 + / \ = + =20 + Merkle_Proof(C) H(H(C)+H(1)) =20 + \ + 1 + +=E2=80=94 nSequence =E2=80=94 + +nSequence has different timelock meanings for the different time related = +OP codes: +OP_CLTV: a tx spending the outputs of a [parent tx with nSequence] is = +invalid if current block number <=3D nSequence +OP_CSV: a tx spending the outputs of a [parent tx with nSequence] is = +invalid if current block number <=3D block number of the parent tx + = +nSequence + +New meaning of nSequence for OP_VAULT: +OP_VAULT: a tx with nSequence is invalid if current block number <=3D = +block number of the parent tx + nSequence + +=E2=80=94OP_VAULT=E2=80=94=20 + +This opcode checks if the tx timelock allows the tx to be included in a = +block and outputs a hash. + +OP_VAULT (nSequence, Merkle_proof(Action), pubKeyHash) +{ +IF (current block number >=3D Max(block number of the parent outputs) + = +nSequence of current tx) + hAction=3DH(H(pubKeyHash)+H(nSequence)); + h=3DH(Merkle_proof(Action)+hAction); + return h; + +ELSE + return H(0); // the tx cannot be = +included in a block yet +} + + +=E2=80=94Vault transaction structures=E2=80=94 + +Funding tx +scriptSig=3D<sig> <pubKey> +scriptPubKey=3D +<3> OP_PICK OP_HASH160 OP_VAULT <Merkle_root> OP_EQUALVERIFY OP_HASH160 = +<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG + +Vault tx +scriptSig=3D<sig> <pubKey> <nSequence> <Merkle_proof> +scriptPubKey=3D +<3> OP_PICK OP_HASH160 OP_VAULT <Merkle_proof> OP_EQUALVERIFY OP_HASH160 = +<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG + +Exit tx +scriptSig=3D<sig> <pubKey> <nSequence> <Merkle_proof> +scriptPubKey=3D +OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG + +Note: The exit tx can also use OP_VAULT if it is exiting the Vault while = +funding another Vault. + + +=E2=80=94New consensus rules=E2=80=94 (enforcement of OP_VAULT txs) + +IF +// this new rule concerns only Vault txs... +(parent tx VAULT_FLAG_ENABLE) +AND + // ...that are not permitted to exit the Vault if the action is not = +terminated by 1 in the Merkle tree=20 +( =20 +H(<Merkle_proof> in tx=E2=80=99s scriptSig + = +H(H(H(pubKeyHash)+H(nSequence))) + H(1))) !=3D <Merkle_proof> in parent = +tx=E2=80=99s scriptSig +) +AND +{ +// the tx must be flagged as a Vault tx +(tx VAULT_FLAG_DISABLE)=20 +OR +// the tx violates the Merkle tree data structure +(<Merkle_proof> in tx=E2=80=99s scriptSig !=3D <Merkle_proof> in tx=E2=80=99= +s scriptPubKey) +} + +THEN the transaction is INVALID. + +=E2=80=94Privacy=E2=80=94=20 + +In this design, Vault txs are CoinJoin/CT compatible (joining with other = +Vault txs) and perhaps Vault users will be willing to way for days or = +weeks to achieve maximum privacy, as they are susceptible of holding = +significant value in these structures. + +=E2=80=94Use-cases=E2=80=94=20 + +"Smart successions" : a morbid yet critical use-case for Bitcoin as a = +store of value + +Bitcoin currently struggles in dealing with successions in a trustless = +manner. How does the Bitcoin system know when the succession should be = +executed ? What happens in case of conflict between the heirs ? It=E2=80=99= +s a tricky but important use-case. + +Bitcoin successions are dealt with by either sharing decrypted private = +keys with the heirs (trusting they won=E2=80=99t take the coins before = +due time or won=E2=80=99t have them stolen), renting a safe at the bank = +and making a testament (trusting the bank) or simply hiding the keys and = +hoping the heirs will find them when you disappear. None of these = +schemes are satisfying, especially when dealing with multiple heirs. = +This gap could likely hold back investors from investing a significant = +portion of their wealth in Bitcoin if they don=E2=80=99t have a = +trustless and secure mechanism that guarantees their succession will be = +executed according to their will. + +Funding addr + \ + `->Transfert addr=E2=80=940=E2=80=94>Alice addr = + (1) + | \ + | `-50000=E2=80=94>Multisig2/2=E2=80=94>Bob = +addr =20 + | \ = + (2) + | = +`=E2=80=94>Carol addr + | + `-100000=E2=80=94>Multisig2/3=E2=80=94>Bob addr = + =20 + \ = + (3)=20 + `=E2=80=94>Carol = +addr =20 + +(1) Alice=E2=80=99s recovery address in case Bob and Carol were too = +impatient to spend the heritage. +(2) Alice added a Multisig2/2 controlled by Bob and Carol. Alice gave = +Bob and Carol each, half of the Merkel proof to pull the funds into = +Multisig2/2: first Bob and Carol need to agree on the conditions of the = +succession and sign the exit transaction from the Multisig2/2, than they = +can share their Merkel proof halves and pull the funds. +(3) Arbitration in case of disagreement (or if Bob or Carol is = +uncooperative, or disappeared): Alice added a Multisig2/3 involving an = +arbitrator in case Alice and Bob couldn=E2=80=99t find an agreement = +after 20=E2=80=99000 blocks or something. The arbitrator has no = +information on the succession until Bob or Carol asks for his = +assistance. Alice gave each Bob and Carol the full Merkel proof to pull = +the funds to Multisig2/3. + +We can imagine services assisting in the Vault setups and in the = +blockchain monitoring, enabling successions to occur entirely on-chain, = +in a trustless, private and peer-to-peer manner, outside of the current = +financial system.=20 + +Scorched earth policies if the Vault defender is entirely compromised +The following defence strategy is inspired from the paper mentionned in = +the introduction : + +Funding addr + \ + `->Transfert addr-1000->Spending addr + \ + `-0->Recovery addr1-100->Recovery addr2-1000->Recovery = +addr3 + = +\ + = + `-0->Hidden addr ?? + +An attacker broadcasts the Transfer tx from the Funding address. The = +defender can stay patient and learn if the attacker knows the recovery = +key (& the corresponding Merkle proofs) and ajust his defence = +accordingly: if indeed the adversary can move funds (he knows the = +recovery key(s)) and approches to the Vault exit (he knows also the = +Merkle proofs), the defender can burn all funds into fees, denying the = +attacker. + +=E2=80=94Thanks for your attention=E2=80=94 + +Please let me know if you think this idea is worth exploring deeper. + +Cheers, +Jerome + =20 + + +> On 27 Feb 2016, at 00:23, = +bitcoin-dev-request@lists.linuxfoundation.org wrote: +>=20 +> Send bitcoin-dev mailing list submissions to +> bitcoin-dev@lists.linuxfoundation.org +>=20 +> To subscribe or unsubscribe via the World Wide Web, visit +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> or, via email, send a message with subject or body 'help' to +> bitcoin-dev-request@lists.linuxfoundation.org +>=20 +> You can reach the person managing the list at +> bitcoin-dev-owner@lists.linuxfoundation.org +>=20 +> When replying, please edit your Subject line so it is more specific +> than "Re: Contents of bitcoin-dev digest..." +>=20 +>=20 +> Today's Topics: +>=20 +> 1. Bitcoin Vaults. (Emin G?n Sirer) +> 2. The first successful Zero-Knowledge Contingent Payment +> (Gregory Maxwell) +> 3. Re: The first successful Zero-Knowledge Contingent Payment +> (Sergio Demian Lerner) +> 4. Fwd: The first successful Zero-Knowledge Contingent Payment +> (Gregory Maxwell) +>=20 +>=20 +> ---------------------------------------------------------------------- +>=20 +> Message: 1 +> Date: Fri, 26 Feb 2016 11:05:20 -0500 +> From: Emin G?n Sirer <el33th4x0r@gmail.com> +> To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +> Cc: Malte M?ser <malte.moeser@uni-muenster.de>, Ittay Eyal +> <ittay.eyal@cornell.edu> +> Subject: [bitcoin-dev] Bitcoin Vaults. +> Message-ID: +> = +<CAPkFh0vuLsoNQUEdH-kGqXYvFJt1tXLvt0eMEuFZGm7Pus-_2g@mail.gmail.com> +> Content-Type: text/plain; charset=3D"utf-8" +>=20 +> 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. +>=20 +> The write-up is here: +>=20 +> = +http://hackingdistributed.com/2016/02/26/how-to-implement-secure-bitcoin-v= +aults/ +>=20 +> The paper with the nitty gritty details is here: +> http://fc16.ifca.ai/bitcoin/papers/MES16.pdf +>=20 +> The core idea: +>=20 +> 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?s decentralized version of you calling your bank to report a = +stolen +> credit card -- it renders the attacker?s transactions null and void. = +And +> here?s the interesting part: in so doing, vaults 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 first place, compared to = +current +> Bitcoin attackers who are guaranteed that their hacking efforts will = +be +> handsomely rewarded. +>=20 +> 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?s like an ?undo? facility that the modern banking = +world +> relies on, but for Bitcoin. +>=20 +> 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. +>=20 +> 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. +>=20 +> As always, comments and suggestions are welcome. +> - egs, Ittay Eyal and Malte Moeser. + + +--Apple-Mail=_B1F27580-A11F-4313-AC39-091FAC96BB0B +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=utf-8 + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = +class=3D""><div class=3D""><div style=3D"font-family:'Helvetica = +Neue';font-size:14px;" class=3D"">In Febuary, an email intitled "Bitcoin = +Vaults" was addressed to this mailing list linking to a paper on = +=E2=80=9Ccovenants=E2=80=9D (see mail below) describing a way to apply = +recursive restrictions temporarily or permanently on bitcoins (for = +digital asset use-cases) and Bitcoin Vaults were offered as an = +application (thanks to the authors for sharing their work with the = +community, I personally found this paper insightful and inspiring). = +Unfortunately, this proposal isn=E2=80=99t fungibility friendly and = +could lead Bitcoin to undesirable outcomes.</div><div = +style=3D"font-family:'Helvetica Neue';font-size:14px;" class=3D""><br = +class=3D""></div><span style=3D"font-family:'Helvetica = +Neue';font-size:14px;" class=3D""><div class=3D"">What follows is an = +attempt to design Vaults that preserve Bitcoin=E2=80=99s fungibility and = +keep their defensive attributes private from blockchain observers and = +from potential insider participants: the Vault=E2=80=99s defence is = +incrementally revealed when executed. If I am a war chief = +defending a castle, I=E2=80=99m certainly not going to show = +my defence strategy to the world and if it leaked to = +the enemy, it would greatly weaken my chances to succeed: greater = +privacy leads to greater security.</div><div class=3D""> </div><div = +class=3D"">Vaults enable important use-cases for Bitcoin as a store of = +value, in particular the tricky but critical use-case of successions = +(heritages).</div><div class=3D""><br class=3D""></div><div class=3D""><br= + class=3D""></div><div class=3D"">=E2=80=94 General idea = +=E2=80=94 </div><div class=3D""><br class=3D""></div><div = +class=3D"">This design restricts the bitcoins in a Vault to a private, = +predefined, finite (no patterns) and unforgeable set of authorized = +actions defined by the Vault creator at the setup.</div><div = +class=3D""><br class=3D""></div><div class=3D"">Definition: an = +authorized action (or action) is an authorized address the bitcoins = +inside a Vault can be sent to, with an authorized timelock.</div><div = +class=3D"">Action =3D <pubKeyHash> < timelock></div><div = +class=3D""><br class=3D""></div><div class=3D"">The Vault can be defined = +as a set of parent/child authorized actions. This enables the Vault = +creator to construct a Merkle tree of his Vault. During the setup, the = +creator computes the hashs of every authorized action, and builds his = +Merkle tree from the bottom, up to the top Merkle root. The Vault = +creator must give the appropriate Merkle proofs (authorizations) to the = +Vault participants (if any) according to the authorizations he grants = +them, and when someone wants to move funds inside or out of the Vault, = +he needs to provide to the network (in addition of a valid signature) = +the Merkle proof that demonstrates that his action is authorized by the = +Vault. The network can verify that: </div><div class=3D""><i = +class=3D"">Hash [ Merkle_proof(Action) + </i><i = +class=3D"">Hash(Action)</i><i class=3D""> ] =3D=3D = +Merkle_proof(Parent_Action)</i></div></span><span = +style=3D"font-family:'Helvetica Neue';font-size:14px;" class=3D""><div = +class=3D""><br class=3D""></div><div class=3D"">The Merkle tree must be = +destroyed once the setup is completed. Storing the tree anywhere is = +unnecessary and endangers the Vault's privacy.</div><div class=3D""><br = +class=3D""></div><div class=3D""><br class=3D""></div><div = +class=3D"">=E2=80=94 Example =E2=80=94 </div><div class=3D""><br= + class=3D""></div><div class=3D"">In this example, the Vault is composed = +of the actions A, B, C, D:</div><div class=3D""><br class=3D""></div><div = +class=3D"">A--->B--->C</div><div class=3D""> = + \</div><div class=3D""> = + `--->D</div><div class=3D""><br class=3D""></div><div = +class=3D"">If H is the hash function, the Merkle tree is:</div><div = +class=3D""> = + = + = + = +Merkle_root </div><div class=3D""> = + = + = + = + = +/ \</div><div class=3D""> = + H(H(H(H(D)+H(1)) + H(H(C)+H(1))) + = +H(B)) H(A)</div><div class=3D""> = + = + = + / \ = + = + = + </div><div = +class=3D"">H(H(H(D)+H(1)) + H(H(C)+H(1))) = +H(B) = + </div><div = +class=3D""> = + / \ = + = + </div><div = +class=3D""> H(H(D)+H(1)) H(H(C)+H(1)) = + </div><div = +class=3D""> / = + = + \</div><div class=3D""> = + 1 = + 1</div><div class=3D""><br = +class=3D""></div><div class=3D"">Note: 1 are terminations to signal to = +the network that the coins are now allowed to exit the Vault. If the = +1-terminations were not added, the bitcoins would be locked forever in = +the Vault because it would require to reverse H to spend them.</div><div = +class=3D""><br class=3D""></div><div class=3D"">With = +notations:</div><div class=3D""> = + = + = + = + Merkle_root = + </div><div class=3D""> = + = + = + = + = +/ \</div><div class=3D""> = + = + = + = +Merkle_Proof(A) H(A)</div><div class=3D""> = + = + = + = + / \ = + = + = + </div><div = +class=3D"">Merkle_Proof(parent of C) =3D Merkle_Proof(B) = + H(B) = + = + </div><div class=3D""> = + = + / \ = + = + </div><div = +class=3D""> Merkle_Proof(C) = + H(H(C)+H(1)) = + </div><div class=3D""> = + = + = + \</div><div class=3D""> = + = + = + 1</div><div class=3D""><br= + class=3D""></div><div class=3D"">=E2=80=94 nSequence =E2=80=94</div>= +<div class=3D""><span style=3D"color: rgb(255, 0, 0);" class=3D""><br = +class=3D""></span></div><div class=3D"">nSequence has different timelock = +meanings for the different time related OP codes:</div><div = +class=3D"">OP_CLTV: a tx spending the outputs of a [parent tx with = +nSequence] is invalid if <i class=3D"">current block number= + <=3D nSequence</i></div><div class=3D"">OP_CSV: a tx spending the = +outputs of a [parent tx with nSequence] is invalid if <i = +class=3D"">current block number <=3D block number of the parent = +tx + nSequence</i></div><div class=3D""><br class=3D""></div><div = +class=3D"">New meaning of nSequence for OP_VAULT:</div><div = +class=3D"">OP_VAULT: a tx with nSequence is invalid if <i = +class=3D"">current block number <=3D block number of the parent = +tx + nSequence</i></div><div class=3D""><br class=3D""></div><div = +class=3D"">=E2=80=94OP_VAULT=E2=80=94 </div><div class=3D""><br = +class=3D""></div><div class=3D"">This opcode checks if the tx timelock = +allows the tx to be included in a block and outputs a hash.</div><div = +class=3D""><br class=3D""></div><div class=3D"">OP_VAULT (nSequence, = +Merkle_proof(Action), pubKeyHash)</div><div class=3D"">{</div><div = +class=3D"">IF (<i class=3D"">current block number >=3D Max(block = +number of the parent outputs) + nSequence of current tx</i>)</div><div = +class=3D""> hAction=3DH(H(pubKeyHash)+H(nSequ= +ence));</div><div = +class=3D""> h=3DH(Merkle_proof(Action)+hActio= +n);</div><div class=3D""> return = +h;</div><div class=3D""><br class=3D""></div><div = +class=3D"">ELSE</div><div class=3D""> return H(0); = + = + // the = +tx cannot be included in a block yet</div><div class=3D"">}</div><div = +class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div = +class=3D"">=E2=80=94Vault transaction structures=E2=80=94</div><div = +class=3D""><br class=3D""></div><div class=3D""><u class=3D"">Funding = +tx</u></div><div class=3D"">scriptSig=3D<sig> = +<pubKey></div><div class=3D"">scriptPubKey=3D</div><div = +class=3D""><span style=3D"font-family: sans-serif; = +font-variant-ligatures: normal; font-variant-position: normal; = +font-variant-numeric: normal; font-variant-alternates: normal; = +font-variant-east-asian: normal; widows: 1; background-color: rgb(249, = +249, 249);" class=3D""><3> </span><span style=3D"font-family: = +sans-serif; font-variant-ligatures: normal; font-variant-position: = +normal; font-variant-numeric: normal; font-variant-alternates: normal; = +font-variant-east-asian: normal; widows: 1; background-color: rgb(249, = +249, 249);" class=3D"">OP_PICK </span>OP_HASH160 = +OP_VAULT <Merkle_root> OP_EQUALVERIFY OP_HASH160 = +<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG</div><div class=3D""><br = +class=3D""></div><div class=3D""><u class=3D"">Vault tx</u></div><div = +class=3D"">scriptSig=3D<sig> <pubKey> <nSequence> = +<Merkle_proof></div><div class=3D"">scriptPubKey=3D</div><div = +class=3D""><span style=3D"font-family: sans-serif; = +font-variant-ligatures: normal; font-variant-position: normal; = +font-variant-numeric: normal; font-variant-alternates: normal; = +font-variant-east-asian: normal; widows: 1; background-color: rgb(249, = +249, 249);" class=3D""><3> </span><span style=3D"font-family: = +sans-serif; font-variant-ligatures: normal; font-variant-position: = +normal; font-variant-numeric: normal; font-variant-alternates: normal; = +font-variant-east-asian: normal; widows: 1; background-color: rgb(249, = +249, 249);" class=3D"">OP_PICK</span> OP_HASH160 = +OP_VAULT <Merkle_proof> OP_EQUALVERIFY OP_HASH160 = +<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG</div><div class=3D""><br = +class=3D""></div><div class=3D""><u class=3D"">Exit tx</u></div><div = +class=3D"">scriptSig=3D<sig> <pubKey> = +<nSequence> <Merkle_proof></div><div = +class=3D"">scriptPubKey=3D</div><div class=3D"">OP_DUP OP_HASH160 = +<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG</div><div class=3D""><br = +class=3D""></div><div class=3D"">Note: The exit tx can also use OP_VAULT = +if it is exiting the Vault while funding another Vault.</div><div = +class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div = +class=3D"">=E2=80=94New consensus rules=E2=80=94 (enforcement of = +OP_VAULT txs)</div><div class=3D""><br class=3D""></div><div = +class=3D"">IF</div><div class=3D"">// this new rule concerns only Vault = +txs...</div><div class=3D"">(<i class=3D"">parent</i> <i class=3D"">tx</i>= + VAULT_FLAG_ENABLE)</div><div class=3D"">AND</div><div class=3D""> //= + ...that are not permitted to exit the Vault if the action is not = +terminated by 1 in the Merkle tree </div><div class=3D"">( = + </div><div class=3D"">H(<Merkle_proof> in <i = +class=3D"">tx</i>=E2=80=99s scriptSig = ++ H(H(H(pubKeyHash)+H(nSequence))) + H(1))) = +!=3D <Merkle_proof> in <i class=3D"">parent tx</i>=E2=80=99= +s scriptSig</div><div class=3D"">)</div><div class=3D"">AND</div><div = +class=3D"">{</div><div class=3D""> +<div class=3D"">// the tx must be flagged as a Vault tx</div> +</div><div class=3D"">(<i class=3D"">tx</i> = +VAULT_FLAG_DISABLE) </div><div class=3D"">OR</div><div class=3D""> +<div class=3D"">// the tx violates the Merkle tree data structure</div> +</div><div class=3D"">(<Merkle_proof> in <i class=3D"">tx</i>=E2=80=99= +s scriptSig !=3D <Merkle_proof> in <i class=3D"">tx</i>=E2=80=99= +s scriptPubKey)</div><div class=3D"">}</div><div class=3D""><br = +class=3D""></div><div class=3D"">THEN the transaction is = +INVALID.</div><div class=3D""><br class=3D""></div><div = +class=3D"">=E2=80=94Privacy=E2=80=94 </div><div class=3D""><br = +class=3D""></div><div class=3D"">In this design, Vault txs are = +CoinJoin/CT compatible (joining with other Vault txs) and perhaps Vault = +users will be willing to way for days or weeks to achieve maximum = +privacy, as they are susceptible of holding significant value in these = +structures.</div><div class=3D""><br class=3D""></div><div = +class=3D"">=E2=80=94Use-cases=E2=80=94 </div><div class=3D""><br = +class=3D""></div><div class=3D""><u class=3D"">"Smart successions" = +: </u><u class=3D"">a morbid yet critical use-case for Bitcoin as a = +store of value</u></div><div class=3D""><br class=3D""></div><div = +class=3D"">Bitcoin currently struggles in dealing with successions in a = +trustless manner. How does the Bitcoin system know when the succession = +should be executed ? What happens in case of conflict between the heirs = +? It=E2=80=99s a tricky but important use-case.</div><div class=3D""><br = +class=3D""></div><div class=3D"">Bitcoin successions are dealt with by = +either sharing decrypted private keys with the heirs (trusting they = +won=E2=80=99t take the coins before due time or won=E2=80=99t have them = +stolen), renting a safe at the bank and making a testament (trusting the = +bank) or simply hiding the keys and hoping the heirs will find them when = +you disappear. None of these schemes are satisfying, especially when = +dealing with multiple heirs. This gap could likely hold back investors = +from investing a significant portion of their wealth in Bitcoin if they = +don=E2=80=99t have a trustless and secure mechanism that guarantees = +their succession will be executed according to their will.</div><div = +class=3D""><br class=3D""></div><div class=3D""><div class=3D"">Funding = +addr</div> +</div><div class=3D""> \</div><div class=3D""> = + `->Transfert addr=E2=80=940=E2=80=94>Alice addr = + = + (1)</div><div class=3D""> = + | = + \</div><div class=3D""> = + | = +`-50000=E2=80=94>Multisig2/2=E2=80=94>Bob addr = + </div><div class=3D""> = + | = + = + \ = + = + (2)</div><div class=3D""> = + | = + = + = +`=E2=80=94>Carol addr</div><div class=3D""> = + |</div><div class=3D""> = + = +`-100000=E2=80=94>Multisig2/3=E2=80=94>Bob addr = + </div><div class=3D""> = + = + = + \ = + = + = + (3) </div><div class=3D""> = + = + = + `=E2=80=94>Carol addr = + </div><div class=3D""><br = +class=3D""></div><div class=3D"">(1) Alice=E2=80=99s recovery address in = +case Bob and Carol were too impatient to spend the heritage.</div><div = +class=3D"">(2) Alice added a Multisig2/2 controlled by Bob and Carol. = +Alice gave Bob and Carol each, half of the Merkel proof to pull the = +funds into Multisig2/2: first Bob and Carol need to agree on the = +conditions of the succession and sign the exit transaction from the = +Multisig2/2, than they can share their Merkel proof halves and pull the = +funds.</div><div class=3D"">(3) Arbitration in case of disagreement (or = +if Bob or Carol is uncooperative, or disappeared): Alice added a = +Multisig2/3 involving an arbitrator in case Alice and Bob couldn=E2=80=99t= + find an agreement after 20=E2=80=99000 blocks or something. The = +arbitrator has no information on the succession until Bob or Carol asks = +for his assistance. Alice gave each Bob and Carol the full Merkel = +proof to pull the funds to Multisig2/3.</div><div class=3D""><br = +class=3D""></div><div class=3D"">We can imagine services assisting in = +the Vault setups and in the blockchain monitoring, enabling successions = +to occur entirely on-chain, in a trustless, private and peer-to-peer = +manner, outside of the current financial system. </div><div = +class=3D""><br class=3D""></div><div class=3D""><u class=3D"">Scorched = +earth policies if the Vault defender is entirely = +compromised</u></div><div class=3D"">The following defence strategy is = +inspired from the paper mentionned in the introduction :</div><div = +class=3D""><br class=3D""></div><div class=3D"">Funding addr</div><div = +class=3D""> \</div><div class=3D""> = +`->Transfert addr-1000->Spending addr</div><div class=3D""> = + \</div><div = +class=3D""> = + `-0->Recovery addr1-100->Recovery addr2-1000->Recovery = +addr3</div><div class=3D""> = + = + = + = + \</div><div class=3D""><i class=3D""> = + = + = + = + `-0->Hidden addr ??</i></div><div = +class=3D""><br class=3D""></div><div class=3D"">An attacker broadcasts = +the Transfer tx from the Funding address. The defender can stay patient = +and learn if the attacker knows the recovery key (& the = +corresponding Merkle proofs) and ajust his defence accordingly: if = +indeed the adversary can move funds (he knows the recovery key(s)) and = +approches to the Vault exit (he knows also the Merkle proofs), the = +defender can burn all funds into fees, denying the attacker.</div><div = +class=3D""><br class=3D""></div><div class=3D"">=E2=80=94Thanks for your = +attention=E2=80=94</div><div class=3D""><br class=3D""></div><div = +class=3D"">Please let me know if you think this idea is worth exploring = +deeper.</div><div class=3D""><br class=3D""></div><div = +class=3D"">Cheers,</div><div class=3D"">Jerome</div><div class=3D""> = + = + = + = + </div></span></div><div class=3D""><br class=3D""></div><br = +class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = +27 Feb 2016, at 00:23, <a = +href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" = +class=3D"">bitcoin-dev-request@lists.linuxfoundation.org</a> = +wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = +class=3D"">Send bitcoin-dev mailing list submissions to<br = +class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"> = +</span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = +class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><br = +class=3D"">To subscribe or unsubscribe via the World Wide Web, visit<br = +class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"> = +</span>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br = +class=3D"">or, via email, send a message with subject or body 'help' = +to<br class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre">= + </span>bitcoin-dev-request@lists.linuxfoundation.org<br = +class=3D""><br class=3D"">You can reach the person managing the list = +at<br class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre">= + </span>bitcoin-dev-owner@lists.linuxfoundation.org<br = +class=3D""><br class=3D"">When replying, please edit your Subject line = +so it is more specific<br class=3D"">than "Re: Contents of bitcoin-dev = +digest..."<br class=3D""><br class=3D""><br class=3D"">Today's = +Topics:<br class=3D""><br class=3D""> 1. Bitcoin Vaults. = +(Emin G?n Sirer)<br class=3D""> 2. The first successful = +Zero-Knowledge Contingent Payment<br class=3D""> = + (Gregory Maxwell)<br class=3D""> = + 3. Re: The first successful Zero-Knowledge Contingent<span = +class=3D"Apple-tab-span" style=3D"white-space:pre"> = +</span>Payment<br class=3D""> (Sergio = +Demian Lerner)<br class=3D""> 4. Fwd: The first successful = +Zero-Knowledge Contingent<span class=3D"Apple-tab-span" = +style=3D"white-space:pre"> </span>Payment<br class=3D""> = + (Gregory Maxwell)<br class=3D""><br = +class=3D""><br = +class=3D"">---------------------------------------------------------------= +-------<br class=3D""><br class=3D"">Message: 1<br class=3D"">Date: Fri, = +26 Feb 2016 11:05:20 -0500<br class=3D"">From: Emin G?n Sirer = +<el33th4x0r@gmail.com><br class=3D"">To: Bitcoin Dev = +<bitcoin-dev@lists.linuxfoundation.org><br class=3D"">Cc: Malte = +M?ser <malte.moeser@uni-muenster.de>,<span class=3D"Apple-tab-span" = +style=3D"white-space:pre"> </span>Ittay Eyal<br class=3D""><span = +class=3D"Apple-tab-span" style=3D"white-space:pre"> = +</span><ittay.eyal@cornell.edu><br class=3D"">Subject: = +[bitcoin-dev] Bitcoin Vaults.<br class=3D"">Message-ID:<br = +class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"> = +</span><CAPkFh0vuLsoNQUEdH-kGqXYvFJt1tXLvt0eMEuFZGm7Pus-_2g@mail.gmail.= +com><br class=3D"">Content-Type: text/plain; charset=3D"utf-8"<br = +class=3D""><br class=3D"">At the 3rd Bitcoin Workshop being held in = +conjunction with the Financial<br class=3D"">Cryptography Conference in = +Barbados, my group will be presenting a new idea<br class=3D"">for = +improving Bitcoin wallet security and deterring thefts today.<br = +class=3D""><br class=3D"">The write-up is here:<br class=3D""><br = +class=3D"">http://hackingdistributed.com/2016/02/26/how-to-implement-secur= +e-bitcoin-vaults/<br class=3D""><br class=3D"">The paper with the nitty = +gritty details is here:<br class=3D""> = + http://fc16.ifca.ai/bitcoin/papers/MES16.pdf<br = +class=3D""><br class=3D"">The core idea:<br class=3D""><br class=3D"">Our = +paper describes a way to create vaults, special accounts whose keys = +can<br class=3D"">be neutralized if they fall into the hands of = +attackers. Vaults are<br class=3D"">Bitcoin?s decentralized version of = +you calling your bank to report a stolen<br class=3D"">credit card -- it = +renders the attacker?s transactions null and void. And<br = +class=3D"">here?s the interesting part: in so doing, vaults demotivate = +key theft in<br class=3D"">the first place. An attacker who knows that = +he will not be able to get away<br class=3D"">with theft is less likely = +to attack in the first place, compared to current<br class=3D"">Bitcoin = +attackers who are guaranteed that their hacking efforts will be<br = +class=3D"">handsomely rewarded.<br class=3D""><br = +class=3D"">Operationally, the idea is simple. You send your money to a = +vault address<br class=3D"">that you yourself create. Every vault = +address has a vault key and a<br class=3D"">recovery key. When spending = +money from the vault address with the<br class=3D"">corresponding vault = +key, you must wait for a predefined amount of time<br class=3D"">(called = +the unvaulting period) that you established at the time you created<br = +class=3D"">the vault -- say, 24 hours. When all goes well, your vault = +funds are<br class=3D"">unlocked after the unvaulting period and you can = +move them to a standard<br class=3D"">address and subsequently spend = +them in the usual way. Now, in case Harry<br class=3D"">the Hacker gets = +a hold of your vault key, you have 24 hours to revert any<br = +class=3D"">transaction issued by Harry, using the recovery key. His = +theft,<br class=3D"">essentially, gets undone, and the funds are = +diverted unilaterally to their<br class=3D"">rightful owner. It?s like = +an ?undo? facility that the modern banking world<br class=3D"">relies = +on, but for Bitcoin.<br class=3D""><br class=3D"">The technical trick = +relies on a single new opcode, CheckOutputVerify, that<br = +class=3D"">checks the shape of a redeem transaction. Note that = +fungibility is not<br class=3D"">affected, as the restrictions are at = +the discretion of the coin owner alone<br class=3D"">and can only be = +placed by the coin owner ahead of time.<br class=3D""><br class=3D"">We = +suspect that this modest change could actually be a game-changer for<br = +class=3D"">bitcoin security: clients and keys are notoriously hard to = +secure, and a<br class=3D"">facility that allows you to possibly = +recover, and if not, permanently keep<br class=3D"">the hacker from = +acquiring your funds, could greatly deter Bitcoin thefts.<br = +class=3D""><br class=3D"">As always, comments and suggestions are = +welcome.<br class=3D"">- egs, Ittay Eyal and Malte Moeser.<br = +class=3D""></div></div></blockquote></div><br class=3D""></body></html>= + +--Apple-Mail=_B1F27580-A11F-4313-AC39-091FAC96BB0B-- + |