UBF -- The Ultimate Bitmessage Forum

User info

Welcome, Guest! Please login or register.

You are here » UBF -- The Ultimate Bitmessage Forum » pyBitmessage » BM help and documentation -- secret readme

BM help and documentation -- secret readme

Posts 1 to 19 of 19


many don't like how the other BM wiki is being censored and used to doxx BM-users.

So here is the real help-file:

Last edited by user3 (Mar 10 2016 08:02)


You are making up artificial problems that don't really exist. There is nothing easier than just exiting the client and running an offline rescan tool that would do nothing else than going through all the objects and reprocess them. Just a tiny bit more difficult solution would be to do that directly from within the client which - for the scan runtime - would suspend all its other activities.

Only v4 addresses have the rescan feature because v4 addresses generate v5 broadcasts which have a tag for easy identification. Most, if not all, of those addresses are v3 or v2 and thus only generate v4 broadcasts which require the same decryption process as msgs: attempting decryption using every enabled subscriptions key. Implementating this isn't trivial which is why v5 broadcasts have a tag. What if a user adds a new subscription/chan during a rescan? Is the rescan restarted or is there a queue of rescans? What about expired messages (messages that an immediate scan would have decrypted but a delayed scan missed because the message expired and was deleted)? What about new messages arriving during a rescan particularly during synchronization (a message that arrives after the new address is added is automatically checked against the new address)?

I think there's already a ticket about it on github.

