You can subscribe to this list here.
2011 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(81) 
_{Jul}
(186) 
_{Aug}
(166) 
_{Sep}
(185) 
_{Oct}
(94) 
_{Nov}
(85) 
_{Dec}
(217) 

2012 
_{Jan}
(135) 
_{Feb}
(131) 
_{Mar}
(70) 
_{Apr}
(62) 
_{May}
(87) 
_{Jun}
(139) 
_{Jul}
(128) 
_{Aug}
(39) 
_{Sep}
(58) 
_{Oct}
(82) 
_{Nov}
(77) 
_{Dec}
(90) 
2013 
_{Jan}
(21) 
_{Feb}
(51) 
_{Mar}
(143) 
_{Apr}
(152) 
_{May}
(200) 
_{Jun}
(167) 
_{Jul}
(193) 
_{Aug}
(163) 
_{Sep}
(93) 
_{Oct}
(199) 
_{Nov}
(247) 
_{Dec}
(230) 
2014 
_{Jan}
(289) 
_{Feb}
(196) 
_{Mar}
(489) 
_{Apr}
(693) 
_{May}
(280) 
_{Jun}
(240) 
_{Jul}
(227) 
_{Aug}
(189) 
_{Sep}
(76) 
_{Oct}
(189) 
_{Nov}
(106) 
_{Dec}
(68) 
S  M  T  W  T  F  S 







1

2
(5) 
3
(5) 
4
(8) 
5
(3) 
6

7
(4) 
8
(1) 
9
(10) 
10
(27) 
11
(8) 
12
(15) 
13
(3) 
14
(7) 
15
(1) 
16
(2) 
17
(1) 
18
(8) 
19
(11) 
20
(12) 
21
(12) 
22
(7) 
23

24
(19) 
25
(13) 
26
(3) 
27
(1) 
28
(10) 

From: Jeremy Hahn <mail@je...>  20140205 21:42:47

Relocating this conversation to the dev list. Feedback / continued discussion welcome. https://github.com/bitcoin/bitcoin/issues/3624 
From: Brooks Boyd <boydb@mi...>  20140205 15:09:41

On Tue, Feb 4, 2014 at 10:04 AM, Peter Todd <pete@...> 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? > Given a tree like: G / \ E F / \ C D / \ A B Where G is the root hash and A is the legitimate data that was included in the tree, the legitimate user provides B, D and F along with A to prove A is part of the tree G. Now an attacker could just make up an arbitrary set of values that XOR together into G, like: G / \ Z Y And could therefore claim Z is part of tree G by providing Y. But if A is also trying to prove its a part of G, we know the first level of the tree must be E and F. It cannot also be Z and Y, so one of the two users is lying and the deceit is obvious, though not obvious which user is lying. An attacker could look more convincing by using the data passed with A as a starting point: G / \ E F / \ / \ / \ C D / \ / \ A B Z Y Instead of working off of G, work of the lowest branch provided by A in its verification (D, in this case), and create the fake data Z, and calculate Y such that Z XOR Y == D (which is just Z XOR D). Now the attacker can claim Z is part of G by supplying Y, C, and F. The tree looks valid (it can coexist with the proof provided by A, at least until someone else claims to be a descendant of the D node as well), and since G was verified by timestamp, looks like Z existed before that timestamp, when really it could be added at any time by calculating Z XOR D. Brooks 
From: Jeremy Spilman <jeremy@ta...>  20140205 07:57:42

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