Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin - page 8. (Read 89873 times)

Securty Now (Twit TV) did a podcast about BitMessage.  I am just now watching it, but it doesn't look favorable.

http://twit.tv/show/security-now/420

Interesting ideas with BitMask.
If you are have ideas to integrate with Namecoin identities also you can start a thread on the Namecoin forum also.
http://dot-bit.org/forum/index.php

Please move detailed discussion about BitMask etc. to another thread.

Hey Tommy, thanks for the replies!

I guess I am still a little concerned about the scalability issue. Despite the advertisements being quite small, I see this quickly becoming a bottleneck in similar way to the problems caused by the receive-it-all approach of BitMessage.  

What I have understood is that these advertisement packets will actually be flooded across the network (?) which is pretty expensive, and as the network size grows, the cost will increase non-linearly.

So I feel that you may need to find some way of partitioning the network in order to keep in manageable.

---
Anyway, allow me digress and detail a few of my motivations so we can see if there is some common ground for a potential collaboration

Basically I have a few projects in mind that depend on a layer one could call 'anonymous-message-passing'. The functional requirements being as follows:

• Alice can send a private message to Bob
• Alice can send a public message to the world (publishing model)
• Bob may be offline and can 'check for messages' by connecting to the network. His 'inbox' is stored by the network.
• Anyone can read any message. Private messages are kept private with cryptography.
• Messages are sent reliably, Alice should not need to receive an ACK, in the same way that I do not expect an ACK from gmail

Some of the key non functionals:

• Perfect forward secrecy
• inability for someone other than the person concerned to be able to relate a network identity(pub key) with the real world identity (an IP)

I believe that if this is done well, with a combination of a good technical solution with the appropriate incentive structures for participants, this could become a very useful tool.

I think this could go far beyond just having an alternative to email. When you consider that the endpoints of a communication could be API servers, HTML5 web-apps etc, there is a ton of things this could be useful for.

One example is that this could help remove reliance on Tor/I2p, since the anonymity is taken care of. Silk-road could be re-implemented as an open source browser extension for example!

So your work is a fine start to all of this. Please keep me updated with your progress on your paper and simulations etc and I will surely bother you soon with some more questions.

In the meantime, here is one:

Why not use an anonymous-PUT, anonymous-GET DHT as a basis? I just found a paper on a DHT which aims to do just that http://arxiv.org/pdf/1203.2668v1.pdf and of course we should not forget Freenet which was designed for this very purpose.

Could a messaging system not be implemented as a thin-layer over the top of 'Octopus' / Freenet / I2P ?

Also, glad to hear you're interested in helping!  Let's chat about working on the simulator; I'll finish putting together some of my thoughts regarding the design and then shoot them over to you so you can take a look at them

I'm looking to put together some sort of startup to facilitate the development of the protocol as well as future applications (ie: separate e-mail clients, IM, Twitter like interface, all sorts of fun stuff).  The goal is to get this simulator proof of concept going and start moving in the direction of a business plan

Cheers,
Tommy

Hey greBit,

First off, really good questions; I left out a few of my thoughts from the paper, and you managed to hit a good portion of them!  Thanks for taking the time to read my paper!

For offline use, one could use a storage peer and query all messages in a large address range to preserve anonymity, but as you mentioned, that wouldn't be possible for low-bandwidth users.  One of the things I sort of glossed over in my paper that is important to offline use is the fact that instead of using special acknowledgement messages like Bitmessage, a peer can simply send another message back with an additional ephemeral key to let a peer know that he received his message.  In other words, acknowledgment messages are sent in the form of regular messages.

With this in mind, I think the easiest way of approaching offline use would be the following scenario:

1) Alice sends a message to Bob, who is currently offline

2) After waiting a certain amount of time, Alice never receives a message from Bob acknowledging that he received the message

3) Alice then sends a permission packet to Bob to restart the conversation with a new ephemeral key, and then resend the previously missed message.  One probably doesn't need to go through the whole permission packet process though, seeing as the one-time/ephemeral address concept I use is really only to mask bias in downloading messages (ie: the origin of broadcast for permission and ad packets is anonymized assuming the min spanning tree assumption)

