![]() The prefix value of each Bitmessage address is the first 64 bits of the ripe hash encoded within the address. This will result in the client needing to download roughly 9,700 objects per day in order to be sure of receiving all objects destined for it. For example, if the total network object traffic is 10,000,000 objects per day and the the owner of the new address wants a balance between anonymity and efficiency that equates to an anonymity set of roughly 10,000 objects per day then the client will select a prefix length value of 10 for the address. When a Bitmessage address is created, the client creating the address selects a prefix length value that will result in a balance between anonymity and efficiency that best suits the end user who owns that address. Over time, the node can change its stream number in order to keep processing as much object traffic as it can. For example, if a node is capable of processing up to 100,000 objects per day and the total network object traffic is 10,000,000 objects per day then the node would select a prefix length value of 7, which would result in it having to process roughly 78,000 objects per day. Rather than having one stream to start with and gradually increasing or decreasing the number of streams as the network grows or shrinks, this system makes 18 quintillion possible 'streams' (prefix values) available immediately.Įach node in the network handles a certain proportion of the total network traffic, with the size of that proportion determined according to the node's capability. ![]() The purpose of the prefix filtering system is to provide a mechanism for determining how Bitmessage objects should be routed. For example, instead the network having to create or abandon streams as the total network traffic level changes, nodes simply adjust their position in a pre-determined hierarchy of streams, moving either 'up' or 'down' the hierarchy. In general the problems shared by most stream systems are simplified. This proposal outlines a method for implementing streams that avoids or reduces many of the difficulties with previous stream proposals. Requires a lot of thought and processes to effectively hide receiving a message.The same as the first method except only some messages are saved (once the network grows beyond a certain point).There are problems with binding addresses to one stream, and there are problems with not binding addresses to streams.Still potential for lots of bandwidth/disk space/processing usage.Take the above and split it into pieces.Massive bandwidth and disk space and processing usage, eventually becomes completely unsustainable.There are three basic possible approaches to making Bitmessage scalable (credit to Dokument for this summary): Objects propagate in the stream that matches their prefix nonce and all higher streams of the same branch.Nodes process objects in their own stream and all lower streams of the same branch.This value determines which streams the object will propagate in. Each Bitmessage object has a prefix nonce. ![]() Nodes maintain long-lived connections to nodes in their own stream and streams that are 'nearby' in the stream hierarchy, but also temporarily connect directly to nodes in any stream when necessary.As the network grows or shrinks, nodes also 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.Groups of nodes form overlapping 'streams' based on their prefix values.These values determine what part and what proportion of the total network traffic the node will handle. Each node in the Bitmessage network also 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'.Suggestions and contributions are welcome. NOTE: This proposal is not yet complete, as some aspects of proposed system are not yet resolved (see ). This page describes a proposal for a way to make Bitmessage scalable. 7.2 Rules for addresses moving between streams.7.1 Rules for nodes moving between streams.5.4 Retrieving messages from the network.5.1 Creating a Bitmessage address and pubkey.4.7 How do objects travel through the network / How do nodes connect to each other?.3.1 Nothing (or everyone gets everything).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |