report from LAFS Hack Hour 2014-02-13

[Zooko Wilcox-OHearn]

Folks:

I was the only one who showed up at LAFS Hack Hour today. I started
working on #1382, and saw that generate_upload_plan() ¹ seems to be
computing some local variables from other local variables (peers and
shares) from other local variables (map), and then passing all three
as arguments to _calculate_mappings() ². Why, I wondered, does it just
pass that third one to _calculate_mappings() and let
_calculate_mappings() generate the other two from the third one?

Investigating that, I saw what seemed to be another redundancy, that
_calculate_mappings() invokes _reindex() ³ to generate a mapping
between things and small integers, and then invokes
_servermap_flow_graph() ⁴, which then invokes _reindex() again,
itself. Are these two invocations of _reindex() supposed to be
generating the same result as each other?

Then I got tired of working on this all by myself and switched to
editing a note I've written about the historical tendency of secure
hash functions to succumb to collision attacks but not to
(second-)pre-image attacks. I hope to publish that note soon. Please
contact me if you're an expert in secure hash functions and want to
help me review it for errors before I publish it.

The next LAFS Hack Hour will be Monday, the 17th, at 22:00Z!

Regards,

Zooko

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382# immutable peer
selection refactoring and enhancements

¹ https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L30

² https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L90

³ https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L282

⁴ https://github.com/zooko/tahoe-lafs/blob/6fd9d90e9fc667a8f21028a4c73bef5265e3facd/src/allmydata/immutable/happiness_upload.py#L256