That would get extremely bulky in mass-adoption, in both local storage and network usage. Currently they have some structure to create tiered "streams", but that still doesn't eliminate the excessive network burden, it just saves some disk space. 

The streams work in a hierarchy, with the uppermost assuming the highest network burden. Because it's necessary to send an acknowledgement message, a complete circuit must established (though not all at once) between nodes.

Also "broadcast messages" seem too risky to me. They're liable to be abused and cause a DoS if this protocol is adopted on a large-scale.

Proof-of-work doesn't protect broadcast message abuse, because an attacker could just use a small botnet to generate a bunch of untransmitted messages with similar timestamps for a future date. Once that date arrives, then the attacker could just submit a very large batch of valid broadcast bitmessages.

I can't think of a solution to either of these problems right now, but I otherwise think Bitmessage is a great idea. It's current, humbly sized userbase makes for comfortable testing. 

https://bitmessage.org/bitmessage.pdf

James


On 25 October 2013 01:41, Russ Nelson <nelson@crynwr.com> wrote:
I haven't seen any discussion of BitMessage (http://bitmessage.org)
here yet. The idea is to be a mixer with a pool of recipients, which
currently seems to be 12,000ish. Before anybody will receive your
message, they need to see a proof of work. Once they do, they forward
the message to everyone else, using a flood-fill algorithm. Messages
are encrypted so only the recipient can decode them. Mailing lists are
simulated via a shared private key.

It looks plausible. Not obviously snake oil.

--
--my blog is at    http://blog.russnelson.com
Crynwr supports open source software
521 Pleasant Valley Rd. | +1 315-600-8815
Potsdam, NY 13676-3213  |     Sheepdog
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography