Difference between revisions of "Scalability through Prefix Filtering"

From Bitmessage Wiki
Jump to navigation Jump to search
(Added summary of scalability possibilities)
(Added more content)
Line 10: Line 10:
 
* Each Bitmessage address has a 'prefix' and a 'prefix length'. These values determine the balance between anonymity and efficiency that the owner of the address will have when retrieving messages from the network.  
 
* Each Bitmessage address has a 'prefix' and a 'prefix length'. These values determine the balance between anonymity and efficiency that the owner of the address will have when retrieving messages from the network.  
 
* Each node in the Bitmessage network has a 'prefix' and a 'prefix length'. These values determine what part and what proportion of the total network traffic the node will handle.
 
* Each node in the Bitmessage network has a 'prefix' and a 'prefix length'. These values determine what part and what proportion of the total network traffic the node will handle.
* Groups of nodes form overlapping 'streams' based on their prefix values. As the network grows or shrinks, nodes change their stream in order to handle a smaller or greater proportion of the network objet traffic.
+
* Groups of nodes form overlapping 'streams' based on their prefix values.  
 +
* As the network grows or shrinks, nodes move to a higher or lower stream in order to handle a greater or smaller proportion of the network object traffic.
 +
* As the network grows or shrinks, addresses move to a higher or lower stream in order to maintain the balance between anonymity and efficiency desired by the address's owner.  
 
* Nodes maintain long-lived connections to nodes in their own stream and 'nearby' streams that are 'nearby' in the stream hierarchy, but also temporarily connect directly to nodes in any stream when necessary.
 
* Nodes maintain long-lived connections to nodes in their own stream and 'nearby' streams that are 'nearby' in the stream hierarchy, but also temporarily connect directly to nodes in any stream when necessary.
* XXX
+
* Each Bitmessage object has a prefix nonce. This value determines the object's destination stream.
 +
* Objects propagate in their destination stream and lower streams of the same branch.
 +
* Nodes process objects in their own stream and lower streams of the same branch.
  
  

Revision as of 15:05, 2 February 2015

Introduction

This page describes a proposal for a way to make Bitmessage scalable.

NOTE: This proposal is not yet complete, as some aspects of proposed system are not yet resolved. Suggestions and contributions are welcome.

Summary of the proposal

  • Each Bitmessage address has a 'prefix' and a 'prefix length'. These values determine the balance between anonymity and efficiency that the owner of the address will have when retrieving messages from the network.
  • Each node in the Bitmessage network has a 'prefix' and a 'prefix length'. These values determine what part and what proportion of the total network traffic the node will handle.
  • Groups of nodes form overlapping 'streams' based on their prefix values.
  • As the network grows or shrinks, nodes move to a higher or lower stream in order to handle a greater or smaller proportion of the network object traffic.
  • As the network grows or shrinks, addresses move to a higher or lower stream in order to maintain the balance between anonymity and efficiency desired by the address's owner.
  • Nodes maintain long-lived connections to nodes in their own stream and 'nearby' streams that are 'nearby' in the stream hierarchy, but also temporarily connect directly to nodes in any stream when necessary.
  • Each Bitmessage object has a prefix nonce. This value determines the object's destination stream.
  • Objects propagate in their destination stream and lower streams of the same branch.
  • Nodes process objects in their own stream and lower streams of the same branch.


Reasoning behind the proposal

There are three basic possible approaches to making Bitmessage scalable (credit to Dokument for this summary):

Nothing (or everyone gets everything) - Everyone user gets every message. - Massive bandwidth and disk space and processing usage, eventually becomes completely unsustainable. - Most private.

Streams - Take the above and split it into pieces. - Still potential for lots of bandwidth/disk space/processing usage. - There are problems with binding addresses to one stream, and there are problems with not binding addresses to streams. Both sets affect privacy.

Scaling without streams - The same as the first method except only some messages are saved (once the network grows beyond a certain point). - Requires two part messages. - Requires a lot of thought and processes to effectively hide receiving a message.

This proposal outlines a method for implementing streams that avoids or reduces many of the difficulties with previous stream proposals.

Proposed changes

XXX

Prefix Filter Streams Hierarchy.png

XXX

Node Connections Diagram.png


Examples

Example 1

XXX

Example 2

XXX

Example 3

XXX


Notes

XXX

XXX

XXX

XXX

XXX

XXX

Idea: POW variable by prefix specificity

Since


Unresolved Questions

Rules for nodes moving between streams

As the overall size of the network changes, nodes will need to adjust the proportion of the network traffic that they handle. This will require moving between streams. How should this be done?

Rules for addresses moving between streams

As the overall size of the network changes, addresses will need to move between streams in order to preserve the balance between anonymity and efficiency that their owner has selected. How should this be done?