> Not to rescan but actually to redownload everything all over again,
> which is just dumb and abuses the network and resources because
> PyBitmessage had all those objects already. The "rescan" feature is
> what is missing.
> ------------------------------------------------------
> I subscribed to all these broadcasts, and then deleted the inventory
> to rescan all the objects.
> I received a ton of messages from TimeService, and a single message
> from Insugentile. That was all I got. The other ones may or may not
> be dead, but most probably are.
> ------------------------------------------------------
> Broadcasts:
> subcribe there (i.e. do not join chan)
> Adrian Short BM-2cV81aEbr1jCoyivcncFeJ8KdGUnUCbKTh - - -
> adrianshort.org
> Apatomoose BM-NBhMpTd2ymGZxBGbSnpWWTtmUinkiwhM
> Apatomoose BM-orBMya4QReKJsfWzmpuZZfS3MHcFcQdBm
> Bitmessage commerce broadcast BM-NB3Ac4aH3dVRtvPnFnffRwHTgs9Qesp8
> Bitmessage Forum broadcaster BM-2cVU5QZ6pquWFcNcRsHAE1PQJTD8zQbgyD -
> - - bmServices.tk
> Bitmessage new releases/announcements
> BM-GtovgYdgs7qXPkoYaRgrLFuFKz1SFpsw
> Bitmessage PHP Class BM-NB19YCwxEnxQXNcGsiFiZU6hjAtJ3pEA - - -
> Release information
> Bitmessage Rebel Broadcast BM-2cXWinxVP1TX24W4wK44VziQpxckXARkp3
> Bitomail news and announcements BM-NBbUtpBXJXVHwWHEWeDovMecqQjEe1oN
> - - - http://personal.kolaja.eu/projects.html
> Bitparking Exchange updates and information
> BM-BbgTgGa6LX3yYqwJSwdwrzysvfWjM2u6
> BMaggregator BM-2D7Wwe3PNCEM4W5q58r19Xn9P3azHf95rN
> BTC Price information every 10 minutes in EUR, USD and GBP
> BM-2cW7MXGU3vtn1deeTRpzrZ95sdtBYywbks - - - bmServices.tk
> BTC Price information every 30 minutes in EUR, USD and GBP
> BM-2cXsWsLfMSsgnPSxUzxPbuPhQNf5PJhqFd - - - bmServices.tk
> BTC Price information every 60 minutes in EUR, USD and GBP
> BM-2cT2LodzfnQBwaX3cqoPozwCheQ8TYkwTK - - - bmServices.tk
> Bündnis Privatsphäre Leipzig BM-2cTaGSVyiHGib57YKSgMh8fFbRb6D2pa6f
> CrownCloud notices BM-2DAfTFF3H5PXhsXxsRC7hRyMagRm2aLwK5 - - -
> crowncloud.net
> CryptoJunky BM-2DBXxtaBSV37DsHjN978mRiMbX5rdKNvJ6 - - - Articles
> related to cryptography
> CryptOpinion Sunday Newsletter BM-NBTchTfFRC68JG4k4h8NRQqMU5gz3d1G
> Daily Anarchist BM-2D92uXjVH5YAGUfcbcUELqyC6K8JqT9nUg - - - blog
> posts
> Daily security news BM-2cSqJErd1UjZ5KoRkaAt5FzpsGTZbynsbz
> FinBM - Finnish Public Bitmessage Chan Broadcast Address / Päälista
> BM-GtvRhAFh1GujEDfqSs92t2LSYFvPKpa3
> FinBM - Distributed Backup Broadcast Address / Varakanava
> BM-GuFn5YWw6h6LDVWXhyUKg62mNgQwgohd
> Grand Wizard's Broadcast Stream BM-NBjxaEvSa8gS8QmALfjn6rNW7EgoKmFu
> heavycoin-users BM-2cV6qRmeK677qYBetTMXmVmu6vGo3Pn4GG - - -
> Heavycoin developments
> Help BM-2cTKZkhu12pib9gwBaxUuzZtL9YeNr3MtU
> Insurgentile BM-NBVR24ZQDmFsjDEUEnn7EioZbkV8mzmB
> Lands of Sheraga BM-2D9rPSJknudPV8pSWZWrw29RHtbHeWfhga
> MC2 Newsletter BM-2cX8R4saGGUPnEkwUpTsQdP4Bu1YCqUtqE - - - MC2 News
> and Community Funding Initiative
> Mesbit news & announcements BM-NBdJo44eQMqCYFn5TyxNRY28mmYRVMnK - -
> - mesbit.com
> mmpool.org - updates BM-NBs7aHtbw6x7beefygEC4Cv6Rsp2dZni - - - merge
> mining for bitcoin-derived virtual currencies
> Multisignature project BM-2cWJbymbhAGXXLM2zV73sNHqKYXnfsW4sk
> Music-Art projects for SaveTheWhales/Dolphins/Belugas
> BM-2cU5Dof8FxRqtLWtayPY2EGFTFoioWk9Hm
> NVCBank announcements BM-NBvsMijZJe9QM7EGnaXUT1t6RFCi8R33 - - -
> nvcbank.com
> openmw BM-2cWPth7A6qLr1BXSC74Bjzyp9vwV9Tux5D - - -
> https://openmw.org/
> Programming and database news (German)
> BM-NAz4H5H32fAJxp6vbfJdkGaBRLRVXa6f
> ProjectMeshnet/Hyperboria updates
> Q's Aktivlist BM-GtT7NLCCAu3HrT7dNTUTY9iDns92Z2ND
> Rebeldyne BM-2cTgYfxecwYCAhsCiYSNGDUiijZDctQ89w
> Round-op Alpha BM-2cTGvTn5q9TnJtJ3AgP2tKDA9435NGGGsP - - - Global
> operation for the arrest of the World Government. Newsletters &
> updates
> Scribe BM-2cWwEi8e6Q6W1M9B2XRyJfu7LzTJGhjAuf - - - #taopunk & silent
> revolution & @emptytech & #bitcoin & #opendata & #haiku
> Skeletor BM-2cVYjbUkPZ17gyLJgAfE7D7mR5u1v7UzoQ - - -
> okzatvfk2jzgvmf4.onion/   facebook.com/FortranBA20
> Skycoin announcements BM-2cXxcRpG1raeNYwDjcb6Axxqi4yiMdqvPf
> Stock Prices information every hour in EUR, USD and GBP
> BM-2cTFmCwivUEC56xfzZ4Y6vGdUhFAVfjuaG - - - bmServices.tk
> Subscription list updates BM-Bbr4a4eNEUTxpEKTQ6BiFb52ftVW1CMs
> TimeService BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash
> Twitter Trending Topics (TT) List updates
> BM-2cV9mHyRtVwnEH9Ym72Wg3HM9hzLegHdPs
> twitter.com/BitmessageDEV BM-2cTrwetbapXCDsptQQsoqQYv5zvgc2PMV2
> Unofficial ZeroHedge feed BM-2D7saq3vmHdHuuoZkPSVGjGVSRjGuc6WZJ
> WeeklyDigest BM-2cTDf5Jxydo61Uav2TxBKs6Dnc5GvPyPs3 - - - Weekly
> updates on bitcoin, bitmessage, world affairs and the financial
> world
> WhiteyLeaks: Exposures of Poseurs
> BM-NBbYjBFtPk1xxkNfm7xNGVzo7KKaraWW