4) Alice can continually resend permission packets every so often until Bob is back online

And yes, users need to be online to answer permission packets.  No reply means the user if offline.  Permission requests should be re-sent randomly, to preserve anonymity (ie: not have a constant amount of time hardcoded in the client)


Attackers making lots of connections is a subset of an area I'm still thinking about, that area being how to best bootstrap the network and how to handle conencting to new peers.  If a peer could gurantee that he is connected to every peer in the network, or even a large subset, he could theoretically start to aproximate network topologies and reduce anonymity depending on how peers are choosing to broadcast ads and permission packets.

To experiment and to try and find out best practices for maximizing anonymity in proportion to the amount of users in the network,  my next step is to create a visual simulator to aproximate network flow and p2p interactions.  This will be used as a proof of concept to estimate the anonymity of users given different topologies, as well as show how the network can react and defend against attempted attacks.  If this goes well, I'll then start client development.

As far as global packets and scalability, that is going to come down to coming up with clever ways of compressing address data, which is on my list of things to think about.  Another thought I had regarding this was to allow messages to be tagged as belonging to a certain category, such as e-mail, files, or twitter-esque service messgae, and then let peers decide what categories/services they want to participate in and relay (ie: think of this as a multiplexing different bitmask networks into one client)

For your behavioral contract question, the beauty of ads is that by relaying an ad to another peer and making them aware of the message's presence, you are simply letting them know that you are serving as a contact for obtaining this message; you don't necessarily have the message cached when you go to pass on the ad.  That way, you only ever checkup on a peer after they have requested a message from you and have received it, meaning you always know which files they should have from you.

When a peer disconnects, new contracts/agreements must be made.  If a peer disconnects too frequently, the peers he was connected to will blacklist him.

With regards to blacklisting, I had only thought of it as being an individual list per peer when I originally wrote the paper.  I'm not sure yet if network knowledge can be done in a trustless manner, as I'm still exploring that.  One idea I had was that you could allocate weight/trust to a node everytime he successfully transfers a message that belongs to you, but it would need to be done in a way that doesn't create an attack vector for discovering which messages you're interested in.

Thanks again, and keep those questions coming

I forgot an obvious question topic ... the blacklists

Is the blacklist individual per node, or is this to become 'network knowledge'?

• For the latter, how do nodes achieve consensus on the contents of the list?
• For the former, could attackers not just find new peers to connect to if they become blacklisted. Since it may be tricky to determine quickly if a peer is malicious or not, the attacker may have a bit of time in which to perform some attack before being banned.

I really like these ideas, especially the use of ephemeral addresses to achieve anonymity and perfect forward secrecy. If you are looking for volunteer developers to help get a proof of concept off the ground I would likely be pretty keen.

I do however have a few questions ...

Offline use

Im a little concerned about the offline-use-case. I understand that advertisement packets have a limited lifespan (any idea how long?), so if I shutdown my machine for the weekend only to reconnect the following monday, it is possible that I miss advertisements meant for me. This means I would need to interrogate a 'storage node' at the cost of giving up valuable information that may help an attacker link an address with my real identity.

For an email replacement, the offline-use-case would be quite common, peers would come and go rather fleetingly. But perhaps this is not your target market, and one of your assumptions is that people will generally stay regularly connected.

Attacker makes lots of connections, analyses origin of permission packet

Thankfully you have included link-layer-encryption, so assuming that the crypto is good, it makes it harder for a global passive adversary. Am I right in assuming that any attacker trying to make large numbers of connections in order to perform statistical analysis on say the origins of a permission packet, would be very quickly blacklisted? i.e. due to the attacker needing to honour a bandwidth/storage 'contract' with each peer he connects with?

What about well funded attackers?

Global packets and scalability


So here I get a little worried. "a peer must continually relay all ad packets within the network".

