How to..

[chan] bitmessage
Jun 27 06:05

So to allow incomming connections from both clearnet and Tor,this must be in the the torrc config file,and then run tor.exe when its done?: socksproxytype = SOCKS5 onionhostname = abcdefgh.onion onionport = 8444 sockslisten = true 2.) But how do I find the correct onion hostname? Does it generate one automatically? if so... where? 3.) Whats the delay of receiving and sending message to someone who hasn't configured their Bitmessage with Tor Hidden node and the ones who have configured their Bitmessage with Tor hidden node?

[chan] bitmessage
Jun 27 06:53

To get your onion hostname for your Tor hidden service you must: 1. create a directory for the hostname and private key file. 2. add the directory entry to your torrc file 3. shut down and restart Tor. this will automatically generate a hostname file. 4. open the directory you created and you will see a text file with the onion hostname. Don't confuse the onion hostname with the private key. Never share the private key.

[chan] bitmessage
Jun 27 06:58

Can you give me an example how it looks like in the torrc file for the configuration for BitMessage,how it looks like,but without give any more info from it? because from what you explained,I need to also have a line with where the directory for the hostname and private key file is located and I dont see that on the FAQ

[chan] bitmessage
Jun 27 07:55

Here is an example of what needs entered in the torrc file: HiddenServiceDir /home/user/apps/TorBrowser/HiddenServices/PyBitmessage HiddenServicePort 8444 127.0.0.1:8444 The directory path in the first line needs to reflect YOUR directory path. Make sure the HiddenServicesPort matches what's in your keys.dat file.

[chan] bitmessage
Jun 28 01:36

I use a shell script set up an ephemeral hidden service and configure bitmessage before running bitmessage. then when bitmessage exits it removes the hidden service.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jun 28 04:34

I don't recommend this. If you're not running bitmessage 24/7 it's probably better to not setup a hidden service at all. If you do run it 24/7 but restart often, then it's better to keep the same onion address. Peter Surda Bitmessage core developer

[chan] bitmessage
Jun 28 11:20

Hey nice idea. I've been using a hidden service with a fixed .onion address so far. Care to share your script?

[chan] bitmessage
Jun 28 12:17

Please share the code! Hundreds of people need your solution!

[chan] bitmessage
Jun 28 12:40

The script would be simple to write yourself. Use bash to perform these operations: sudo killall tor rm /..../private_key rm /..../hostname tor sudo killall PyBitmessage (or PID of bitmessage) awk or sed the new onion hostname into keys.dat PyBitmessage done shouldn't be too hard to figure out.

[chan] bitmessage
Jun 28 12:48

Why would you do that, though? It doesn't exactly give you anything, but it fills up the node lists of other people with onion addresses, which will be unreachable, making it bit by bit harder to find a node to connect to.

[chan] bitmessage
Jun 28 13:16

Change the manner in which bitmessage resolves nodes to be more efficient. Distribute php/http bootstrap scripts for free hosting users worldwide. Make bitmessage do pings from bootstrapping nodes to those in the knownnodes list on a separate, dedicated realtime socket on all nodes. The programmers should overcome problems by design rather than by having a manual of arcane rules for users.

[chan] bitmessage
Jun 28 13:18

Except, ANY system works better if the largest number of participating parts is behaving properly. If a large number of parts of any system behaves incorrectly, it's not something a programmer can fix.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jun 28 16:11

While it is true that the node list management can be improved (and I started doing that with 0.6.2 and still continuing), there is still the question of the benefit of an ephemeral node address. It doesn't improve connectivity, speed, or anonymity. It doesn't really help the network meaningfully unless you run your node 24/7. It may make sense for protocols which require you to accept incoming connections in order to work, but not for Bitmessage. If you want to both help the network and have anonymity, the best choice is to setup a permanent node on a VPS somewhere in the cloud, and independently use tor-outbound-only connectivity on your laptop/desktop. 0.6.3 will have a dramatically lower memory requirements, so you should be able to use a cheap VPS. Peter Surda Bitmessage core developer