TTL is stored as the expiration date so it will have to be set to a new value which will affect the message payload checksum which will need a new PoW.

However, it is a lie what the client says, i.e. "By default, if you send a message to someone and he is offline for more than two days, Bitmessage will send the message again after an additional two days. This will be continued with exponential backoff forever; messages will be resent after 5, 10, 20 days ect. until the receiver acknowledges them.", let alone a sick delusional nonsense exhibited in the first quoted sentence.

In reality, the first resend is done once the original message expires. This first resend (and all the consecutive resends as well) will have TTL set to a maximum value, i.e. 28 days, (resulting in a more difficult PoW) and the next resend after that will be scheduled in 28 days * 2^currentresendnumber.

- original send: time T, original TTL, resend scheduled in 28 days
- first resend: time T+28 days, TTL=28 days, resend scheduled in 28 * 2^1 days (=56 days)
- second resend: time T+28+56 days (=84 days), TTL=28 days, resend scheduled in 28 * 2^2 days (=112 days)
- third resend: time T+28+56+112 days (=196 days), TTL=28 days, resend scheduled in 28 * 2^3 days (=224 days)
- fourth resend: time T+28+56+112+224 days (=420 days), TTL=28 days, resend scheduled in 28 * 2^4 days (=448 days)
- fifth resend: time T+28+56+112+224+448 days (=868 days), ...

So the message is not resent after 5, 10, 20 days as the client lies to you, but after 28, 84, 196 days. In other words, if a message is sent with the default 4 days TTL and the recipient happens to not run their BM client within this short period of time, they will have to wait for another 24 days to have a chance to receive your message. By that time the message may not be relevant to them anymore and if you deleted the message in the meantime it will never get resent at all.

So this feature is basically non-functional and useless for most of the users.

In the client it's stated that if the recipient isn't online for 2 days the client automatically resends the message. Will it have to calculate the PoW again? How is the TTL going to be accounted? From the new resend datetime?


In portable mode a "unwanted" file /pybitmessageqt.conf  will appear in the local dir.

To get rid of it, put an

export statement in your ~/.bashrc  for XDG_CONFIG_HOME

Then the  ~/.config/PyBitmessage   will stay absolutely empty in portable mode.

> ~/.config/PyBitmessage/pybitmessageqt.conf file is not a
> PyBitmessage configuration file.

> The pybitmessageqt.conf file is a qt thing, it stores the settings
> of the PyBM window size and whatever you can resize or move (with)in
> it. You may try to set the XDG_CONFIG_HOME env variable.

Try running it like this:
> XDG_CONFIG_HOME=/some/portable/path/ python bitmessagemain.py
> and check whether the pybitmessageqt.conf gets created there.



"nodes will delete an object that has a PoW for less than 5 minutes"

Objects that expire in less than 5 minutes have, for the purpose of PoW validation, a TTL of 5 minutes (line 468 - 469 shared.py).

Objects are deleted between 3 hours and 5 hours 3 minutes past their expiry (line 210 of shared.py; called by singleCleanerThread every 2 hours 3 minutes)

" The minimum TTL that PyBitmessage will currently allow for new  messages is 1 hour. "