Say we have a network with 1 Billion peers who are all actively sending messages. For each message that is sent, we require numerous advertisement packets to be broadcast on the network. Depending on the lifetime and regularity at which advertisements are resent, the number of global packets that need to be move across each peer-peer link will be huuuge.

If I have interpreted this correctly, how can the network scale and how can low-bandwidth/low-storage nodes participate?

Getting permission to communicate, both parties need to be online?

Do Alice and Bob need to be simultaneously online for Alice's permission packet to reach Bob and for its response to come back to Alice? Or are permission packets also referenced by advertisements in a similar way to messages?

Enforcing behavioural contracts

I like your idea of making sure that nodes behave correctly and continue to store messages they have agreed to store etc.

I am wondering though, do peers need to be exact mirrors of each other? How can Alice check that Bob still stores messages for which Alice does not store herself?

What happens when Alice becomes disconnected from the network, and reconnects to a different set of peers? How do the new peers enforce her (preexisting storage contract) ? Or will she agree to a new contract when she makes the new connections?


Sorry to overload you with questions, im just trying to understand your proposal a little better

We were already planning on introducing some of your ideas as part of Project Quixote and really like some of your innovations and would like to include more of them.

If you would like to join our team and help develop your ideas as part of Project Quixote, please contact me via PM.

Keep up the innovation!

sorry i just dont trust pdfs. thanks much.

Bitmask: A Perfectly Anonymous, Naturally Scalable Peer-to-Peer Messaging System

Tommy Anderson
tommy [email protected]
www.bitmask.me

v0.1.0 - September 6, 2013

Abstract. We propose a trustless peer-to-peer messaging system that allows peers to securely send and receive anonymous, plausibly deniable messages, without exposing one’s true identity. Through the combined defensive efforts of a minimum spanning tree of non- malicious peers, the system is shown to be resilient to attempts made by malicious peers to disrupt both the activity and anonymity of the system. Additionally, peers are responsible for self-regulating and maintaining the health of the system, in a way that is both scalable and fair to all peers.

1 Introduction
Peer-to-peer (P2P) messaging as it currently exists lacks a proper trustless solution that is both anonymous and scalable. A system known as Bitmessage attempts to be such a solution, however its approach to anonymizing the identity and activities of peers prevents the system from achieving the scalability needed for mainstream adoption. This section will analyze the shortcomings of Bitmessage, as well as introduce a new solution titled Bitmask.

1.1 Bitmessage
The private information retrieval (PIR) approach that Bitmessage takes to anonymize the activities of peers is to have each peer download and forward every message within the system’s network. This is done to obfuscate both the addresses that belong to the peer and those that the peer is in communication with. Bandwidth limitations render such a system impractical for use on a mobile device. More generally speaking, usage is limited strictly to those who are willing to store and transfer large amounts of data over a given period of time.

Bitmessage attempts to scale by allowing peers to split up into separate bandwidth partitions of the network known as streams. Streams however limit a peer’s anonymity to a function of how many peers are in a specific stream, rather than the entire network.

Additionally, it has been shown that various timing attacks exist that can be used to break anonymity. These timing attacks result from the exploitation of Bitmessage network protocol packets known as acknowledgment messages. Lack of link layer encryption also makes it possible for anonymity to be broken by internet service providers (ISPs).

1.2 Bitmask
To remedy these shortcomings and provide a system that is both scalable and anonymous, a new system titled Bitmask is proposed with the following features. These feature descriptions give a high level overview of the system, and will be explained in greater detail within the sections to follow.

Note: symmetric-key encryption, the usage of public and private keys to sign and encrypt messages, is used in a manner similar to Bitmessage, including the concept of addresses to shorten public keys.

1.2.1 Perfect Forward Secrecy
Instead of always sending encrypted messages to the same address for a particular contact, a peer will generate a new public/private key pair before sending a new message, and include the new public key at the end of the message. The one-time address associated with this public key is known as an ephemeral address; an address to be used more than once is known as non-ephemeral. When the recipient reads this message, it will know which new ephemeral address the sender is listening on for a reply, and send a reply accordingly. If the most recent private key for one of the two peers communicating is ever compromised, all previous messages in the conversation are safe as long as the previous private keys were discarded, thus achieving perfect forward secrecy.

