Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1ADFC74 for ; 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 ; Sun, 24 Apr 2016 10:05:56 +0000 (UTC) Received: by mail-wm0-f66.google.com with SMTP id e201so14787687wme.2 for ; 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 (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?= 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: To: bitcoin-dev@lists.linuxfoundation.org In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 < 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 scriptPubKey=3D <3> OP_PICK OP_HASH160 OP_VAULT OP_EQUALVERIFY OP_HASH160 = OP_EQUALVERIFY OP_CHECKSIG Vault tx scriptSig=3D scriptPubKey=3D <3> OP_PICK OP_HASH160 OP_VAULT OP_EQUALVERIFY OP_HASH160 = OP_EQUALVERIFY OP_CHECKSIG Exit tx scriptSig=3D scriptPubKey=3D OP_DUP OP_HASH160 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( in tx=E2=80=99s scriptSig + = H(H(H(pubKeyHash)+H(nSequence))) + H(1))) !=3D 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 ( in tx=E2=80=99s scriptSig !=3D 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 > To: Bitcoin Dev > Cc: Malte M?ser , Ittay Eyal > > Subject: [bitcoin-dev] Bitcoin Vaults. > Message-ID: > = > 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
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=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.
 
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 

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:    
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 
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  
        =                     =                     =                     =           = /     \
    =           H(H(H(H(D)+H(1)) + H(H(C)+H(1))) + = H(B))       H(A)
    =                     =                     =      /     \     =                     =                     =            
H(H(H(D)+H(1)) + H(H(C)+H(1)))        = H(B)                   =               
                =      /     \     =                     =           
 H(H(D)+H(1))        H(H(C)+H(1)) =                
           /   =                     =      \
        =   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 =  
            =                     =                     =                     =                 = /     \
    =                     =                     =                   = Merkle_Proof(A)       H(A)
  =                     =                     =                     =           /     \ =                     =                     =                
Merkle_Proof(parent of C) =3D Merkle_Proof(B)     =    H(B)               =                 =   
          =                     =         /     \   =                     =             
            Merkle_Proof(C) =        H(H(C)+H(1))         =        
      =                     =                     =           \
    =                     =                     =              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 

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(nSequ= ence));
     h=3DH(Merkle_proof(Action)+hActio= n);
     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 
(   =  
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=99= s scriptSig
)
AND
{
// the tx must be flagged as a Vault tx
(tx = VAULT_FLAG_DISABLE) 
OR
// the tx violates the Merkle tree data structure
(<Merkle_proof> in tx=E2=80=99= s scriptSig !=3D <Merkle_proof> in tx=E2=80=99= s scriptPubKey)
}

THEN the transaction is = INVALID.

=E2=80=94Privacy=E2=80=94 

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 

"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=99s 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   =  
            =    |                 =                     =         \             =              =      (2)
    =            |         =                     =                   = `=E2=80=94>Carol addr
      =          |
    =             = `-100000=E2=80=94>Multisig2/3=E2=80=94>Bob addr     =            
  =                     =                     =         \         =                     =         =      (3) 
  =                     =                     =           `=E2=80=94>Carol addr   =           

(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. 

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
 =                     =                     =                     =    


On = 27 Feb 2016, at 00:23, bitcoin-dev-request@lists.linuxfoundation.org = wrote:

Send bitcoin-dev mailing list submissions to
= bitcoin-dev@lists.linuxfoundation.org

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

You can reach the person managing the list = at
= bitcoin-dev-owner@lists.linuxfoundation.org

When replying, please edit your Subject line = so it is more specific
than "Re: Contents of bitcoin-dev = digest..."


Today's = Topics:

  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)


---------------------------------------------------------------= -------

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"

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-secur= e-bitcoin-vaults/

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?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.

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.

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.

= --Apple-Mail=_B1F27580-A11F-4313-AC39-091FAC96BB0B--