This is for sending broadcasts, for normal messages it's 5 minutes (nodes will delete an object that has a PoW for less than 5 minutes) but the TTL label doesn't have sufficient precision to describe times lower than 1 hour. Also, the PoW adds some randomness to the TTL, and the expiration date is determined when the PoW starts rather than when it finishes so I don't recommend going as low as 5 minutes.

Peter Surda
Bitmessage core developer



http://bm6hsivrmdnxmw2f.onion/chan/gene … f97f3e2d93

back reference into BM  :cool:


> > Since the owner of a bitmessage address can set min pow, and
> > everyone owns same key in chans. What is to stop malicious person
> > setting pow to insane difficulty for a chan rendering it useless?

> How?
> A chan does not know it is a chan.
> > Chans' min POW is always 1

The client (sender and recipient) knows whether it's a chan and ignore the PoW difficulty settings (at least that's how PyBitmessage works, I don't know about other clients).

If one of them doesn't know it's a chan, that can cause other behaviour but let's ignore that because that's not the normal case.

At least in theory, it's possible to have chans with a different difficulty, but there is currently no way for the subscribers to agree on it, so you'd have to solve this problem before implementing it.

Peter Surda
Bitmessage core developer


> Correction:
> > nodes will delete an object that has a PoW for less than 5 minutes
> Objects that expire in less than 5 minutes have, for the purpose of
> PoW validation, a TTL of 5 minutes (line 468 - 469 shared.py).
> Objects are deleted between 3 hours and 5 hours 3 minutes past their
> expiry (line 210 of shared.py; called by singleCleanerThread every 2
> hours 3 minutes)
> ------------------------------------------------------
> Correction:
> > The minimum TTL that PyBitmessage will currently allow for new
> > messages is 1 hour.
> This is for sending broadcasts, for normal messages it's 5 minutes
> (nodes will delete an object that has a PoW for less than 5 minutes)
> but the TTL label doesn't have sufficient precision to describe
> times lower than 1 hour. Also, the PoW adds some randomness to the
> TTL, and the expiration date is determined when the PoW starts
> rather than when it finishes so I don't recommend going as low as 5
> minutes.


no portable mode possible

That is generally the case when you "install" - portability and installation are mutually exclusive.

BM Portablility only from the Master.zip from github. PAMAC install will give non-portable mode only.

very 1. line breaking error   "env  python22.7" in AUR PKGBUILD , hence zero votes yet.

The prepare section of PKGBUILD naively tries to fix some shebang lines resulting in "python22.7".

Lines 31 and 32 of PKGBUILD should be replaced with a single line something like:

find . -type f -print0 | xargs -0 sed -i 's#^\#!.*python.*$#\#!/usr/bin/python2#g'


above post refers to pyBM installed in Arch or a derivate like Manjaro or Parabola Linux.


### Running PyBitmessage as a daemon

If you find yourself using BMF all the time and don't want to see the
PyBitmessage UI, you can start PyBitmessage as a daemon.

First, add the following to the `[bitmessagesettings]` section of `keys.dat`:

    daemon = true

Next, start PyBitmessage like so:

    nohup python src/bitmessagemain.py &

This will start up PyBitmessage in the background without the QT GUI.


what is missing is the wiki-undocumented way to use green light BM over tor

with hidden service keys.dat setting


In daemon mode, see above, pyBM can be run by pypy, a fast python JIT-compiler.


set up BitMessage over TORnet - version 11 :

check the settings table at

https://bitmessage.org/wiki/FAQ#How_do_ … ice_on_Tor

Edit your torrc - on Ubuntu, Arch, etc. it's /etc/tor/torrc -
and add a hidden service for bitmessage:

HiddenServicePort     8444
HiddenServiceDir             /var/lib/tor/bitmessage

look up the content of        /var/lib/tor/bitmessage/hostname afterwards to fill in keys.dat  at onionhostname , e.g.

onionhostname = yufrurfrkv64.onion 

hint 1: delete hostname + privKey file, then restart tor to have a new .onion generated, then update "keys.dat" accordingly (i.e. copy the value).

