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