1.2.2 Plausible Deniability
By including one’s ephemeral private key at the end of every encrypted message and then discarding that private key, one can deny having written a message if accused outside of the network by the recipient. This is because the recipient had the means to forge the message by possessing the private key at the end. Because all peers never use the same address twice, there is no need for identity-theft concern when releasing the private key, as there is no identity to protect.

1.2.3 Link Layer Encryption
By using transport layer security (TLS) to communicate with and send packets over the network to peers, link layer encryption will be provided, and ISPs will be unable to read the contents of packets.

1.2.4 Advertisement Packets
To preserve the anonymity that comes with Bitmessage’s PIR scheme of everyone gets every- thing without actually forwarding and receiving every message, advertisement (ad) packets are used. All messages are advertised to the network as a special ad packet before ever being transferred between peers. This ad packet contains the recipient address of the message being advertised, as well as the time of expiration for how long the peer passing along this ad is willing to respond to requests from other peers to send them the message.

1.2.5 Randomized Caching
Instead of using streams and Bitmessage’s PIR scheme of everyone gets everything, Bitmask uses a concept called random caching. After learning from ad packets what messages are available to download from peers, a peer will randomly and regularly ask to download cer- tain messages from certain peers. The peer will then cache these messages for an agreed upon amount of time, and transfer them to other peers if requested. The peer’s activity is obfuscated by the fact that no peer can tell which messages are of interest to the peer, and the fact that messages sent by the peer are introduced into the network as an ad whose origin of broadcast is undetermined.

1.2.6 Bandwidth for Anti-Flood
Bandwidth metrics are used for protecting the network against flood attacks, instead of Bitmessage’s CPU based proof of work (POW). Natural bounds on system growth are de- fined by self-verifiable and trustless rules between peers, such as bandwidth agreements and statistically allowable thresholds for message transfer and dropping. Malicious peers must follow these rules or risk being dropped by the non-malicious peers who have set them. As a result, malicious peers can only flood in proportion to how much network traffic they are facilitating, which in effect helps the network by adding additional noise.

1.2.7 Permission Packets
In order to prevent spam, all ad packets for messages contain the recipient address instead of the public key. Thus, special permission packets are needed to obtain a public key for non-ephemeral addresses shared outside of the network, in order to initiate a conversation and start sharing ephemeral public keys. Such a permission packet includes the recipient’s address as well as an ephemeral public key for the sender. The recipient can then reply to that public key with its own ephemeral address as an encrypted message (signed by the address requested in the permission packet in order to prevent false/spammed replys), thus allowing the permission requester to then send its first message.

1.2.8 Trustless Identity
In order to prevent attempts to spam permission packets by altering an original packet and rebroadcasting it with a new ephemeral public key, the first message that gets sent after permission has been granted must be a special identity profile message. The peer who is responding to the request can then read and subsequently decide whether or not to initiate a conversation with whoever the sender claims to be (ie: take an accept or reject type of action).

Note: this identity is a claim, it doesn’t guarantee the peer is who he says he is

1.2.9 Low-Bandwidth Accessibility
Peers such as those on mobile phones can request to only receive ad packets that advertise the availability of messages being sent to a specified range of addresses. As long as these peers provide some constant amount of bandwidth to frequently send and receive messages, anonymity is preserved.

2 P2P Systems
P2P based systems like Bitmask and Bitmessage are made up of a decentralized and dis- tributed network of peers. Such peers take on both the role of consumer and producer, each providing some portion of individual resources to the network. Bitmask is designed to be a trustless P2P system, in which network protocol never dictates the trusting of peers to achieve proper functionality. For example, making the assumption that peers are caching all messages transferred to them without some form of verification or accountability would fail to result in a network that is trustless.