hint 2: using SelekTOR or TorBrowser-bundle (hardened or soft) is not recommended for a quick success of getting the green traffic light in pyBM.
        Use "regular system tor" via systemD-KCM or CLI instead.

------------------------------------------------------------------------ torrc section for reference

############### This section is just for location-hidden services ###

## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.

# inside of the HiddenServiceDir
# you'll find the value for "onionhostname = " of keys.dat file , stored in file hostname

HiddenServiceDir   /var/lib/tor/bitmessage
HiddenServicePort  8444

#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80

#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80
#HiddenServicePort 22

----------------------------------------------------------------  end of section

----------------------------------------------------------------  example tor unit file for ref.:

Description=Anonymizing Overlay Network

ExecStart=/usr/bin/tor -f /etc/tor/torrc
ExecReload=/usr/bin/kill -HUP $MAINPID


----------------------------------------------------------------- end of unit file for ref.

Then restart tor , possibly using the selekTOR GUI.

----------------------------------------------------------------- edit the keys.dat

keys.dat is the control file of pyBM  -- SUMMARY:
----------------------------------------------------------------- example of keys.dat
settingsversion = 10

timeformat        = %%a, %%d %%b %%Y  %%I:%%M %%p
keysencrypted     = false
messagesencrypted = false

## put in YOUR value from HiddenServiceDir ---> /var/lib/tor/bitmessage/hostname
onionhostname = yufrurfrkv64.onion   

onionbindip =
onionport   = 8444
port        = 8444

sockshostname       =  ## otherwise you will only be able to accept one (simultaneous) connection. This will be fixed in the future.
sockslisten         = False      ## then no clearnet connects are made at all

socksport           = 9054
socksproxytype      = SOCKS5

socksusername       =
sockspassword       = without it a hacker can hack ure sox !
socksauthentication = False

sendoutgoingconnections = True

-------------------------------------------------------------------- end of example keys.dat

The first port (in this case 8444) you (then) have to put as
"onionport" variable into "keys.dat" file in PyBitmessage portable (or non-p.) dir.

onionport = 8444

The second port (in this case: 8444 , too)
is the port you have in PyBitmessage network settings
as "Listen for connections on port" (variable "port" in keys.dat).

port = 8444

