I'm not sure where you got this idea, but it's not correct. Every message sent through Bitmessage is strongly encrypted. See https://bitmessage.org/wiki/Encryption.
If your message is a normal person-to-person message (not a broadcast or message to a mailing list) then only the person who owns the destination address can decrypt and read the message. Broadcasts and messages to mailing lists can only be decrypted by people subscribed to the broadcast or mailing list address.
I think the thread at this link answers your question: https://bitmessage.org/forum/index.php?topic=3884.0
>There are three mechanisms Bitmessage uses to learn of nodes.
1. about 10 are hardcoded. These are only used when you run the client the first time or when you delete your knownNodes.dat file.
2. DNS bootstrapping. On startup, Bitmessage looks up the DNS A-records for bootstrap8080.bitmessage.org and bootstrap8444.bitmessage.org and adds those to its list. This is very much like method #1 except that I don't have to update the source code to update the list of peers.
3. After the client is connected to another peer, peers share nodes using addr messages. This is continuously updated. At this point the first two methods really aren't important at all; the knownNodes list will grow plenty big using this third method. (Max 20K peers in the list).
If your client doesn't hear that a peer is active and cannot connect to it for two days then it removes it from the list until you have less than 1000 peers in your list at which point it stops removing them.
Your concerns are valid, but I don't think the situation is as bad as it may seem. To address the points you've raised:
Bitmessage still isn't 100% reliable yet. However I use it pretty regularly and I've found it to be very reliable, so your mileage may vary. Try it out and see for yourself. (As a comparison, how reliable was Bitcoin 1.5 years into its development?)
You can read Atheros' explanation of his choice of job here: http://www.reddit.com/r/bitmessage/comments/29dzvl/bitmessage_has_not_been_reliable_need_help/cikmk43
Atheros has apparently been very busy recently, so development progress has been slow. However progress is being made, for example: https://bitmessage.org/forum/index.php?topic=4067.0. These changes should be a big step forward, particularly for reliability.
Bitmessage is a hugely ambitious project and it's going to take significant time and effort to get it to a point where it's as reliable as email, a 40 year old technology. If people are willing to contribute then I think there's every chance it can succeed.
I don't remember a binary for Linux. There's an outdated unofficial PPA for Ubuntu and an AUR package for Arch Linux.
> Linux is for the average mom and pop now.
I would like to see a binary and package in the Debian/Ubuntu repository, too. But that requires work and effort by volunteers.
For anyone unaware, this update upgrades PyBitmessage to version 3 of the Bitmessage protocol:
https://bitmessage.org/wiki/Protocol_specification_v3
Anyone interested can find the discussion thread about Protocol Version 3 here:
https://bitmessage.org/forum/index.php?topic=4067.0
It's a really large update, with several important improvements to Bitmessage. Many thanks to Atheros and Thomas for all the work they've put into this.
This is something we're trying to work out at the moment.
See this thread for the recent discussion: https://bitmessage.org/forum/index.php?topic=4075.0
At the moment we have 3 proposals for how to do lite client message retrieval. See this link for a comparison:
https://docs.google.com/document/d/1b5q1SmZZQ_d-8I3kaBj3Kc2vWSNnPXVOqKgbduEqyTQ/edit?usp=sharing
If anyone has any suggestions or ideas to contribute they would be very gratefully received.
you can set a command to be executed when an event happens. Set this to something that plays an audio file. See the apinotifypath option in keys.dat.
Supply a script for example, which checks for the first parameter to be newMessage or newBroadcast and then perform an action
I'm not certain for user2user messages, but broadcasts and pubkey objects since recently contain a 'tag' which is hash of the broadcast address. This tag can then be compared instead of decrypting the entire message, but looking at the protocol spec I can't find it being used for regular user2user messages, so it seems that "decryption" must still be attempted for those.
In any case, the encryption is a combination of assymetric and symmetric cryptography (using ECIES), which means that the cpu intensive bit is the key derivation and attempting to validate the MAC (Message Authentication Code). This means that there technically is no decryption performed on unknown messages, and the processing time required is decoupled from the size of the message.
disclaimer: I am not a developer or contributor to the Bitmessage project. My knowledge comes from reading the whitepaper, the protocol spec and some of the client source.
That's interesting. Yesterday someone on the forum reported what sounds like the same problem, although they were using the 0.4.4 code (which is for the new protocol version).
I assume you're referring to how much bandwidth Bitseal uses. This is because at the moment there is no way for a Bitmessage client to select and download only the messages which are destined for one of its addresses, at least without compromising your anonymity.
Therefore in order to be sure of receiving messages sent to you, your client has to download all the messages in your stream (currently everyone is using stream 1). That is why Bitseal currently uses a lot of bandwidth.
In the long term this is clearly not viable for mobile and other 'lite' clients. Therefore we need a method for allowing Bitmessage clients to receive messages sent to them without downloading the whole stream's worth of messages while still maintaining a strong degree of their anonymity. I think we now have a good technique for doing this (prefix filters) but it is going to take some time to get it implemented. We're discussing it in this thread: https://bitmessage.org/forum/index.php?topic=4155.0
I hope that answers your question.
TLDR: Bitmessage needs a way of supporting 'lite' clients such as mobile phones. The Android client is ready to go once this is done, screenshots at www.imgur.com/a/xRGOq. I would like us to discuss and decide how we should do this.
Message Tagging Proposal wiki page: https://bitmessage.org/wiki/Message_Tagging_Proposal
Yes, it should be possible. You would have to change the hardcoded list of 'bootstrap' peers to ones that are active on the meshnet, but that shouldn't be too difficult.
For reference, this link might be helpful: https://bitmessage.org/forum/index.php?topic=3884.0
When not using Tor (Not TOR, see https://www.torproject.org/docs/faq.html.en#WhyCalledTor) BitMessage will use those automatically, by the way. Which is probably why defaultKnownNodes.py is a deal breaker for most (though it should definitely be fixed).
The library is now available as a NuGet package:
https://www.nuget.org/packages/niip-bitmessagelib/
Install using the Package Manager Console:
PM> Install-Package niip-bitmessagelib
They are both partially correct and partially incorrect. All objects, including messages, contain an unencrypted expiration time, which anyone can check, so that they know when to throw away the object from their storage. The client, when it successfully decrypts a message, will store the time it was decrypted, you'll see that in the "Received" column. Similarly, for sent messages, the current time is stored when the message is about to be sent (prior to PoW calculation) and this you see in the "Sent" column.
In the past, the objects did contain a creation time and the client had predefined expiration times for different types of objects. If you look at the protocol specification, there is a field expiresTime, and in the notes it says "be aware, in version 2 of the protocol this was the generation time".
So the creation time isn't visible either in the encrypted nor decrypted object, but you can make very rough guesses based on when you receive it, what the expiration time and the PoW is. But, in the past, the creation time was in the (unencrypted) object data, so it's more protected now.
Since the PoW is a monotonic function, there is no need to store the TTL in the object, only the expiration time.
> If I were to send a message to alice, what would happen if I was not online to receive the receipt for as many days as it persists in the network.
It expires and your client would send the message again, unless you decided that unanswered messages are forgotten in the app settings.
> Also could someone here explain to me exactly how the address is generated and verified. I read the white paper but it did not seem to give the best explanation.
Generate yoursel a public/private keypair and then do this: https://bitmessage.org/wiki/Public_key_to_bitmessage_address
> Could someone also explaim how the streaming system works.
It doesn't. There is no implementation of it at the moment. Streams have an ID which is embedded in the message and a client will only accept/route messages with the same ID as he is in.
First, they are put in memory, because is is likely, that they are used again very soon for decrypting or forwarding. After a while (or when the client exits) they are flushed to messages.dat.
About your request for more information: it depends a bit on what you'd like to do with it. The white paper and protocol specification are useful starting points if you want to write a new protocol implementation, the wiki also holds lots of information about more user centred aspects of Bitmessage.
In case you really want to implement your own client, you won't come around looking at the PyBitmessage code as some aspects of the protocol aren't really documented.
Since nonce field of the object packet is not signed, one (e.g. weak client without much computer power, mobile phone, etc.) can create fully encrypted and signed object without or with empty nonce and pass it to some gateway. Gateway can calculate nonce by itself and broadcast the resulting fully valid object to the network. In order to mitigate spam/flood issues, gateway can use some sort of CAPTCHA mechanism or something like that.
In fact, that's how bitmsg.me/blinked.ca work as far as I know.
>In general, how do you handle the matter of availability?
Well, messages live for 28 days by default (if I understand the code right) and the sender will automatically resend message every 5, 10, 15, etc. days so in general I don't think you need that good uptime. Bitmessage is an e-mail replacement, after all.
As for me I just don't turn off my computer so the PyBitmessage client is always running. If you need to turn off your computer or have some network issues I think up to 1 day downtimes should be completely fine. 5-10 days should be fine too, but theoretically you may experience some problems since BM is still not that mature.
Btw (as a self PR note) I've almost completed implementation of alternative (headless) Bitmessage node (bitchan-node) so if you install it on VPS it will be able to dump (and possibly decipher) all network objects even if you are offline. PyBitmessage should also be easily installed at a VPS, see e.g. here. You still should think up some way to deliver messages.dat
from the VPS to your home computer (I can give your some hints if you are interested in).
In the long term, the scalability of Bitmessage will depend on how we implement streams. There hasn't been much progress on that recently (AFAIK), but you can find a compilation of the forum threads on streams here:
https://bitmessage.org/forum/index.php?topic=4067.0
More recently, scalability discussions have centered around version 3 of the protocol, which it seems we've now more or less agreed on. The thread for that is here:
https://bitmessage.org/forum/index.php?topic=4067.0
That may not contain the specific thread you're after, but hopefully it's of some use.
Bitmessage has acknowledgements. If you send someone a message and do not receive an acknowledgement after a reasonable period of time, then you may conclude that the recipient has not received that message for some reason.
It is possible that the recipient may have disabled acknowledgments, which some people do for greater security against traffic analysis. However if they have done this, it should be signalled by a flag in the pubkey for their address (see https://bitmessage.org/wiki/Protocol_specification#Pubkey_bitfield_features). You can then act accordingly.
You're right, there's currently no integrated functionality for local encryption of private keys + addresses.
There have been a couple of 'quick fix' implementations that you might find useful: https://bitmessage.org/forum/index.php?topic=1589 https://bitmessage.org/forum/index.php?topic=2689
Implementing local encryption of the keys has been on the 'to do' list of PyBitmessage for some time, so if anyone reading this were to submit a patch which implements it I think Atheros would be very likely to accept it.
I think this happens when you are connected at the TCP level with the peer but the handshake packets haven't been exchanged yet (version and verack).
If it stays like this for a long time it could mean : 1. a bugged client, 2. someone developping a new client not functionnal yet, 3. a malicious connection trying to penetrate your machine.
Also check this thread.
It is a darknet with some similarities to Tor. I believe it is much better than Tor though, I suggest you research the difference for yourself if you are interested. https://geti2p.net/en/comparison/tor
Thanks. (I actually did look. https://sourceforge.net/projects/pechkin/ didn't have any links to "source" and didn't think to search for "murcurial". Then when I searched for "abit bitmessage source" I didn't notice the dissem link)
For the certificates, would this be of any use to you: https://letsencrypt.org/
They are leaving beta phase the 28th of October and
should then be open to hand out certificates to everyone.
If not, perhaps you should find out how much it'll cost you,
and we can see about crowdfunding it. Can't be that expensive right?
Since you're putting a lot of work into this, you shouldn't be the
one who has to pay for it.
The main link is bitmessage.org - the .ch one is dead. The forums link is also dead.
For a list of channels and subscriptions, along with instructions, send a message to BM-NBqDC5RiwBkF6URmdQu9wAG71rLNRopt with the word "help" in the subject line. This will give you a list of chans and subs that you can read. :)
Thanks for kind comments. My questions were solved, I think. I fixed my settings and codes to default ones. I'm trying accepting incoming connections, being a tor hidden service, and email gateway functionality. Thank you!
P.S. Doesn't Echo addresses in FAQ work? If no, I want the author to modify the FAQ.
Afaik no. Somebody started one but I believe it's abandoned. If you want to go through the hell that is Java, there is a protocol implementation there: https://github.com/Dissem/Jabit
The most complete C# implementation I am aware of is here: https://bitmessage.org/forum/index.php?topic=2544.0
It hasn't seen a commit since 5 years though.
First, I don't recommend using bitmessage on a VPN, it's better to use tor. Second, if you're having networking problems, you should consider using the development code v0.6 branch, development snapshots for Windows. Other than that, you simply may have to wait a long time.
UPnP stands for Universal Plug and Play, and, while I don't know a ton about it either, it can be used to get though NATs and automatically forward ports, but it can also be kind of chatty which is probably why it isn't turned on by default.
What you actually probably need to do is forward the port for Bitmessage in your router's setting. That port is probably 8444 unless you've changed it in your settings. More information can be found in the Bitmessage FAQ, along with a bunch of other information you're probably interested in.
There is a file called debug.log which is a text file. The location on Windows is the same as keys.dat. You can send me the file if you want, I'll take a look at it.
What have you tried so far? As you provide no information about your network setup, one can only guess from here.
On this site, you see the red indicator explained: https://bitmessage.org/wiki/Network_Status#Red
This site suggests to delete the knownnodes.dat and restart PyBitmessage.
> knownnodes.dat is the configuration file, which contains a list of IP addresses and ports which run bitmessage. It sometimes helps to delete this file in case bitmessage wont connect. It is stored together with keys.dat and messages.dat in the same folder.
P.S. It is indeed called netiquette.
First of all: Bitmessage is primary a means of message transport (using encryption, yes), GPG is simply a means of message encryption (and verification, which does not matter here):
GPG/PGP is a stable, audited technology existing for many years, apparently even NSA can not break it (easily).
Bitmessage on the other hand is a rather new software, lacking an security audit, which is also stated prominently on the webpage. You can't be too sure your messages are really safe with BM.
That's why you keep the message very small. Also this is more for network announcements, so wont be used for general chatting due to increase PoW and limited message size (since it would be easier to chat on normal chans). So for pedos you cannot send files thought this. For ISIS, well at most they could only point to their channel etc...
At the very least, you don't have to implement the human readable interface, and just restrict it to background announcement (e.g. channel discovery). But really, this is just a tab ( "Network Broadcast" ) which is shown as a stream of twitter length text (for information aimed at human consumption), and for messages not aimed at humans, it can be access by API.
But it would provide the framework for better usability for newcomers trying to discover new services.
edit:
Just found out https://bitmessage.org/wiki/Protocol_specification . It seems like they have a packet structure for unencrypted data . Hopefully this can be used.
If you're using TOR, maybe you can check out these instructions about how to configure Bitmessage to use TOR.
I'm not an OSX expert so I don't know how to check firewall settings, however it you can access TOR, it may mean that your traffic is restricted to ports 80 and 443 and most Bitmessage nodes are not accessible, but it should work if you redirect Bitmessage through TOR.
In the official client, there is an "Identities" tab, where you can find and create identities. One is automatically created for you, on the first run of the client.
Help for the client can be found in this wiki page: https://bitmessage.org/wiki/PyBitmessage_Help
Perhaps you weren't on the network long enough, or there was a port conflict? Try changing the port on one of them to something other than 8444, and forward it as well. Then check the network status.
Perhaps your isp is blocking bitmessage; change both ports.
Also Windows 10 seems to fail to connect.
Also try changing your demanded difficulty to something lower, say 0.1. Less privacy but easier to send and receive.
Another thing to try is to use TOR (socks5, 9150 on browser bundle):
https://bitmessage.org/wiki/FAQ#How_do_I_setup_Bitmessage_to_work_with_Tor
Yep, that's what I was referring to -- detached PGP/GPG signatures. Perfect.
When I Google "Bitmessage", I get this page:
https://bitmessage.org/wiki/Main_Page
Which looks like the official page (whether it is or not), doesn't list the latest version, and doesn't list the detached signature (.asc) files. So that's really what I was working from. Any way to get that page updated?
Hi there,
Bitmessage isn't a company or an organisation, and it doesn't have a help desk or support center. It is just a group of volunteers who write the code.
If you have issues, why not head over to the project's GitHub and enter them there, or if you have a feature request, you can edit the Official Wiki.
Glad to see you're a long time user!
>similar way of, if you open an executable in a text-editor, copy/paste it in a new text editor, and save it.
Based on a developer over at the Bitmessage forums, your statement is invalid, but, I obviously didn't check it, so, you might be valid:-
https://bitmessage.org/forum/index.php?topic=3327.0
>Encodings: Base64, Hex, Raw, ASCII85
The reason I believe it'd work, unlike how it'd fail in SMTP, is, unlike SMTP, this includes a payload length before it sends the actual method, so, it'd be something like (Obviously, it wouldn't be using plain-text ascii, nor would it use ASCII to show integers, but, you get the point)
>6hello!
Six being the length of "hello!", the reason it wouldn't work in SMTP is SMTP doesn't predefine the length of the payload, and, in fact just listens forever until you read a single period on a line on it's own (I.E. \r\n.\r\n), so, if it just-so-happened that I send \r\n.\r\n in an attachment, it'd break the smtp environment. At-least, that's my theory, I've never actually done SMTP development, nor have I read extensively into bitmessage's protocol or source. I'm just going off stuff I've read. I completely agree that it may corrupt it if it's sent raw, but, I'm basing it may not based off the stuff I've read.
Thank you for your good feedback. I have included your point about easy moderation in the comparison table, along with a link to your GitHub project, I hope you don't mind ;-)
EDIT: Can you elaborate on the issue from the DML wiki page 'Users are easier deanonymized when using DML addresses using simple network monitoring.'? It seems that it was actually discussed in a DML according to this forum post
Thanks
The message was not delivered.
You have sent a message to an address, which has not published its public key yet. This can have multiple reasons:
If the address is online again and not a DML it will answer your key request and then your client can send the message. Until then, it is not sent.
Freenet was developed for p2p hosting, if you install freenet usually you give up a bit for your harddrive for the cloud.
>* Only lets you access content uploaded to Freenet, including (static) websites, email, filesharing, forums, microblogging, etc. All of which are anonymous (or pseudonymous i.e. you create an untraceable identity). * Hosts content in a distributed way: You don't know what your node is storing, any given content is distributed across many nodes. * Ensures that popular content will be available forever. Is older than Tor, but more experimental (arguably it's a harder task).
The source of LAFS is already available at GitHub. Also there are apt packages for some distributions already
I've had some level of success running 2017-10-20 on it's own isolated VM. After a few hours of use, 100mb RAM usage and 15% CPU usage with occasional brief spikes. 30 connections, a mix of inbound and outbound. All of these are within the range of acceptability.
I'm not entirely sure why it's running with more stability on this new VM whose specs are identical to the VM where it failed.
One item of interest: The failing VM was running an AirVPN client. I'm not sure why this would make a difference; In fact, on OS X, BitMessage runs smoothly behind AirVPN, happily accepting inbound connections and making outbound ones. Then again it may not be AirVPN that caused the problem at all.
I'll let it run for a few days and we'll see how things look.
I have a node running over AirVPN. All I did was to get a forwarding port from:
As I have the VPN code running in my router I had to add the following to my Firewall up script:
/usr/sbin/iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.123 --dport 12345 -j ACCEPT
and
/usr/sbin/iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 12345 -j DNAT --to-destination 192.168.1.123
(You need to change the "12345" and "192.168.1.123" to the port number and local IP address)
Then I just set the port number in the Bitmessage client, and after 10 minutes I got the green indicator.
"The real University ... has no specific location. It owns no property, pays no salaries and receives no material dues. It's a state of mind which is regenerated throughout the centuries by a body of people who traditionally carry the title of professor, but even that title is not part of the real University. The real University is nothing less than the continuing body of reason itself.
In addition to his state of mind, "reason", there's a legal entity which is unfortunately called by the same name but which is quite another thing... But this second university, the legal corporation, cannot teach, does not generate new knowledge or evaluate ideas. It is not the real University at all. it is just a church building, the setting, the location at which conditions have been made favorable for the real church to exist."
Zen and the Art of Motorcycle Maintenance, Robert Pirsig.