2.1 Minimum Spanning Tree of Trust
The only assumption that Bitmask makes with regards to the trusting of peers, is the as- sumption that a minimum spanning tree of non-malicious peers is present within the network. In other words, each peer must be connected to at least one non-malicious peer. If a peer sends messages out over time and never receives a response, he is only connected to mali- cious peers and the assumption is broken. As such, we can philosophically guarantee the validity of this assumption in the sense that the system is only useful if peers can use it to communicate with each other. Thus, as long as peers find Bitmask to be useful, the trustless nature of the system is preserved.

This assumption in combination with various methods of verification will be used to detect the presence of malicious peers within the network, as described in the sections to follow. Non-malicious peers will work together to set mutually-beneficial terms, but at the same time constantly verify the actions of each other in a trustless manner, in order to maintain the functionality of the network.

3 System Components
Central to the use of Bitmask is the usage of addresses for initiating and carrying out communication, in addition to two types of network packets; global packets for broadcasting to every peer within the network, and local packets for cooperating with specific peers.

3.1 Addresses
All addresses are of a form similar to the base 58 encoded addresses used by Bitmessage and the crypto-currency Bitcoin, in order to compress a peer’s public key and make it more user- friendly with regards to copying and pasting. Additionally, addresses help prevent spam by hashing the associated public key and preventing network observers from being able to scrape an ad packet and send an encrypted spam message to that public key. The checksum length is chosen to be the same as for Bitmessage. As a side-note, the shorter this checksum is, the greater the probability that collisions are possible when getting a response to a permission packet (ie: getting two responses back that are signed by different public keys that hash to the same address, which can be interpreted as two public keys claiming responsibility for the same permission packet).

3.2 Global Packets
The following types of packets are relayed from peer to peer until they’ve traversed the entire network.

3.2.1 Permission Request
This packet is needed for getting the public key of a non-ephemeral address and for subse- quently starting a conversation, as previously described.

3.2.2 Advertisement
This packet is needed to introduce the availability of a message within the network. When relaying this packet to another peer, both peers must agree on a time of expiration for how long the receiving peer is willing to answer requests from other peers to transfer the message being advertised. Determination of this time will be discussed in the section to come on network behavior.

3.2.3 Message
This packet contains encrypted content, such as an acknowledgment for receiving a previous message, a trustless identity profile message following a successful permission request, or a plain text message. It is sent when a peer requests it from another peer, sometime between the moment the receiving peer learns of the message’s presence from an advertisement packet, and the time of expiration for that advertisement.

3.3 Local Packets
The following types of packets are used for communication between two peers.

3.3.1 Bandwidth Agreement
Upon establishing a connection, two peers use this packet to enter into an agreement to provide an amount of message storage space for each other. The peer that offers the lower of the two amounts determines the amount agreed to.

3.3.2 Message Request
A vector of messages are requested in each packet of this type, based on which messages are available for request from the peer in question. Included in this request is the proposed time of storage for each message that a peer is requesting, so that the peer sending the files knows the duration of time that he has to spend verifying that the peer is caching the messages as promised. The sending peer will then begin to transfer the requested messages, either immediately if it currently has a message cached, or with a delay if the peer needs to request a message from one of its peers.

To determine how much time a peer will offer to store a message from another peer, a function with an input of the current amount of unused bandwidth minus the size of the file in question will be used (ie: how much space will remain after caching this message). This function will be exponential, where the smaller the amount of currently available space there is, the shorter a peer will be willing to hold on to messages. This curve will be adjusted depending on network activity, for example making it steeper in the presence of high traffic.

3.3.3 Checkup
Upon establishing a connection, two peers use this packet to enter into an agreement to checkup on each other over a regular interval of time, in order to verify that both peers are holding messages for as long as they promised to. In order to prove that caching is occurring, a random nonce is sent by one peer to the other. The receiving peer then computes and returns a checksum for each file plus this nonce, to prove that each file is currently stored.

Failure to respond within an adequate amount of time or to provide the correct answer results in the blacklisting of that peer. Each checkup packet will contain a list of files that in combination have a large total file size, to guarantee that the peer isn’t simply re-downloading the files from other peers.

