![]() However, this trade-off delivers a substantial benefit in allowing mobile phones and other lite clients a viable part of Bitmessage. Tagging messages in this way is clearly a trade-off in terms of security, as it reveals some extra information, albeit obfuscated information, about the message's destination. This identification of messages sent to lite clients can be accomplished by introducing a 'tag' to Bitmessage messages which is derived from the destination address. As described above however, the work required for this approach is too great for many devices, and therefore there must be some way for lite clients to identify which messages are destined for them, so that they can request those messages from a server. Full nodes in Bitmessage do not require this because they receive and automatically attempt to decrypt all messages in the streams (segments of the network) which they are a part of. In order for 'lite' clients such as mobile phones to receive messages, there needs to be some way for them to identify messages that have been sent to their addresses. However, this arrangement does require one significant compromise. Data provided by servers can be cryptographically authenticated as being correct, and data sent to servers can be disseminated to several at once to ensure that it reaches the rest of the network. All message encryption and decryption can be done locally by the lite client, and it can retain sole control over its addresses and cryptographic keys. Thankfully the design of Bitmessage allows this to be implemented in such a way that very little security is lost. ![]() Instead, the burden of this work is shifted to servers, which supply lite clients with the data they need and relay data sent by lite clients to the rest of the Bitmessage network. These are Bitmessage clients which do not do all the processing and transmission work that full nodes do. One approach to solving this problem is the creation of 'lite' clients. Therefore, in order for the users of these devices to be able to use Bitmessage, there must be some way of doing so that does not involve their device acting as a full node in the network. Because of this, a high proportion of the computing devices in use today are not suitable to act as full nodes in the Bitmessage peer-to-peer network. This is particularly true in cases where mobile internet connections mean that bandwidth is very expensive. This workload may be manageable for more powerful devices, such as laptops, desktops, and servers, but it is typically too great for less powerful devices such as mobile phones and tablets to reasonably handle. This involves transmitting, receiving, and processing a large amount of data. A lite client can signal that messages to its addresses should be tagged by setting a flag in the behavior bitfield of each of its address's pubkeys.Ĭurrently, Bitmessage clients such as PyBitmessage act as full nodes in the Bitmessage peer-to-peer network.Otherwise the tag field is filled with random data. Message tagging is only necessary when sending messages to 'lite' clients.The time component of the tag is 00:00 on the current day in Unix time.This tag allows 'lite' clients, such as mobile phones, to receive messages sent to them without downloading and processing large amounts of data.Bitmessage messages can be 'tagged' with a hash derived from the message's destination address and a time value.This page describes the changes proposed and the reasoning behind them. This is a draft proposal to allow Bitmessage messages to be 'tagged' so they can be received by 'lite' clients, such as mobile phones.
0 Comments
Leave a Reply. |