1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
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--
|