[chan] bitmessage
Jun 29 02:34

Reputation systems can reduce this a pretty significantly.

[chan] bitmessage
Jun 29 08:16

Sorry, my solution is highly specific to my system. However the following script illustrates the general idea although I haven't properly tested it even works. It requires python3, stem and Tor 0.2.7.1+. The idea is to run the script with the path to keys.dat as the only argument. It then reads some onion settings, instructs tor to create a hidden service (generating a new private key if necessary and adding appropriate settings to the end of the keys.dat in a duplicate section), then runs bitmessage. When bitmessage ends the script ends and tor automatically discontinues the hidden service. #!/usr/bin/env python3 import argparse import configparser import subprocess from stem.control import Controller parser = argparse.ArgumentParser() parser.add_argument( 'bm_config_file', type=argparse.FileType('r+'), help='location of keys.dat') args = parser.parse_args() config = configparser.ConfigParser(strict=False) config.read_file(args.bm_config_file) local_port = config['bitmessagesettings'].getint('port') hs_ip = config['bitmessagesettings'].get('onionbindip', '127.0.0.1') hs_port = config['bitmessagesettings'].getint('onionport', local_port) key_type = config['bitmessagesettings'].get('onionkeytype', 'NEW') key_content = config['bitmessagesettings'].get('onionkey', 'BEST') discard_key = key_type != 'NEW' with Controller.from_port() as controller: controller.authenticate() response = controller.create_ephemeral_hidden_service( {hs_port, }, key_type=key_type, key_content=key_content, discard_key=discard_key, detached=False, await_publication=False) service_id = response.service_id if not discard_key: s = ''' [bitmessagesettings] onionhostname = {}.onion onionbindip = {} onionport = {} onionkeytype = {} onionkey = {} '''.format(service_id, hs_ip, hs_port, response.private_key_type, response.private_key) args.bm_config_file.write(s) args.bm_config_file.flush() args.bm_config_file.close() subprocess.run('python')

[chan] bitmessage
Jun 29 10:13

you forgot something like this: subprocess.run('tor') subprocess.run('bitmessagemain.py') .......................... subprocess.run('ps aux | grep -i firefox | awk '{print $2}' | xargs kill -9') subprocess.run('ps aux | grep -i TorBrowser | awk '{print $2}' | xargs kill -9')

[chan] bitmessage
Jun 29 10:14

Yes censorship by the majority is good.

[chan] bitmessage
Jun 29 10:17

or subprocess.call() ???

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jun 29 11:18

I can only repeat what I said, having an ephemeral hidden service bitmessage node provides no benefits to anyone. If for some reason you're unable to run a fixed hidden service address (e.g. you're storing the configuration in volatile memory) and still want to help the network, then fine, but otherwise please don't use it. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 1 00:32

That's not what it even is. Like, at all. The whole idea of one is that people that say useful/interesting/amusing/{insert your choice of adjective here} things are given more attention, while others get less. *Every* group of people has things they don't/can't/won't discuss; that's kind of just how humans work. Oblig xkcd: https://xkcd.com/1357/

[chan] bitmessage
Jul 1 00:54

Forgot to mention: It can also refer to automated systems; nodes are given reputation scores based on uptime, connection consistency, etc. That way malicious ones don't have as much of an impact.

[chan] bitmessage
Jul 1 01:03

Also a service to request ratio can greatly help mitigate malicious clients. It's basically a proof of work without using hashes. A client should only be able to send a fraction of the bandwidth it forwards. Perhaps for every 30 messages forwarded 1 message can be sent.

[chan] bitmessage
Jul 1 08:34

Learn from the events that required implementation changes to original peer based filesharing systems: these came under well funded attack for copyright piracy reasons. Many of those countermeasures are directly relevant to Bitmessage. Put some strategic thinking in that direction and discuss them here ( But please post in a renamed Subject Thread that includes same unique text within open chan message text and post insightful comments with 28days TTL)

[chan] bitmessage
Jul 1 08:50

> post insightful comments with 28days TTL yes. everyone: when you post something important, or send a message direct, always use 28 days TTL: for a couple good reasons. 1. Many ultra paranoid users don't run a permanent node and only connect every few weeks to download messages then go dark again (like me). The only messages we'll get are ones with a long TTL. 2. A large number of users using 28 TTL helps mitigate timing attacks and in private messages preserves the anonymity of sender to receiver, if at least several people do it consistently. This does not mean use 28 days for every message. Just the important ones.

[chan] bitmessage
Jul 1 09:09

Better way is to limit incoming speed. You don't know which messages are forwarded, which created. In Emule we have credits/rewards system stored in remote nodes. It's called DL/UP Modifier. In Emule every big uploader downloads faster. In BM every big uploader should be limitted.

[chan] bitmessage
Jul 1 09:53

connections between nodes need to be encrypted. without this a network survey can determine origin of an object by seeing which node sent it earliest.

[chan] bitmessage
Jul 1 10:00

Well, Peter has been doing quite some great work on this end. Of the 18 connections I have right now, only 4 are without encryption.

[chan] bitmessage
Jul 1 10:03

How to enforce encryption?

[chan] bitmessage
Jul 1 10:04

I don't think there's a way to enforce it. But the current versions of PyBitmessage (0.6.1 and 0.6.2) will always first try to establish encrypted communication first and fallback to legacy if the other side doesn't support it. Peter would have to answer if there's a way to get PyBitmessage to ignore nodes which can't encrypt.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 1 13:11

Since about 0.5.8 (it's in the release notes, I'm too lazy to check), PyBitmessage will indicate via a bitflag that it supports TLS during the BM handshake, and if both sides indicate this, the connection will turn on TLS. This isn't configurable. There is no hard fallback (if both sides indicate TLS support and the TLS handshake fails, the connection will die), only a soft one (if at least one node doesn't indicate TLS support, the connection will continue unencrypted). There are certain restrictions: - incoming connections are only encypted if you have python 2.7.9 or higher. This is due to limits of older python versions (they don't support anonymous TLS server mode). In the future, when authentication is added, I believe this restriction won't apply anymore - if both sides have python >= 2.7.9 and PyBitmessage >= 0.6.2, it uses TLS version 1.2, otherwise 1.0. Again this is due to limitations of older python versions. The platforms that I checked use ephemeral session keys (i.e. the connection has forward secrecy). At some time in the future, once everyone upgrades and other implementations add TLS, TLS will be mandatory and nodes will refuse connections to/form peers that don't support TLS. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 1 14:01

Can anyone tell me how to get exactly the most recent or best bugfixed version of bitmessage? I got 0.6.2. There was a problem with old / expired objects being re-routed by another bad node. I was getting them even after deleting them. I suppose I should NOT have gotten them. Would that indicate that my node is bad, too? help?

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 1 14:48

They shouldn't reappear in your inbox, if that's what you mean, that would be very strange. If you're merely getting messages in the log or on the console, you can ignore them, they merely have an informative character and merely sound unnecessarily ominous. If you really want the bleeding edge version, you can get the source from github (v0.6 branch), and for a couple of weeks there have also been daily snapshots for windows, which can be downloaded from https://bitmessage.org/download/snapshots/ Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 2 12:12

what about the implementations in other languages, apart from PyBitmessage? all of those will need to be upgraded too. many seem incomplete still, or still don't support latest protocol. hard to keep current when only up-to-date implementation is PyBitmessage - maybe this should be more coordinated across languages, like picking an 'official' client or at least library for each major language.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 12:14

I don't think any other implementation supports TLS. I documented the TLS parameters in the wiki a long time ago. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 2 12:22

MiNode does. However, it's not a full client (it can't send messages).

[chan] bitmessage
Jul 2 12:34

For reference: https://bitmessage.org/wiki/Protocol_specification#version >A "verack" packet shall be sent if the version packet was accepted. Once you have sent and received a verack messages with the remote node, send an addr message advertising up to 1000 peers of which you are aware, and one or more inv messages advertising all of the valid objects of which you are aware. >The following services are currently assigned: >Value Name Description >1 NODE_NETWORK This is a normal network node. >2 NODE_SSL This node supports SSL/TLS in the current connect (python < 2.7.9 only supports a SSL client, so in that case it would only have this on when the connection is a client). >3 NODE_POW This node may do PoW on behalf of some its peers (PoW offloading/delegating), but it doesn't have to. Clients may have to meet additional requirements (e.g. TLS authentication) (proposal) https://bitmessage.org/wiki/Protocol_specification#verack >verack >The verack message is sent in reply to version. This message consists of only a message header with the command string "verack". The TCP timeout starts out at 20 seconds; after verack messages are exchanged, the timeout is raised to 10 minutes. >If both sides announce that they support SSL, they MUST perform a SSL handshake immediately after they both send and receive verack. During this SSL handshake, the TCP client acts as a SSL client, and the TCP server acts as a SSL server. The current implementation (v0.5.4 or later) requires the AECDH-AES256-SHA cipher over TLSv1 protocol, and prefers the secp256k1 curve (but other curves may be accepted, depending on the version of python and OpenSSL used). https://bitmessage.org/wiki/Changelog >0.6.0 >QT interface overhaul >Opportunistic TLS support This is every occurrence of the word SSL or TLS on the wiki. Porting this to other langs could require lots of trial and error, and many other language impls seem incomplete or out-of-date as-is. So currently, all users of other languages will be cut off from the network if hard-TLS req goes live. Why even claim support for languages other than Python if the Python client is the only one kept current?

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 12:39

Ah, good to know. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 12:51

The reason why there isn't more is that the it works the same way as other TLS and relies on OpenSSL to do everything. The actual implementation is literally two lines of code, one calling python's wrap_socket and another one do_handshake methods from python's ssl module. In python 2.7.9 or newer, it also sets up a ssl context variable to explicitly remove certain SSL configuration parameters which aren't needed (it will work without it, it just results in a more strict implementation of the specification). While there is more TLS-related code in PyBitmessage, that's is detecting version of python and OpenSSL, error handling, buffer flushing, asyncore support, loading dummy keys and workarounds for missing library/python functionality. That isn't specific to the Bitmessage wire protocol. Peter Surda Bitmessage core develop

[chan] bitmessage
Jul 2 13:02

Granted, in Python many things are 2 lines of code. And if you only use it to communicate with other Python impls, chances are that they used the same 2 lines of code calling the same exact library and it all just works. But it tends to leave certain details a bit unclear for those who need them for other languages. What is Python's wrap_socket(), in raw OpenSSL calls? What is Python's do_handshake(), in raw OpenSSL calls? What specific SSL config parameters are being explicitly removed in python 2.7.9 or newer? Also all those workarounds that will presumably need to be ported too. This looks likely to be a lot more than 2 lines of code: https://stackoverflow.com/questions/4236526/looking-for-a-high-level-c-ssl-library And a lot of very frustrating debugging and staring at pcap files. I'd be surprised if someone does it.

[chan] bitmessage
Jul 2 13:09

For instance: >The current implementation > (v0.5.4 or later) requires the AECDH-AES256-SHA cipher over TLSv1 > protocol, and prefers the secp256k1 curve (but other curves may be > accepted, depending on the version of python and OpenSSL used). Which other curves may be accepted? Under what exact circumstances? What if you aren't using Python in the first place ("depending on the version of python...")?

[chan] bitmessage
Jul 2 13:12

Or do we just treat the Python impl as the spec, if the spec doesn't contain this information? It is the reference client after all. It's just that trying to get an exact behavior match in another language for the behavior of a specific Python library is often pretty hit-or-miss and can get quite time-consuming. A more language-agnostic unambiguous spec could potentially help reduce the amount of pain involved for anyone trying to keep the other language impls current.

[chan] bitmessage
Jul 2 13:46

This is indeed very convenient: http://www.programcreek.com/python/example/1124/ssl.wrap_socket Here's the approximate equivalent in OpenSSL: https://stackoverflow.com/questions/7698488/turn-a-simple-socket-into-an-ssl-socket Note all the discussion about needing certificates -- do we need those here? I don't see anything about certificates in the docs or this thread. Also comments stating that using the library is notoriously difficult and error-prone. As an early-stage end-user of the protocol, it seems like entire languages are going to be dropped from usability if someone doesn't hack their way through this. This makes it difficult to justify building something based on anything but the Python XML-RPC API.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 16:42

> Granted, in Python many things are 2 lines of code. And if you only > use it to communicate with other Python impls, chances are that they > used the same 2 lines of code calling the same exact library and it > all just works. But it tends to leave certain details a bit unclear > for those who need them for other languages. Then that's a python issue and not a BM issue. > What is Python's wrap_socket(), in raw OpenSSL calls? > What is Python's do_handshake(), in raw OpenSSL calls? I don't know. > What specific SSL config parameters are being explicitly removed in > python 2.7.9 or newer? It restricts which elliptic curves can be used. I'd like an crypto expert to look at the choice of curves and give feedback. > Also all those workarounds that will presumably need to be ported > too. The workarounds make TLS behave according to OpenSSL documentation rather what python's developers thought ssl should behave like. When I was writing it originally, I tried the connectivity with openssl s_client/s_server (after disabling the BM handshake) and it works, so there isn't anything hidden going on, apart from my own bugs, which I hope are fixed in 0.6.2 and in asyncore. > This looks likely to be a lot more than 2 lines of code: > https://stackoverflow.com/questions/4236526/looking-for-a-high-level-c-ssl-library > And a lot of very frustrating debugging and staring at pcap files. > I'd be surprised if someone does it. I also used wireshark when implementing debugging. The problems occured due to undocumented python bugs and me not doing buffer flushing correctly. Oh and when using OpenSSL 1.1, you have to add "@SECLEVEL=0" to anonymous ciphers. After I fixed/worked around that, it worked fine. None of this is BM specific. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 16:59

> For instance: > >The current implementation > > (v0.5.4 or later) requires the AECDH-AES256-SHA cipher over TLSv1 > > protocol, and prefers the secp256k1 curve (but other curves may be > > accepted, depending on the version of python and OpenSSL used). > > Which other curves may be accepted? Under what exact circumstances? Any curve under any circumstances. I'd like to harden this, but I'm not a crypto expert and didn't want to unnecessarily break stuff. So if you can't use the secp256k1 curve, you still may get lucky as some nodes may accept other curves. In retrospect I'm not overly happy over the choice of curves and would like a cryptographer's opinion about adding others (OpenSSL allows to specify more than one in the order of desired priority). > What if you aren't using Python in the first place ("depending on > the version of python...")? If both sides accept curves other than secp256k1, they can agree on a different one. If you have python < 2.7.9 and are using it's ssl module, it doesn't allow to specify which elliptic curves to announce, so the negotiated curve is undefined. Recent pyopenssl packages don't have this restriction and can be used instead, however I haven't added this code because on my test environment at that time, Ubuntu 14.04, the distro contained both the old python version and old pyopenssl, so you'd have to install at least one of them manually anyway and I think in that case it's easier just to use venv to setup a newer python version. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 2 17:10

> Note all the discussion about needing certificates -- do we need > those here? I don't see anything about certificates in the docs or > this thread. Currently the protocol specification doesn't support certificates (the only specified cipher is anonymous, i.e. certificate-less). The PyBitmessage repository contains dummy certificates to work around python's bugs, which however have no cryptographic relevance. I want to add certificates later, the nodes will include their certificates when they announce themselves and then the client can use that information to verify it. If it doesn't want to verify it, or if the server doesn't have a certificate and the client doesn't mind, it will continue unauthenticated as it is now. > Also comments stating that using the library is > notoriously difficult and error-prone. That's probably why python has wrap_socket. > As an early-stage end-user of the protocol, it seems like entire > languages are going to be dropped from usability if someone doesn't > hack their way through this. This makes it difficult to justify > building something based on anything but the Python XML-RPC API. As I said before, almost all my time when debugging turned out to be caused by bugs in python, hidden openssl things (like how anonymous ciphers work with 1.1) and my own bugs. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 3 03:55

This and the preceding replies were quite informative. Thank you very much for elaborating. I have a better understanding of what would be needed to try implementing this extension of the protocol in C/C++ now. Do you have an opinion of which C/C++ bitmessage library is the most complete and up-to-date? BitMRC looks like it but not sure.

[chan] bitmessage
Jul 3 13:55

> And a lot of very frustrating debugging and staring at pcap files. > I'd be surprised if someone does it. Busy FinTech Specialist Programmers, well paid. Looking myself at Python raw sockets programming ( Network Focussed Pentesting courses / Vids ) Been there in C decades ago; maybe better placed at that level and build custom python abstraction programming layers to a common testing standard if you really must code real time critical stuff in hiher level abstractions. Dont forget that the multithreading capability in python is deliberately limited, and that Py2 + Py3 implementations differ. So you have the dubious pleasure of doing it over again, later.

[chan] bitmessage
Jul 4 22:19

oops, yeah I meant subprocess.call(). One can use os.system() or popen, which is deprecated but works in older py. Also, if using shell commands in a py script, shell returns output to the script that needs to be checked to preven errors. In this case use: subprocess.check_output("ps aux | grep -i firefox | awk '{print $2}' | xargs kill -9", shell=True).strip() I set it up as a bash alias so If I need to kill bitmessage I just hotkey the shell and enter it: alias killbitmsg="ps aux | grep -i firefox | awk '{print $2}' | xargs kill -9"

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 6 18:01

For the first time I now noticed in the network status that indeed MiNode 0.2.2 negotiates TLSv1.2. Well done! Peter Surda Bitmessage core developer

[chan] bitmessage
2 hours ago

refresh lawl

[chan] bitmessage
2 hours ago

my point being : it is September now , and this post is from June ! nice caching job there ! use google for this malfeasance ;-)

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
Building instructions for Windows Sep 24 17:53 13
beamstat.com is being cached by google Sep 24 16:51 1
How to.. Sep 24 16:43 2
BitText XHKhFPCDzj: ultimate bitmessage forum Sep 24 16:36 1
BitText Error Sep 24 16:32 1
BitText LIST Sep 24 16:16 2
HELP Sep 24 15:49 2
BitText ADD confirmation Sep 24 15:34 1
TTL Tweaks Sep 24 15:27 12
turn MiNode into a full client - simple task ! Sep 24 15:12 1
use MiNode py3 app to route a BM via "stream 7" Sep 24 14:07 1
BM GUI via API using monkey studio Sep 23 20:35 26
BM GUI via API using KDevelop Sep 23 18:21 1
Email client integration Sep 23 16:34 10
got green light Sep 23 10:59 3
pyBM eats too many CPU cycles Sep 23 10:36 22
Git pull error Sep 23 08:49 17
What's a status of DevTalk pseudo-mailing list? Sep 23 07:44 7
Kdevelop + qt-designer for python Sep 22 21:47 1
NATO member Turkey boast that Russian S-400 SAMs can take out American B-52s, F-22s and Tomahawks Sep 22 12:24 1
bug? pyBM eats 17% of my 6core CPU cycles SOLVED :-) Sep 22 11:41 1
bug? pyBM eats 17% of my 6core CPU cycles Sep 22 11:37 21
monkey studio Sep 22 11:06 1
MX.forum.cool Sep 22 10:56 2
so stream 7 cannot work ? Then what did I do ? Sep 22 10:44 1
How make new stream? Sep 22 10:29 22
(Qt4 security staus?) Sep 22 10:27 6
Question Sep 22 05:49 8
GUI choice is Good. Ncurses anyone? Sep 22 05:35 6
attitude Sep 22 03:21 2
(Qt4 security status?) Sep 22 02:57 2
Searching for BM address for g1itch/Dmitri Bogomolov Sep 21 15:41 4
QT designer and Monkey GUI builder for pyBM Sep 21 15:39 1
bug report: Connected hosts: 0 -- SOLVED :-) retracted Sep 21 13:35 1
bug report: Connected hosts: 0 -- SOLVED :-) Sep 21 13:32 2
Gabon has teamed up with militant conservation group Sea Shepherd Sep 21 13:17 1
twister micro blogging Sep 21 12:40 6
rating in pybitmessage snapshot build Sep 21 12:38 3
#Assange Sep 21 11:45 4
bug report: Connected hosts: 0 Sep 21 11:09 7
How would you describe the technology behind Bitmessage Sep 21 09:43 4
does anyone get BM over tor to work ? SOLVED :-) Sep 20 22:03 1
does anyone get BM over tor to work ? Sep 20 22:00 12
what needs to be in a real BM GUI via API - web Sep 20 21:55 20
what needs to be in a real BM GUI via API Sep 20 21:52 14
BM GUI via API Sep 20 21:47 1
bot bug: bot keeps sending me a list - ACK is missing Sep 20 21:38 2
get BM over tor to work ( see UBF ) Sep 20 21:32 1
GUI Sep 20 20:38 1
BM future & features Sep 20 16:41 7
Feature Mashup Sep 20 16:40 1
BitMessage Secure Station (Developer Version) open-core open-hardware project PCB routing advancement : 75% Sep 20 16:01 9
py typo-squatting Sep 20 15:41 1
does anyone get BM over tor to work ?? --> poss. solution now? Sep 20 12:09 2
does anyone get BM over tor to work ?? Sep 20 11:17 5
what needs to be in a real BM GUI Sep 20 11:14 27
Is anyone there? Sep 20 07:47 5
Rewarded help needed for scanning old amazon (Or any other website) shipment barcodes (Reward $10 in Bitcoin per scan). Sep 19 22:25 1
Bitmessage noise script Sep 19 00:48 15
BitMessage Secure Station's architecture security review : White Papers & Publications about Designing Secure Hardware and fighting Hardware Backdoors. Sep 19 00:48 4
How to compliment a female cryptographer? (joke) Sep 19 00:47 3
Great article about fighting Hardware Backdoors and how to design secure open-hardware open-core systems (BitMessage Secure Station) Sep 17 11:58 1
Question about curves Sep 16 21:27 10
Streams Sep 16 10:39 4
BitMessage Secure Station open-core open-hardware project news. Sep 15 22:07 8
Tor Browser Sandbox Sep 13 21:39 1
BitMessage Secure Station "version developer" security update Sep 13 20:56 1
ISS Space Station - Augmented Virtual Reality Sep 13 12:41 2
TTL of pubkey requests Sep 13 05:52 2
encryption in BM Sep 12 16:55 20
BM connection security Sep 12 08:26 8
First pictures of the in routing PCB of the BitMessage Secure Station, version developper (Implemented with a PIC 24 Microcontroller, and not a Spartan 6 FPGA) Sep 11 13:37 1
Another Question about curves Sep 11 09:49 3
onion issues/questions? Sep 11 06:53 32
CAN SOMEONE REVERSEENGINEER? Sep 9 15:22 42
bitmessage has forward secrecy? Sep 9 08:35 17
mixmaster / mixminion routing in bitmessage Sep 9 08:23 6
Passphrase encryptsion for keys.dat? Sep 8 20:33 14
Bitmessage Addresses Question Sep 8 09:46 2
FEATURE REQUEST: PGP SIGNING Sep 7 00:55 6
Anatomy of encrypted payload Sep 6 08:24 8
BM / singleWorker.py Sep 6 07:07 6
Bitmessage Mix Routing Sep 6 03:32 1
Unencrypted image Sep 5 20:22 5
Do PoW but don't send the object Sep 5 09:05 2
Question on BM source code Sep 5 08:42 3
ENCRYPTION IN BITMESSAGE Sep 5 08:26 15
What does this mean? Sep 2 05:03 3
Anybody willing to share their xmpp IDs? Sep 1 15:05 1
Short Addresses Sep 1 01:40 35
Bitmessage and Namecoin Aug 31 06:45 3