3.3.4 Message Query
This packet is used to check if a peer is currently storing any messages for specific addresses, and if so, to transfer them. It sacrifices anonymity, but is useful for querying peers that are serving as storage services by keeping messages cached after their ads expires, for an addi- tional amount of time. Anonymity can be preserved by querying a large range of addresses. This packet should only be used by peers who have been offline and are reconnecting to the network.

4 Network Behavior
The following is an overview of interactions between peers.

4.1 Reciprocal Bandwidth
Because of the minimum spanning tree assumption, a peer must continually relay all ad packets within the network or risk being classified as a malicious peer, because all ads will eventually make their way through the minimum spanning tree to the recipient peer. So if a peer receives an ad for a message that it’s the recipient of but never receives the same ad from peers attempting to drop ad packets, those malicious peers can be detected and blacklisted.

Therefore peers must use their bandwidth for the good of the network, in addition to any “junk” (ie: messages to addresses not owned by any peer) they might want to introduce. The more bandwidth that a peer agrees to, the greater the chance that other peers will randomly cache files that the peer is attempting to send, because these peers will be requesting messages faster. Additionally, the more that peers cache messages, the quicker those messages will get to the intended recipient; it’s to every peer’s benefit to create a strong network pipeline.

If a peer is offline when a message is sent, that peer must attempt to query the message from a storage peer. Otherwise, the only other way to retrieve the message is to wait for the sender to either to resend the message, or to send a new permission packet to restart the conversation on a new ephemeral address.

4.2 Reciprocal Advertising
Peers must agree every so often on a constant time to advertise each others ads, because any messages a peer would try to send will then be reciprocally advertised for an equal amount of time. When a peer advertises a message to another peer, the recieving peer agrees to an expiration time no greater than the time of expiration the advertising peer previously agreed to for the same ad, and no more than the constant time they’re currently in agreement on. Thus, the longer a peer is willing to advertise messages, the longer its messages can be advertised within the network.

If a peer frequently fails to obtain and/or send a message after having been requested to do so, that peer can be blacklisted. The fact that a peer may no longer have access to a file due to advertisement expirations or disconnects in its path to obtain the file will be taken into account when determining such a threshold for blacklisting.

5 Anonymity
The following are various thoughts regarding the anonymity of Bitmask.

• Random caching based PIR and ephemeral addresses keeps interests masked; peers appear to simply be facilitating traffic
• By waiting a random amount of time before responding to permission requests, peers will be unable to detect if a non-ephemeral address belongs to a certain peer
• Unless completely connected to malicious peers (which would violate the minimum spanning tree assumption), no peer can prove the origin of an ad
• Because every message has a mutually agreed upon time of expiration based on ads, messages that are cached will be deleted upon expiration so that peers can’t abuse query requests to see if another peer is holding messages longer than they should be, thus giving away that the peer has interest in it (either sent or read it); deletion can be turned off if serving as a storage peer
• Link layer encryption protects against ISP’s from figuring out which ads originate from certain peers
• Message size increments and padding are not needed due to regular bandwidth fre- quency (ie: constantly pushing and pulling a set amount of data)

6 Spam
Public keys are never directly broadcasted within the network, so no peer can encrypt and send spam messages. The only possibility for spam is with regards to permission packets. Having a trustless identity profile message be the first message after permission has been granted gives a peer the means to accept or reject starting a conversation with the requesting peer. The more fields this profile has, the harder it will be for spam peers to generate a meaningful profile that a Bitmask client can choose to mark as spam, and flat out reject the conversation. A client can also allow users to whitelist certain addresses, and ignore permission requests signed by any other addresses.

7 Flooding
Because of the minimum spanning tree assumption, malicious peers must facilitate all normal traffic or risk being caught dropping messages, and blacklisted as a result. Thus a malicious node must support the current network, in addition to any packets it wishes to introduce. As a result of all peers establishing bandwidth requirements amongst themselves, they naturally limit how much data a malicious peer can push into the network, which in the end will only help peers gain more anonymity from each other. Additionally, peers will agree amongst themselves to have bandwidth caps for ad and permission packets to protect against network flood.

