summaryrefslogtreecommitdiff
path: root/54/658e1e3398ff87ad0de016b528ecaf7c58d703
blob: 955dc7702b68bab0e9118b1ff829f78b3ea601bc (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jeremy@taplink.co>) id 1WAxMc-0001j6-6d
	for bitcoin-development@lists.sourceforge.net;
	Wed, 05 Feb 2014 07:57:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of taplink.co
	designates 50.117.27.232 as permitted sender)
	client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
	helo=mail.taplink.co; 
Received: from mail.taplink.co ([50.117.27.232])
	by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1WAxMb-0004SY-EA for bitcoin-development@lists.sourceforge.net;
	Wed, 05 Feb 2014 07:57:42 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co ;
	Tue, 4 Feb 2014 23:57:58 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: Natanael <natanael.l@gmail.com>, "Peter Todd" <pete@petertodd.org>
References: <1D8E0828-D07F-46EF-9F9F-5CA83AA9DB59@plan99.net>
	<20140204130312.GA23538@savin>
	<CANEZrP2NyvRKwSEZORjAOq6G7UqLv=F3FjxmGNTPMT10yWGxzw@mail.gmail.com>
	<20140204131723.GA10309@savin>
	<CAAt2M1-LZ1APX9F93WE7Z877-WxqvJFbGaUmu5eriRGwvAOESw@mail.gmail.com>
	<20140204160414.GA23803@savin>
Date: Tue, 04 Feb 2014 23:57:36 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xastqaf9yldrnw@laptop-air>
In-Reply-To: <20140204160414.GA23803@savin>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -2.1 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WAxMb-0004SY-EA
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh,
 bip39 and payment protocol support
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 07:57:42 -0000

Well the point of the Merkle tree is that if I all you have is the top,  
and all I give you is a leaf node and the siblings of all parents of that  
leaf, then by simply hashing you can check if the node was actually  
present in the tree.

The only reason this works is because it's hard for an attacker to come up  
with the list of values which would ultimately hash together to produce  
the expected top value. But if the hash function is actually just XOR, it  
becomes completely trivial for me to claim any value I want was in the  
tree.

1) Pick the fake value you want to claim was in the tree (leaf node)
2) Choose some random values to fake the depth in the tree
3) Calculate the last value as 'Prev (x) Top'
4) When your victim goes to verify set membership, they will get the top  
value they expected



On Tue, 04 Feb 2014 08:04:14 -0800, Peter Todd <pete@petertodd.org> wrote:

> On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote:
>> Because it's trivial to create collisions! You can choose exactly what
>> output you want. That's why XOR is a very bad digest scheme.
>
> You're close, but not quite.
>
> So, imagine you have a merkle tree, and you're trying to timestamp some
> data at the bottom of the tree. Now you can successfully timestamp the
> top digest in the Bitcoin blockchain right, and be sure that digest
> existed before some time. But what about the digests at the bottom of
> the tree? What can an attacker do exactly to make a fake timestamp if
> the tree is using XOR rather than a proper hash function?