The IP address (here is the internal (local) address of
your PyBitmessage.

If you run Tor and PyBitmessage on the same (local) system,
it will usually be

This address you then have to  put as "onionbindip"
into your keys.dat control file.

onionbindip =

If you want to accept  connections from both clearnet and tornet,
that step is not necessary, however.

onionhostname = hostname_of_YOUR_individual_hidden_service.onion # is taken from the file "hostname" in the respective hidden service directory, usually


  or whatever was defined in torrc (see above).

----------------------------------------------------------------- launch pyBM and that's it ! you're good to go. you might want to delete the knownNodes file.

--- remarks:

It can take a long time to actually get an incoming connection on
the hidden service, depending on circumstances and your other
settings, it may be hours. However, once your onion address makes it
onto the list in the network ("known nodes"), it should be faster.

PS. I just committed some minor fixes to the Tor code, you may want
to pull them.

Peter Surda
Bitmessage core developer


   You probably want to tell people what exactly to do to use onions,
   step by step. Lines in torrc, etc.   --> find it above!


  yeah, the minimum steps to get green light.

  using SelekTOR would be helpful as it is a GUI.
  If so, remember to have port to 9054 by default in both pyBM and SelekTOR.


This way you add a text-based user interface for Bitmessage so people can use it in the Terminal and (remotely) on servers where there is no graphical environment available.

For anyone who wants to set it up on a debian-based system:

Setup Command :

sudo apt-get install python openssl git python-pip
## Installation of dependencies.

sudo pip install python2-pythondialog

## Installation of a pythondialog version which works with the curses UI. The version from the Debian/Ubuntu repository does not work.

git clone https://github.com/Bitmessage/PyBitmessage ~/PyBitmessage

## This downloads PyBitmessage itself.

sudo ln -s ~/PyBitmessage/src/bitmessagemain.py /usr/local/bin/pybitmessage

## Sets up a symbolic link so you can execute PyBitmessage more easily

git -C ~/PyBitmessage pull

## Updates PyBitmessage

Usage:  You can start the curses-based interface by executing

pybitmessage -c

    You can switch tabs with the numbers 1-8 on your keyboard.
    Use the arrow keys to navigate through a list
    Press enter to read a message
    q to quit Bitmessage.


A note about security: using the Bitmessage API remotely

It is insecure to use a remote Bitmessage API directly, as all XMLRPC API calls go over the web using http in cleartext. That means when your Inbox is downloaded, or when you send a message, the content goes out over the web in plain text (unencrypted).

To protect against this, it is better to open an SSH tunnel to the host your PyBitmessage API/server is running on.

You can forward a local port on your computer to a destination port (typically 8442) on the server

(you only need to open up  port 8444 in your firewall on the server
to transmit to and from the Bitmessage peers,

you do not need to open up port 8442 for the API,
as the tunnel will connect locally to it on the server).

This command will forward port 8422 on your local computer to port 8442 on the server,
using SSH as a tunnel (typically port 22) to your Bitmessage server host:

ssh -N -L 8442:localhost:8442 <remote-bitmessage-server-hostname>

When you use an API based app such as Bmr,  when you  login to Bmr locally, just use localhost as the hostname and port 8442.

This will encrypt all communication to the API using SSH before it leaves your computer.
You can use whatever port you want locally (the first port defined above).

For windows: use Putty and setup an SSH tunnel for Source port 8442 and
Destination localhost:8442 under Tunnels. Then connect normally to your host via SSH Session

By doing this, you are effectively making the API calls directly on the server over SSH.

So they are not going out over the web using http to the API.

Login to PyBitmessage server (use SSH tunnel for remote access): ...


Don't confuse chans and deterministic identities.

While they seem similar there are differences under the hood
- in particular chans don't publish their public keys (encrypted or otherwise) on the network

while deterministic identities do.

This means that a deterministic identity is vulnerable to unsolicited messages
from anyone who has the address while a chan is not.

chans always use the first valid address generated
unlike deterministic identities.

with determinstic identities it is a hindrance to generate say 1000 addresses,
pick one of them, coordinate with your friends

* the passphrase,
* generation settings and
* which one of those 1000 addresses should be used as the chan;

and then disable/remove the 999 useless identities
(the more active identities you have the slower the message decryption process).

BM works with a sort of 'flood' model, where every node processes every messasge it gets.
If it can decrypt it, that message appears in your inbox.
If not, it must not have been meant for you, and it's passed on.

This is a clever design because it means that the whole message can be encrypted-
-including the 'to' and 'from' fields (that's a common challenge in anonymous communication systems).

Can I send a message to someone that is offline

Yes. However, if you go offline then they must come back online within 2 days of the message being sent.
Nodes delete data, and do not accept data, older than 2 days.

No, it's only as hard to discover as the chan name's complexity. 
Keep in mind that you can generate as many BM addresses based on that passphrase
as you want and then choose one at random yourself. 

Still, it's best to be complex and hard to guess. 
At that point your chan is as secure
as the opsec practiced by the other people you give the address/passphrase to.

Supposedly child pornographers, terrorists and the like are quite active on here using such secret chans.

If I create a chan with a name that is hard to guess,
will the contents of that chan be discovered by others?

I was hoping a secret chan name would keep the messages privy to those who know the chan name and address.

Is this true and are the messages encrypted?
Is there any way for interlopers to discover the address?


in other words:

nobody wants       ~/.config/PyBitmessage/pybitmessageqt.conf

in ~./bashrc

export XDG_CONFIG_HOME=/someShitPathToDumpCrapIn



Lately I have had problems similar to those listed above. I suspect that the error may be caused by a problem in the connection to the server. I recently started to use a proxy server, could this be because of this?

You are here » UBF -- The Ultimate Bitmessage Forum » pyBitmessage » BM help and documentation -- secret readme