i want to read it but not bad enough to open a pdf. can you just post the text on the forum?

Based on what I've learned from the discussions on the Bitmessage forum, in addition to my own independent analysis, I've put together what I think is the next step towards a perfectly anonymous, naturally scalable P2P messaging system.  Please see https://bitmessage.org/forum/index.php/topic,3259.0.html for a brief whitepaper I've put together detailing my thoughts towards such a system, titled Bitmask.

Bitmask is a system centered around using Bandwidth metrics for anti-flood, in a way that is trustless, scalable and doesn't arbitrarily limit growth, and uses a concept I call random caching as a means for PIR.  While this document is mostly high-level and doesn't go into any technical discussions, I'm currently working on a tech spec and plan to release it within the near-future.

When people feel that current system resource usage is getting too high. There is no clear defined line as I'm not even sure what the bottleneck will be (bandwidth? Disk IO? CPU? Memory?).

I would discourage the use of the word "channel" because it's vague and conflicts with "chan," or "shared address," a decentralized multiparty communication method.

Proof of work acts as a limiter on the ability of someone to send any type of message, period. This includes under-the-hood messages like pubkey messages.

It serves to deter FLOODING. Spam should be handled client-side, for example by using Thunderbird.

By making it more expensive to send a message, it acts as a way to reduce the number of messages sent over a channel over the p2p network, reducing the bandwidth+storage costs of each node and protecting the network from flooding-based DoS attacks.

One could have different POW requirements for each channel mailing list, address, or stream.

---

When the devs decide on how best to implement streams, then implement them. See stream discussion index.

Question about streams, there's only 1 now. When are more added?

I have been recently having a look through Bitmessage and would like to gain a greater understanding about why certain choices, e.g. Streams,  were made etc.

So this is my understanding of the use of Streams & POW in Bitmessage. Please correct me if I am wrong...

[POW]

Proof of work acts as a limiter on the ability of someone to post a message over a broadcast channel.

• It serves to deter SPAM.
• By making it more expensive to send a message, it acts as a way to reduce the number of messages sent over a channel, reducing the bandwidth+storage costs of each node.

The POW difficulty need not be static but could adapt dynamically in an effort to constrain the bandwidth + storage requirements of each node to some fixed level

• One could have different POW requirements for each channel

[STREAMS]

If there were no Streams, we would be left with a best-effort broadcast channel.

• This would force each node to be responsible for the relaying and storage of a huge number of messages.
• Or the POW difficulty would be so high as to render the system useless
• It would not scale.

So we partition the network into a number of Streams, where each Stream is a best-effort broadcast channel.

• Each identity is assigned to one stream (it is fixed in the BM address).
• Some streams may be more active than others, node requirements(bandwidth/storage) will vary.

Partitioning is an effort to even out the network load.

• The only opportunity to do this load balancing and create a new partition is when a user wants to create an identity (BM address)
• If the current stream is deemed 'too busy', the identity will be created on a brand new stream

Once a stream is established, there is nothing the network can do to make itself more efficient and more evenly distribute the load on the nodes.

• It must resort to making it more difficult to post messages, by increasing POW difficulty
• This will likely not be in the user's interest

At my current level of understanding, it seems to me that Streams are quite a rigid mechanism. I see two problems:

• Once a stream is established, it cannot be re-partitioned because each identity is directly linked to a particular stream
• There is a trade-off between cost_to_run_a_node and level of anonymity. If a stream is quiet, the node's own messages will be less well hidden than if a stream was really chatty. In the current system, the user is less empowered to make a choice based on his own individual needs.

Thoughts ...?

Hi, I have just sent you a message through bitmessage from my public address BM-2DAYSTvtMp5ADZzSxKYZsRGBqkxubAAjt9.

It's either that or more centralization. Maybe it would be possible to figure out some voting system to agree on donation addresses.

But for a start I would use the three suggested addresses (atheros, bitcoin100, bitcoineater) and let the user decide between them. It would also help funding the project.

Also:

first assent would be proud of the way you used the word force in this sentence