On Sat, Feb 16, 2013 at 01:49:18PM -0500, Jonathan Warren wrote:
> Hello everyone, I would like to introduce you to a communications protocol I
> have been working on called Bitmessage. I have also written an open source
> client released under the MIT/X11 license. It borrows ideas from Bitcoin and
> Hashcash and aims to form a secure and decentralized communications protocol
> which also doesn't rely on trust. Criticism of the X.509 certificate system
> is understandably common in this listserv (and also increasingly common in
> more public forums); Bitmessage instead uses Bitcoin-like addresses for
> authentication. It has a 'broadcast' and 'subscription' feature which other
> people have described as a decentralized Twitter and also aims to hide
> "non-content" data, like the sender and receiver of messages, from passive
> eavesdroppers like those running warrantless wiretapping programs. It may
> also be possible to be strong against active attackers although I'm not yet
> making that claim.
...
> I would be interested to hear your comments. The website
> https://bitmessage.org links to various resources like a short whitepaper
> describing how the protocol works and what its goals are (
> https://bitmessage.org/bitmessage.pdf ) and the source code on Github (
At a first glance, I strongly like the hierarchical cluster design.
I'll need to think about it for a while to decide if it actually works.
Having an explicit motivation ("threat model" in security protocol
parlance) would help in analyzing if this feature provides the desired
benefits. You should also figure out what problems the cluster model
doesn't solve and explicitly identify them. For an example of a threat
model see section 3.1 of
https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf
I think it would be worth having a separate threat model for the stream
scalability design, in addition to elucidating one for Bitmessage as a
whole.
The "proxy ack" feature you describe in section 7 is a single-hop
fixed-usage onion routing mode. How about extending it to arbitrarily
nested messages (with a separate proof-of-work on each one, of course)?
With the release of new software, the difficulty of the
proof-of-work can be adjusted.
Why not include an auto-adjusting network difficulty factor like Bitcoin
rather than requiring a client upgrade? I think this is a critical
issue. Suppose that Bitmessage 1.0 becomes popular and spam becomes a
problem. You release 2.0 with an increased PoW factor. How long do you
wait before 2.0 clients stop accepting messages from 1.0 clients? Until
they stop, the spam problem continues; after they stop, peers who
haven't upgraded (because they're running Debian Stable or whatever) are
unable to talk to their friends until they upgrade.
Have you considered replacing your bespoke PoW system with simply
including Bitcoin postage on messages?
-andy
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
