My issue is very similar to:

#8

My system is OS X 10.8.2, Python 2.7.2

I'm getting the same complaint, but my SQLite version is pretty recent:

import sqlite3
sqlite3.sqlite_version
'3.7.12'
sqlite3.version
'2.6.0'
^D

full log of startup below:

[michael@varga (Fri Mar 29 21:39:18) ~/src/git/PyBitmessage]% ./bitmessagemain.py
Creating new config files in /Users/michael/Library/Application support/PyBitmessage/
Adding 66.65.120.151 to knownNodes based on DNS boostrap method
Adding 66.65.120.151 to knownNodes based on DNS boostrap method
Adding 60.242.109.18 to knownNodes based on DNS boostrap method
Adding 60.242.109.18 to knownNodes based on DNS boostrap method
Adding 76.27.132.40 to knownNodes based on DNS boostrap method
Adding 76.27.132.40 to knownNodes based on DNS boostrap method
Adding 84.48.88.49 to knownNodes based on DNS boostrap method
Adding 84.48.88.49 to knownNodes based on DNS boostrap method
reloading keys from keys.dat file
Created messages database file
Problem: The version of SQLite you have cannot store Null values. Please download and install the latest revision of your version of Python (for example, the latest Python 2.7 revision) and try again.
PyBitmessage will now exist very abruptly. You may now see threading errors related to this abrupt exit but the problem you need to solve is related to SQLite.

Exception KeyError: KeyError(4545462272,) in <module 'threading' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py'> ignored
[michael@varga (Fri Mar 29 21:41:56) ~/src/git/PyBitmessage]% python
Python 2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import sqlite3
sqlite3.sqlite_version
'3.7.12'
sqlite3.version
'2.6.0'
^D

Any suggestions?

In the Debian pybm script there's no need to (1) use a ‘heavy’ shell like bash, and (2) having an extra process around when it can easily be exec'ed away. So:

diff --git a/debian/pybm b/debian/pybm
index d806eed..95e61e5 100644
--- a/debian/pybm
+++ b/debian/pybm
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 cd /usr/share/pybitmessage
-python bitmessagemain.py
+exec python bitmessagemain.py

Cheers.

Debian 6.0.6
Kernel 3.7.8
Python 2.6.6
PyOpenSSL and OpenSSL installed.

python bitmessagemain.py
Traceback (most recent call last):
File "bitmessagemain.py", line 55, in
import highlevelcrypto
File "/home/rricci/Build/sources/PyBitmessage/highlevelcrypto.py", line 1, in
import pyelliptic
File "/home/rricci/Build/sources/PyBitmessage/pyelliptic/init.py", line 16, in
from .openssl import OpenSSL
File "/home/rricci/Build/sources/PyBitmessage/pyelliptic/openssl.py", line 427, in
raise Exception("Couldn't load the OpenSSL library. You must install it. Error message:"+err)
TypeError: cannot concatenate 'str' and 'exceptions.AttributeError' objects

This is just my list of things that I feel like should be put into bitmessage asap. I understand that bug fixes and other issues may have to come first.

• Known Nodes - The ability for the user to specify their own nodes (replacing the default known nodes when used).This is the only centralized thing in bitmessage and once it is gone, it can be advertised as fully decentralized.
• LAN/WAN - An option to switch between lan or wan operation. It should be an "or" option and not an "and" option. This also requires users to input their own known node when in LAN use.
• Flag/Star/Unread - Some way to mark messages for future reference. I would think that marking a message unread or the ability to flag/star it would be the easiest way to do this.

If I send a message and come back later I might see this under the Status column of my Sent messages tab:

Acknowledgement of the message received just now.

It would be so much more useful to see the status message with my local time or UTC as:

Acknowledgement of the message received at 9:57 PM PST.

If you select text in a richtext message the QTextEdit retains the text's formatting if you view another message. So, if you highlight white text on a blue background, and then select (or receive) a plaintext message, the plaintext will be white.

The solution I found to work is to use a QTextDocument when you want to change textEditInboxMessage.

E.g., MyForm.tableWidgetInboxItemClicked would be something like:

def tableWidgetInboxItemClicked(self):
    currentRow = self.ui.tableWidgetInbox.currentRow()
    if currentRow >= 0:
        fromAddress = str(self.ui.tableWidgetInbox.item(currentRow,1).data(Qt.UserRole).toPyObject())

        '''QTextDocument doesn't have setText(), which guessed whether to use richtext or plaintext'''

        message = QTextDocument()
        if decodeAddress(fromAddress)[3] in prefsAddressesToDisplayAsRichtext:
            message.setHtml(self.ui.tableWidgetInbox.item(currentRow,2).data(Qt.UserRole).toPyObject())
        else:
            message.setPlainText(self.ui.tableWidgetInbox.item(currentRow,2).data(Qt.UserRole).toPyObject())

        self.ui.textEditInboxMessage.setDocument(message)

An option could be added to items in Address Book and Subscriptions to set whether or not to view messages as richtext, instead of by default.

I also tried (re)setting the stylesheet with self.ui.textEditInboxMessage.setStyleSheet('color: black;') between messages, but highlighting richtext still lead to styled plaintext.

If you send and receive a lot of messages with the same person, it is hard to follow the thread.

It would help, if you would save the connection between a message in your inbox and the sent answer.

Or even better: show messages in a conversation like in Thunderbird (invented by gmail)

Currently, it appears that when broadcasts are first received the client tries to decrypt them with the addresses in the user's subscriptions.

This could be changed so that whenever a new address is added to the user's subscriptions, it tries again to decypt the broadcast messages in inventory with the new address. This would show any broadcasts from that address for the last ~2 days.

This would be useful for new users starting up the application, then finding and adding the mailing list addresses to their subscriptions. I noticed when starting a new client, by the time I added the common mailing lists, all of the broadcasts had already been processed by the client. I then would only get new broadcasts from that time forward. New users would be more likely to stay with bitmessage if they can immediately get the recent broadcasts instead of waiting for hours for a new one to be sent.

I tried to install OpenSSL via brew, but no effect. I exported needed PATH for it.

On Linux, Pybitmessage uses ~/.PyBitmessage. Instead, it should respect the XDG Base Directory Specification, which means ~/.config/pybitmessage ($XDG_CONFIG_HOME) for keys.dat and so on.

I just pulled the latest change (commit 4577c6a), and the program terminates without showing the window.

Here's the log:
Loading existing config files from /home/sibbo/.PyBitmessage/
Adding 66.65.120.151 to knownNodes based on DNS boostrap method
[...]
Adding 60.242.109.18 to knownNodes based on DNS boostrap method
reloading keys from keys.dat file
Database file already exists.
Traceback (most recent call last):
File "bitmessagemain.py", line 5135, in
myapp = MyForm()
File "bitmessagemain.py", line 3599, in init
newItem = myTableWidgetItem(unicode(strftime(config.get('bitmessagesettings', 'timeformat'),localtime(int(received)))))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)

The ability for the user to change settings such as default known nodes, maximumAgeOfAnObjectThatIAmWillingToAccept, and other coded values from the UI would be nice.

Settings > Advanced could be one place to house all of these settings.

With those two settings, a user could connect to a knownnode that stores messages for long periods of time (month/year) and obtain messages that they missed while they had their client offline for an extended period of time.

Because of the - in addresses, copy and paste is usability issue since you can't double-click to select the address, since it doesn't pick up the BM- part connected by the -. You can try to double click the main part of the address in BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb and see, BM- is omitted. You should deprecate the -

I am also seeing the behavior described here:

https://pay.reddit.com/r/bitmessage/comments/1b73hp/doesnt_work_after_restart/

Processed messages, broadcasts and public keys remain at zero indefinitely despite having multiple connections (green status).

If I delete knownnodes.dat and messages.dat, then restart, I regain the ability to both send and receive but of course at the cost of losing all my messages, contacts and subscriptions.

Example output is listed below:

Loading existing config files from /home/motters/.PyBitmessage/
Adding 66.65.120.151 to knownNodes based on DNS boostrap method
Adding 66.65.120.151 to knownNodes based on DNS boostrap method
Adding 66.65.120.151 to knownNodes based on DNS boostrap method
Adding 76.27.132.40 to knownNodes based on DNS boostrap method
Adding 76.27.132.40 to knownNodes based on DNS boostrap method
Adding 76.27.132.40 to knownNodes based on DNS boostrap method
Adding 84.48.88.49 to knownNodes based on DNS boostrap method
Adding 84.48.88.49 to knownNodes based on DNS boostrap method
Adding 84.48.88.49 to knownNodes based on DNS boostrap method
Adding 60.242.109.18 to knownNodes based on DNS boostrap method
Adding 60.242.109.18 to knownNodes based on DNS boostrap method
Adding 60.242.109.18 to knownNodes based on DNS boostrap method
reloading keys from keys.dat file
Database file already exists.
Watching for ackdata 4d5430b3245da07d95d10459c6f0ace0bf536ce2fd6984126161635e6d9aebf9
Listening for incoming connections.
Trying an outgoing connection to 84.203.34.195 : 8444
Could NOT connect to 84.203.34.195 during outgoing attempt. timed out
Trying an outgoing connection to 24.184.210.205 : 8444
Could NOT connect to 24.184.210.205 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 91.121.102.56 : 8444
Could NOT connect to 91.121.102.56 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 83.172.25.92 : 8444
Could NOT connect to 83.172.25.92 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 94.19.51.235 : 8444
Could NOT connect to 94.19.51.235 during outgoing attempt. timed out
Trying an outgoing connection to 184.35.10.237 : 8444
<main.outgoingSynSender object at 0x173d560> connected to 184.35.10.237 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 24369200 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00go\xef\xc8\xd1\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf5h\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xb8#\n\xed \xfc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
Trying an outgoing connection to 216.67.170.48 : 8444
remoteCommand 'verack' from 184.35.10.237
verack received
remoteCommand 'version' from 184.35.10.237
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Sending verack
Connection fully established with 184.35.10.237 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 155 entries.
Sending huge inv message with 3393 objects to just this one peer
remoteCommand 'addr' from 184.35.10.237
addr message contains 130 IP addresses.
knownNodes currently has 326 nodes for this stream.
remoteCommand 'inv' from 184.35.10.237
inv message lists 3678 objects.
remoteCommand 'addr' from 184.35.10.237
addr message contains 1 IP addresses.
knownNodes currently has 326 nodes for this stream.
sending getdata to retrieve object with hash: cd4627c58cec29533b997342743acc20ae8eec8dc180aaf27357a842362cf77c
(concerning 184.35.10.237) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3674
Could NOT connect to 216.67.170.48 during outgoing attempt. timed out
Trying an outgoing connection to 79.2.244.63 : 8444
Could NOT connect to 79.2.244.63 during outgoing attempt. timed out
Trying an outgoing connection to 107.1.128.34 : 8444
Could NOT connect to 107.1.128.34 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 84.46.18.197 : 8444
Could NOT connect to 84.46.18.197 during outgoing attempt. [Errno 113] No route to host
Trying an outgoing connection to 93.85.236.17 : 6002
Could NOT connect to 93.85.236.17 during outgoing attempt. timed out
Trying an outgoing connection to 99.94.167.98 : 8444
Could NOT connect to 99.94.167.98 during outgoing attempt. timed out
Trying an outgoing connection to 74.132.73.137 : 8444
Could NOT connect to 74.132.73.137 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 88.128.80.2 : 8444
Could NOT connect to 88.128.80.2 during outgoing attempt. [Errno 113] No route to host
Trying an outgoing connection to 202.2.108.245 : 8444
Could NOT connect to 202.2.108.245 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 109.95.105.15 : 8443
<main.outgoingSynSender object at 0x173d560> connected to 109.95.105.15 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 24369488 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00g\xd17 Q\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf5\xbc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xffm_i\x0f \xfb\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
Trying an outgoing connection to 78.34.98.56 : 8444
remoteCommand 'verack' from 109.95.105.15
verack received
Could NOT connect to 78.34.98.56 during outgoing attempt. [Errno 113] No route to host
remoteCommand 'version' from 109.95.105.15
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Trying an outgoing connection to 24.116.20.132 : 8444
Sending verack
Connection fully established with 109.95.105.15 8443
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 139 entries.
Sending huge inv message with 3393 objects to just this one peer
remoteCommand 'addr' from 109.95.105.15
addr message contains 74 IP addresses.
knownNodes currently has 326 nodes for this stream.
remoteCommand 'inv' from 109.95.105.15
inv message lists 3653 objects.
sending getdata to retrieve object with hash: 4a7ea78ed4182675246e0990579fb0a4e5293a22555c8cc399085c805035149b
(concerning 109.95.105.15) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3645
remoteCommand 'addr' from 109.95.105.15
addr message contains 1 IP addresses.
knownNodes currently has 326 nodes for this stream.
sending getdata to retrieve object with hash: c73b1a5d628f9459f7eba14894ea916af0a6abf1cec9acfd35f551dd6c6d787d
(concerning 109.95.105.15) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3638
remoteCommand 'addr' from 109.95.105.15
addr message contains 1 IP addresses.
knownNodes currently has 326 nodes for this stream.
sending getdata to retrieve object with hash: 94e2fa312a07b9c6d5cfcd9b6d90dc40471241182cee6629add3ab55a98d24e1
(concerning 109.95.105.15) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3619
Could NOT connect to 24.116.20.132 during outgoing attempt. timed out
Trying an outgoing connection to 78.34.111.2 : 8444
Could NOT connect to 78.34.111.2 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 97.83.25.197 : 8444
Could NOT connect to 97.83.25.197 during outgoing attempt. timed out
Trying an outgoing connection to 130.243.164.105 : 8444
Could NOT connect to 130.243.164.105 during outgoing attempt. timed out
Trying an outgoing connection to 165.228.66.206 : 8444
Could NOT connect to 165.228.66.206 during outgoing attempt. timed out
Trying an outgoing connection to 216.252.204.133 : 8444
Could NOT connect to 216.252.204.133 during outgoing attempt. timed out
Trying an outgoing connection to 128.46.95.38 : 8444
Could NOT connect to 128.46.95.38 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 78.42.98.175 : 8444
<main.outgoingSynSender object at 0x173d560> connected to 78.42.98.175 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 24369776 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00g\x8e\x08\xef\xfe\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf6!\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xffN_b\xaf \xfc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
remoteCommand 'verack' from 78.42.98.175
verack received
remoteCommand 'version' from 78.42.98.175
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Sending verack
Connection fully established with 78.42.98.175 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 143 entries.
Sending huge inv message with 3393 objects to just this one peer
remoteCommand 'addr' from 78.42.98.175
addr message contains 80 IP addresses.
added new node 71.138.132.206 to knownNodes in stream 1
Broadcasting addr with 1 entries.
knownNodes currently has 327 nodes for this stream.
Trying an outgoing connection to 64.147.229.246 : 8444
remoteCommand 'inv' from 78.42.98.175
inv message lists 3654 objects.
sending getdata to retrieve object with hash: a854e2f9ad721ae4996bbc69334699bd20152cabdd54a4a77d1fb5683ce62188
(concerning 78.42.98.175) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3647
remoteCommand 'addr' from 78.42.98.175
addr message contains 1 IP addresses.
knownNodes currently has 327 nodes for this stream.
sending getdata to retrieve object with hash: 794669e4f5f5953004e117032512fb227df4eb2fd0c270dcfeb5eba845775083
(concerning 78.42.98.175) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3616
Could NOT connect to 64.147.229.246 during outgoing attempt. timed out
Trying an outgoing connection to 94.102.53.175 : 8444
Could NOT connect to 94.102.53.175 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 62.212.99.86 : 8444
Could NOT connect to 62.212.99.86 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 84.203.42.200 : 8444
Could NOT connect to 84.203.42.200 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 188.174.51.226 : 8444
Could NOT connect to 188.174.51.226 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 205.118.82.86 : 8444
Could NOT connect to 205.118.82.86 during outgoing attempt. timed out
Trying an outgoing connection to 94.26.188.199 : 8444
remoteCommand 'addr' from 78.42.98.175
addr message contains 1 IP addresses.
knownNodes currently has 327 nodes for this stream.
sending getdata to retrieve object with hash: df16ab800be7d2fa9088789b2f2a7a502213f97ef0885fcf5a1607c8cff27fb2
(concerning 78.42.98.175) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3613
Could NOT connect to 94.26.188.199 during outgoing attempt. timed out
Trying an outgoing connection to 87.117.176.162 : 8444
Status bar: Doing housekeeping (Flushing inventory in memory to disk...)
Could NOT connect to 87.117.176.162 during outgoing attempt. timed out
Trying an outgoing connection to 212.218.65.223 : 8444
Could NOT connect to 212.218.65.223 during outgoing attempt. timed out
Trying an outgoing connection to 84.48.88.49 : 8444
remoteCommand 'addr' from 109.95.105.15
addr message contains 1 IP addresses.
added new node 188.234.2.221 to knownNodes in stream 1
Broadcasting addr with 1 entries.
knownNodes currently has 328 nodes for this stream.
sending getdata to retrieve object with hash: 093c9437aca7ca096660d06223adb313961ac0f4fba5884daaa968a8aa74f3be
(concerning 109.95.105.15) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3607
Could NOT connect to 84.48.88.49 during outgoing attempt. timed out
Trying an outgoing connection to 217.82.221.162 : 8444
Could NOT connect to 217.82.221.162 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 94.254.2.145 : 8444
Could NOT connect to 94.254.2.145 during outgoing attempt. timed out
Trying an outgoing connection to 66.65.120.151 : 8080
Could NOT connect to 66.65.120.151 during outgoing attempt. timed out
Trying an outgoing connection to 173.79.213.105 : 8444
Could NOT connect to 173.79.213.105 during outgoing attempt. timed out
Trying an outgoing connection to 31.23.154.231 : 8444
Could NOT connect to 31.23.154.231 during outgoing attempt. timed out
Trying an outgoing connection to 173.66.8.105 : 8444
<main.outgoingSynSender object at 0x173d560> connected to 173.66.8.105 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 24370208 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00g\xe5\x8e\x93\xaf\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf6\xed\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xadB\x08i \xfc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
Trying an outgoing connection to 37.45.20.109 : 8444
remoteCommand 'verack' from 173.66.8.105
verack received
remoteCommand 'version' from 173.66.8.105
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Sending verack
Connection fully established with 173.66.8.105 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 142 entries.
Sending huge inv message with 3392 objects to just this one peer
remoteCommand 'addr' from 173.66.8.105
addr message contains 150 IP addresses.
added new node 74.61.178.227 to knownNodes in stream 1
Broadcasting addr with 1 entries.
knownNodes currently has 329 nodes for this stream.
Could NOT connect to 37.45.20.109 during outgoing attempt. timed out
Trying an outgoing connection to 95.88.10.54 : 8444
Could NOT connect to 95.88.10.54 during outgoing attempt. [Errno 113] No route to host
Trying an outgoing connection to 212.63.218.1 : 8444
remoteCommand 'pong' from 184.35.10.237
sending getdata to retrieve object with hash: 9cfc5ab7b675fc4b7d7e1d5cb0396299747d3d261fa1beda9f6695694e81c296
(concerning 184.35.10.237) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3666
Could NOT connect to 212.63.218.1 during outgoing attempt. timed out
Trying an outgoing connection to 84.135.171.5 : 8444
Could NOT connect to 84.135.171.5 during outgoing attempt. [Errno 113] No route to host
Trying an outgoing connection to 94.198.135.29 : 8444
Could NOT connect to 94.198.135.29 during outgoing attempt. timed out
Trying an outgoing connection to 95.72.27.203 : 8444
remoteCommand 'addr' from 78.42.98.175
addr message contains 1 IP addresses.
knownNodes currently has 329 nodes for this stream.
sending getdata to retrieve object with hash: 97c01a870dd4307b1fd3f10bc822cea27b9083f65b665e122ac066d5bf39c318
(concerning 78.42.98.175) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3604
Could NOT connect to 95.72.27.203 during outgoing attempt. timed out
Trying an outgoing connection to 117.198.69.75 : 8444
Could NOT connect to 117.198.69.75 during outgoing attempt. timed out
Trying an outgoing connection to 217.118.78.80 : 8444
Could NOT connect to 217.118.78.80 during outgoing attempt. timed out
Trying an outgoing connection to 86.56.161.249 : 8444
<main.outgoingSynSender object at 0x173d560> connected to 86.56.161.249 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 24370352 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00g\x19-\xa8\xb7\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf7h\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xffV8\xa1\xf9 \xfc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
Trying an outgoing connection to 95.119.15.92 : 8444
remoteCommand 'verack' from 86.56.161.249
verack received
remoteCommand 'version' from 86.56.161.249
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Sending verack
Connection fully established with 86.56.161.249 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 141 entries.
Sending huge inv message with 3392 objects to just this one peer
remoteCommand 'addr' from 86.56.161.249
addr message contains 74 IP addresses.
Strange occurance: The port specified in an addr message 8444 does not match the port 8445 that this program (or some other peer) used to connect to it 87.236.30.170 . Perhaps they changed their port or are using a strange NAT configuration.
knownNodes currently has 329 nodes for this stream.
remoteCommand 'inv' from 86.56.161.249
inv message lists 3657 objects.
sending getdata to retrieve object with hash: c190abe1123c99bb8ec565f6bb52b65d2d906c6ac412667445f3fdc68df5aab0
(concerning 86.56.161.249) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3653
remoteCommand 'addr' from 86.56.161.249
addr message contains 1 IP addresses.
knownNodes currently has 329 nodes for this stream.
sending getdata to retrieve object with hash: 9d4df664939a40aab2df8121987ca40773519c3a3ef7dd5845f9f7f0993c4be6
(concerning 86.56.161.249) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3645
Could NOT connect to 95.119.15.92 during outgoing attempt. timed out
Trying an outgoing connection to 213.47.137.217 : 8444
<main.outgoingSynSender object at 0x173d560> connected to 213.47.137.217 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 24370496 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00g\xb7\xd6R\xb3\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf7|\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xd5/\x89\xd9 \xfc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
Trying an outgoing connection to 60.242.109.18 : 8444
remoteCommand 'verack' from 213.47.137.217
verack received
remoteCommand 'version' from 213.47.137.217
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Sending verack
Connection fully established with 213.47.137.217 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 151 entries.
Sending huge inv message with 3392 objects to just this one peer
remoteCommand 'addr' from 213.47.137.217
addr message contains 84 IP addresses.
knownNodes currently has 329 nodes for this stream.
remoteCommand 'inv' from 213.47.137.217
inv message lists 3616 objects.
sending getdata to retrieve object with hash: 15e38230a80a3626d05138216e3e81835c8108dea9f7fec3d9e2e83111026f37
(concerning 213.47.137.217) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3606
remoteCommand 'addr' from 213.47.137.217
addr message contains 1 IP addresses.
knownNodes currently has 329 nodes for this stream.
sending getdata to retrieve object with hash: 24d28a7005702fd050f30dd81a870cc0cb46b207f9d384f33f5f6fe38a9ac9f9
(concerning 213.47.137.217) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3599
remoteCommand 'addr' from 109.95.105.15
addr message contains 1 IP addresses.
knownNodes currently has 329 nodes for this stream.
sending getdata to retrieve object with hash: 2d7701688c99d894c8f00c489842b174a75bd39cac8cf10b10c76cc53689fd56
(concerning 109.95.105.15) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3566
Could NOT connect to 60.242.109.18 during outgoing attempt. timed out
Trying an outgoing connection to 178.95.122.237 : 8444
Status bar: Doing housekeeping (Flushing inventory in memory to disk...)
Could NOT connect to 178.95.122.237 during outgoing attempt. timed out
Trying an outgoing connection to 178.37.40.251 : 8444
remoteCommand 'addr' from 184.35.10.237
addr message contains 1 IP addresses.
knownNodes currently has 329 nodes for this stream.
sending getdata to retrieve object with hash: 10e913a3660fd1890a8c89946cc5185a08f4f5a22537e2019ea31fa2c5a05adc
(concerning 184.35.10.237) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3653
Could NOT connect to 178.37.40.251 during outgoing attempt. timed out
Trying an outgoing connection to 74.83.46.202 : 25565
Could NOT connect to 74.83.46.202 during outgoing attempt. timed out
Trying an outgoing connection to 80.149.232.250 : 8444
Could NOT connect to 80.149.232.250 during outgoing attempt. timed out
Trying an outgoing connection to 194.242.100.99 : 8444
remoteCommand 'addr' from 184.35.10.237
addr message contains 1 IP addresses.
knownNodes currently has 329 nodes for this stream.
sending getdata to retrieve object with hash: 38222869f4efd3306b53557b53507f2cb5e3992aa39cef3ce6112c18e5d0dab6
(concerning 184.35.10.237) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3651
Could NOT connect to 194.242.100.99 during outgoing attempt. timed out
Trying an outgoing connection to 84.156.69.81 : 8444
<main.outgoingSynSender object at 0x173d560> connected to 84.156.69.81 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 24370928 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00g\x8a,\xed\x1d\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf7\xf5\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xffT\x9cEQ \xfc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
Trying an outgoing connection to 85.183.60.17 : 8444
remoteCommand 'verack' from 84.156.69.81
verack received
<main.outgoingSynSender object at 0x173d560> connected to 85.183.60.17 during an outgoing attempt.
The streamNumber of this sendDataThread (ID: 33992784 ) at setup() is 1
Sending version packet: '\xe9\xbe\xb4\xd9version\x00\x00\x00\x00\x00\x00\x00\x00g\xf5\xdd_z\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00Q[\xf7\xf5\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xffU\xb7<\x11 \xfc\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x7f\x00\x00\x01 \xfc\xe1\xd3\xaf^\xa1\xe7\xdfl\x14/PyBitmessage:0.2.7/\x01\x01'
remoteCommand 'version' from 84.156.69.81
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Sending verack
Connection fully established with 84.156.69.81 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 155 entries.
remoteCommand 'verack' from 85.183.60.17
verack received
Sending huge inv message with 3392 objects to just this one peer
remoteCommand 'addr' from 84.156.69.81
addr message contains 8 IP addresses.
Strange occurance: The port specified in an addr message 1337 does not match the port 1227 that this program (or some other peer) used to connect to it 94.6.26.59 . Perhaps they changed their port or are using a strange NAT configuration.
knownNodes currently has 329 nodes for this stream.
Connection closed. Closing receiveData thread.
removed self (a receiveDataThread) from ConnectionList
Updating network status tab with current connections count: 6
remoteCommand 'version' from 85.183.60.17
Remote node useragent: /PyBitmessage:0.2.7/ stream number: 1
Sending verack
Connection fully established with 85.183.60.17 8444
broadcasting addr from within connectionFullyEstablished function.
Broadcasting addr with 1 entries.
Sending addr with 151 entries.
Sending huge inv message with 3392 objects to just this one peer
remoteCommand 'addr' from 85.183.60.17
addr message contains 118 IP addresses.
Strange occurance: The port specified in an addr message 8444 does not match the port 8555 that this program (or some other peer) used to connect to it 80.36.134.184 . Perhaps they changed their port or are using a strange NAT configuration.
knownNodes currently has 329 nodes for this stream.
Trying an outgoing connection to 94.143.40.37 : 8444
Could NOT connect to 94.143.40.37 during outgoing attempt. [Errno 111] Connection refused
Trying an outgoing connection to 119.74.140.13 : 8444
self.sock.sendall failed
sendDataThread thread <main.sendDataThread object at 0x173def0> ending now
Could NOT connect to 119.74.140.13 during outgoing attempt. timed out
Trying an outgoing connection to 77.120.136.154 : 8444
remoteCommand 'addr' from 78.42.98.175
addr message contains 1 IP addresses.
knownNodes currently has 329 nodes for this stream.
sending getdata to retrieve object with hash: 94ea0bebbd6a3e4a04142dbcfa4385e45d1ea997eca58dd3d337f93b7394604f
(concerning 78.42.98.175) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3578
Could NOT connect to 77.120.136.154 during outgoing attempt. timed out
Trying an outgoing connection to 31.23.139.167 : 8444
remoteCommand 'addr' from 78.42.98.175
addr message contains 1 IP addresses.
added new node 78.43.190.17 to knownNodes in stream 1
Broadcasting addr with 1 entries.
knownNodes currently has 330 nodes for this stream.
sending getdata to retrieve object with hash: 0ad12a464b248d2adbbf789cd639a46a275dc901aee49b6aa7d7619be92322e3
(concerning 78.42.98.175) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3559
remoteCommand 'addr' from 213.47.137.217
addr message contains 1 IP addresses.
knownNodes currently has 330 nodes for this stream.
sending getdata to retrieve object with hash: 0ca3d7534d3e6d92003c12a79bcbcdf62719e98e2c803d021f7710a145fc3ce6
(concerning 213.47.137.217) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3579
remoteCommand 'addr' from 86.56.161.249
addr message contains 1 IP addresses.
knownNodes currently has 330 nodes for this stream.
sending getdata to retrieve object with hash: ea72ea6305abda66ebb59aa26773d16b06cc89612f30fa1766da6a1bf45e3e0c
(concerning 86.56.161.249) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3640
remoteCommand 'addr' from 184.35.10.237
addr message contains 1 IP addresses.
knownNodes currently has 330 nodes for this stream.
sending getdata to retrieve object with hash: 7ea511c2b050a6e0bfdf1d991c4c024aa1909a76bb6f729b20e22801e598eb2f
(concerning 184.35.10.237) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3648
remoteCommand 'addr' from 109.95.105.15
addr message contains 1 IP addresses.
knownNodes currently has 330 nodes for this stream.
sending getdata to retrieve object with hash: 49b215ef654e188c70567179d35a49106010acb04d3b3b09a5d66a2cea3572c6
(concerning 109.95.105.15) number of objectsThatWeHaveYetToCheckAndSeeWhetherWeAlreadyHave is now 3561
Could NOT connect to 31.23.139.167 during outgoing attempt. timed out
Trying an outgoing connection to 212.46.239.90 : 8444

Seems to copy some of the top line's qualities.

I working in LAN without Internet access. But, initially, bitmessage sets the initial point of locate on the Internet and not work. If knownnodes.dat has been change using python, all working it's good. Need ui interface for change this file.

Trying PyBitmessage on an updated install of Mint Linux 12, and I get the following SQLite error:

python bitmessagemain.py 
Loading config files from /home/philip/.PyBitmessage/
reloading my address hashes
Database file already exists.
Problem: The version of SQLite you have cannot store Null values. Please download and install the latest revision of your version of Python (for example, the latest Python 2.7 revision) and try again. Exiting.
Exception KeyError: KeyError(-1226089616,) in <module 'threading' from '/usr/lib/python2.7/threading.pyc'> ignored

(python:1860): GLib-CRITICAL **: g_main_context_pop_thread_default: assertion `g_queue_peek_head (stack) == context' failed

With my client, When sending getdata, between thousands of correct messages, I receive this header:
[-23, -66, -76, -39, 109, 115, 103, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 12, 60, -61, 93, -106, 83, 104] (Printed as unsigned byte[])
The magic bytes are correct, the command is msg, the length is 801987, but the hash is wrong.
There is no magic value directly after this message, the next starts 50 to 2000 bytes later, randomly altering every try. There are about 500 magic values inside the encrypted bytes. Sure, part of them are just randomly there. But I guess a bunch of them also represent real messages. The msg message itself contains a valid time field, and the stream is one.
Is it possible, that PyBitmessage sends objects with wrong length information?

Could the text to add a new address on the address book tab be changed to say "New" instead of "Add". It is confusing to users when they go to the address book to send a message to an address.

Hey, I'm not sure how hard this will be to implement but my hunch is "not very". Still digging into the codebase and trying to figure out how it all works.

Anyway; Bitmessage has support for broadcast addresses that people can subscribe to, which can also receive mail as normal addresses.

If there were an action-hook for addresses to call as they receive mail, then one could configure an address that auto-broadcasts any message it receives, creating a mailing-list address. If sender's addresses were included by default (at mailing-address-owner's option), it'd behave like a normal list. If not, then it'd be a sort of anon-list, where senders choose whether to include their address/id in their signatures.

This feature would really expand my ability to sell bitmessage to others, and it would provide an easy-in to new people to bitmessage: join bitmessage and discuss it internally on the bitmessage network, rather than on the subreddit or public forum!

Anyways. I'll keep digging in my spare time and perhaps I'll find a way to implement this. It would be doable with an RPC interface too, of course. :)

After pulling c87fd93 I can't delete contacts in the address book. While trying repeatedly to delete a single contact something happened and every address except the one intended was deleted.

I haven't had time to dig deeper, I'll update if I find something.

fixes:

def hash_160(string):
   intermed = hashlib.sha256(string).digest()
   ripemd160 = hashlib.new('ripemd160')
   ripemd160.update(intermed)
   return ripemd160.digest()

and

def hex_to_point(h): return (decode(h[2:66],16),decode(h[66:],16))

It would be really cool if there were a message encoding type to transfer files, in simple binary format.

I always get confused, if I am looking at the inbox or the sentbox.

It would help the eye a lot, if you could define another backgroundcolor for the sentbox

Please add indention to replies like in most other email programs

• Application Indicator
  This provides access to key features of Bitmessage.
  • mono icon (compare /usr/share/icons/ubuntu-mono-dark/status/24)
• Messaging menu
  The entry could look like this:
  • Pybitmessage
    • New message
    • Contacts
    • 1 new message (from John Doe)
• Launcher shortcut
  This is very easy to implement when the application supports command line options.
• Notify OSD
  This informs the user about new messages and connection loss.
• Most importantly, Ubuntu users have no easy way to install Pybitmessage. Even though it may be too early to get Pybitmessage into the Debian repositories, there are several options to make it more convenient to install this application:
  • Provide a single official .deb file
  • Provide a portable statically linked executable
  • Provide a PPA

The text prepended in pseudo-mailing-lists, "Message ostensibly from", causes the textEditInboxMessage qTextEdit widget to interpet all messages as text, due to QTextEdit::setText being used.

It would be nice if you could provide signed git tags for new releases.

Please, make a UPnP support standart.

Clicking on the Manage Keys button results in the pop-up appearing twice.

Probable cause is that both line 3293 and 3295 are identical in bitmessagemain.py causing the action to be added twice.

(Not used to Qt but I think that should solve it :) )

When setting this option to true the application does not minimize itself on startup, which I expect is the intended behavior.

Are the getbiginv and the ping and pong commands used? I have seen the sendbiginv method, but nothing to send a biginv request. And I have seen a sendpong method, but nothing to send a ping. Does a client have to implement these?

Let me just quote what happens when I run pep8 bitmessagemain.py:

bitmessagemain.py:7:80: E501 line too long (122 > 79 characters)
bitmessagemain.py:11:80: E501 line too long (82 > 79 characters)
bitmessagemain.py:11:52: E261 at least two spaces before inline comment
bitmessagemain.py:11:53: E262 inline comment should start with '# '
bitmessagemain.py:12:80: E501 line too long (188 > 79 characters)
bitmessagemain.py:12:47: E261 at least two spaces before inline comment
bitmessagemain.py:12:48: E262 inline comment should start with '# '
bitmessagemain.py:13:80: E501 line too long (261 > 79 characters)
bitmessagemain.py:13:43: E261 at least two spaces before inline comment
bitmessagemain.py:13:44: E262 inline comment should start with '# '
bitmessagemain.py:14:80: E501 line too long (80 > 79 characters)
bitmessagemain.py:14:51: E261 at least two spaces before inline comment
bitmessagemain.py:14:52: E262 inline comment should start with '# '
bitmessagemain.py:15:48: E261 at least two spaces before inline comment
bitmessagemain.py:15:49: E262 inline comment should start with '# '
bitmessagemain.py:16:80: E501 line too long (181 > 79 characters)
bitmessagemain.py:16:58: E261 at least two spaces before inline comment
bitmessagemain.py:16:59: E262 inline comment should start with '# '
bitmessagemain.py:17:80: E501 line too long (151 > 79 characters)
bitmessagemain.py:17:41: E261 at least two spaces before inline comment
bitmessagemain.py:17:42: E262 inline comment should start with '# '
bitmessagemain.py:37:14: E261 at least two spaces before inline comment
bitmessagemain.py:37:15: E262 inline comment should start with '# '
bitmessagemain.py:44:80: E501 line too long (92 > 79 characters)
bitmessagemain.py:44:14: E261 at least two spaces before inline comment
bitmessagemain.py:44:15: E262 inline comment should start with '# '
bitmessagemain.py:48:28: E261 at least two spaces before inline comment
bitmessagemain.py:48:29: E262 inline comment should start with '# '
bitmessagemain.py:51:80: E501 line too long (137 > 79 characters)
bitmessagemain.py:52:1: E302 expected 2 blank lines, found 1
bitmessagemain.py:56:19: E231 missing whitespace after ','
bitmessagemain.py:63:80: E501 line too long (88 > 79 characters)
bitmessagemain.py:64:80: E501 line too long (112 > 79 characters)
bitmessagemain.py:64:69: E261 at least two spaces before inline comment
bitmessagemain.py:64:70: E262 inline comment should start with '# '
bitmessagemain.py:68:80: E501 line too long (99 > 79 characters)
bitmessagemain.py:72:80: E501 line too long (83 > 79 characters)
bitmessagemain.py:74:80: E501 line too long (181 > 79 characters)
bitmessagemain.py:75:80: E501 line too long (87 > 79 characters)
bitmessagemain.py:77:80: E501 line too long (83 > 79 characters)
bitmessagemain.py:81:80: E501 line too long (83 > 79 characters)
bitmessagemain.py:83:80: E501 line too long (95 > 79 characters)
bitmessagemain.py:86:80: E501 line too long (104 > 79 characters)
bitmessagemain.py:91:80: E501 line too long (92 > 79 characters)
bitmessagemain.py:94:80: E501 line too long (97 > 79 characters)
bitmessagemain.py:97:80: E501 line too long (92 > 79 characters)
bitmessagemain.py:98:80: E501 line too long (87 > 79 characters)
bitmessagemain.py:99:80: E501 line too long (172 > 79 characters)
bitmessagemain.py:99:32: E261 at least two spaces before inline comment
bitmessagemain.py:99:33: E262 inline comment should start with '# '
bitmessagemain.py:100:80: E501 line too long (93 > 79 characters)
bitmessagemain.py:101:80: E501 line too long (96 > 79 characters)
bitmessagemain.py:102:80: E501 line too long (96 > 79 characters)
bitmessagemain.py:103:80: E501 line too long (110 > 79 characters)
bitmessagemain.py:105:80: E501 line too long (80 > 79 characters)
bitmessagemain.py:106:80: E501 line too long (91 > 79 characters)
bitmessagemain.py:109:80: E501 line too long (96 > 79 characters)
bitmessagemain.py:112:80: E501 line too long (92 > 79 characters)
bitmessagemain.py:113:80: E501 line too long (87 > 79 characters)
bitmessagemain.py:114:80: E501 line too long (172 > 79 characters)
bitmessagemain.py:114:32: E261 at least two spaces before inline comment
bitmessagemain.py:114:33: E262 inline comment should start with '# '
bitmessagemain.py:115:80: E501 line too long (93 > 79 characters)
bitmessagemain.py:116:80: E501 line too long (96 > 79 characters)
bitmessagemain.py:117:80: E501 line too long (96 > 79 characters)
bitmessagemain.py:118:80: E501 line too long (110 > 79 characters)
bitmessagemain.py:120:80: E501 line too long (80 > 79 characters)
bitmessagemain.py:125:80: E501 line too long (92 > 79 characters)
bitmessagemain.py:125:37: E261 at least two spaces before inline comment
bitmessagemain.py:128:80: E501 line too long (105 > 79 characters)
bitmessagemain.py:128:34: E231 missing whitespace after ','
bitmessagemain.py:128:39: E231 missing whitespace after ','
bitmessagemain.py:128:44: E231 missing whitespace after ','
bitmessagemain.py:128:62: E231 missing whitespace after ','
bitmessagemain.py:131:80: E501 line too long (83 > 79 characters)
bitmessagemain.py:135:80: E501 line too long (105 > 79 characters)
bitmessagemain.py:135:34: E231 missing whitespace after ','
bitmessagemain.py:135:39: E231 missing whitespace after ','
bitmessagemain.py:135:44: E231 missing whitespace after ','
bitmessagemain.py:135:62: E231 missing whitespace after ','
bitmessagemain.py:142:80: E501 line too long (91 > 79 characters)
bitmessagemain.py:144:80: E501 line too long (83 > 79 characters)
bitmessagemain.py:145:80: E501 line too long (248 > 79 characters)
bitmessagemain.py:145:118: E261 at least two spaces before inline comment
bitmessagemain.py:150:80: E501 line too long (142 > 79 characters)
bitmessagemain.py:153:80: E501 line too long (115 > 79 characters)
bitmessagemain.py:154:80: E501 line too long (108 > 79 characters)
bitmessagemain.py:154:64: E231 missing whitespace after ','
bitmessagemain.py:157:80: E501 line too long (107 > 79 characters)
bitmessagemain.py:157:98: E203 whitespace before ','
bitmessagemain.py:157:99: E231 missing whitespace after ','
bitmessagemain.py:158:80: E501 line too long (135 > 79 characters)
bitmessagemain.py:161:80: E501 line too long (98 > 79 characters)
bitmessagemain.py:163:80: E501 line too long (97 > 79 characters)
bitmessagemain.py:164:80: E501 line too long (108 > 79 characters)
bitmessagemain.py:165:80: E501 line too long (145 > 79 characters)
bitmessagemain.py:169:80: E501 line too long (95 > 79 characters)
bitmessagemain.py:171:80: E501 line too long (87 > 79 characters)
bitmessagemain.py:172:80: E501 line too long (245 > 79 characters)
bitmessagemain.py:172:122: E261 at least two spaces before inline comment
bitmessagemain.py:177:80: E501 line too long (139 > 79 characters)
bitmessagemain.py:180:80: E501 line too long (154 > 79 characters)
bitmessagemain.py:183:80: E501 line too long (402 > 79 characters)
bitmessagemain.py:184:1: E302 expected 2 blank lines, found 1
bitmessagemain.py:189:5: E303 too many blank lines (2)
bitmessagemain.py:190:80: E501 line too long (176 > 79 characters)
bitmessagemain.py:191:80: E501 line too long (88 > 79 characters)
bitmessagemain.py:197:18: E261 at least two spaces before inline comment
bitmessagemain.py:200:80: E501 line too long (87 > 79 characters)
bitmessagemain.py:206:9: E303 too many blank lines (2)
bitmessagemain.py:207:80: E501 line too long (184 > 79 characters)
bitmessagemain.py:208:80: E501 line too long (92 > 79 characters)
bitmessagemain.py:212:80: E501 line too long (120 > 79 characters)
bitmessagemain.py:215:14: E231 missing whitespace after ','
bitmessagemain.py:215:20: E231 missing whitespace after ','
bitmessagemain.py:217:80: E501 line too long (238 > 79 characters)
bitmessagemain.py:220:80: E501 line too long (82 > 79 characters)
bitmessagemain.py:223:18: E231 missing whitespace after ','
bitmessagemain.py:223:24: E231 missing whitespace after ','
bitmessagemain.py:226:1: W293 blank line contains whitespace
bitmessagemain.py:228:23: E231 missing whitespace after ','
bitmessagemain.py:228:28: E231 missing whitespace after ','
bitmessagemain.py:228:33: E231 missing whitespace after ','
bitmessagemain.py:228:36: E231 missing whitespace after ','
bitmessagemain.py:232:80: E501 line too long (84 > 79 characters)
bitmessagemain.py:232:29: E261 at least two spaces before inline comment
bitmessagemain.py:233:23: E231 missing whitespace after ','

That's not even the best part of it. You can see the full 2443 line PEP8 error list here.

This shouldn't be so insanely un-pythonic. Some work should be done on cleaning up the source code - maybe some classes, those are helpful.

The initial trialValue for proof of work calculation appears to initially be out of the range of an 8 byte integer (unsigned long long)

trialValue = 99999999999999999999

8 byte unsigned long long range is 0 to 18446744073709551615

It is 2013, we're just about out of IPv4.

Please consider implementing IPv6.

Linux distributions have a pretty stable toolchain to package Python programs with standard setup.py file

Can you make it runnable from an USB flash with all settings/keys?
I've already requested it on the bitcoin forum, but I'm doing it again to give it more visibility ;)

With the spike of traffic last night I, and several others, noticed that we had to re-start our clients in order for them to start processing messages again.

Notes (knowns):
-OS>Windows7,Server2008
-Not processing old messages (only 10 old messages, all of which received ack.)
-CPU> not higher than during idle
-RAM> not higher than during idle
-Message>Work queued for all outgoing messages except those already sent

Fix: Restart required (I did have to restart one client every few hours last night)

• Permanent tray icon
• Notification pop-ups from tray when message received when window is not in focus
• Switch to 'Send' tab when selecting 'Send message to this address' from 'Address book' tab
• Capitalise the 'b' in 'book' on the 'Address book' tab (or drop the upper-case 'S' on 'Network Status')
• Have a mark for read/unread messages, display total unread messages in the 'Inbox' tab text field
• Change some of the status messages for the messages to be simpler (like 'Doing necessary work to send the message'):
  • 'Sending...', 'Sent', 'Delivery confirmed'
  • Separate columns for datetimestamps of time message sent and time of confirmation receipt in format (YYYY/MM/DD, 00:00:00)
• The explanation of the deterministic and random addresses can be simplified. Call such addresses "random address" and "passphrase-based address", stating one is recoverable and the other is not respectively.

Just a bit of polish, basically. Sometimes it's hard to keep human language simple when you're developing something like this, but the program UI itself feels almost like the documentation for the program.

Is it possible to leave PyBitmessage alone between version updates and instead keep any changes in a subversion or similar?

That way no changes are made between versions that would affect the interaction between Bitmessage and other applications (specifically api). This may already be how it works and I am just ignorant.

.dok

While not really an issue in functionality, after starting Bitmessage I'll start to see a high amount of writes to my HDD. While the amount of data isn't big (a small 600kB/s) it does this to several hundred temporary files before deleting them.

The file in question is messages.dat-journal, these seem to be of a small 4kB in size. Why are these written to disk before getting deleted?

Hello,
when you are determining the appdata path on windows, you get the value in whatever encoding windows chooses, which then results in an OperationalError during db connection opening. It would be useful to decode it to an unicode string, perhaps using sys.getfilesystemencoding. And it would help to have the whole logic only in shared, not duplicated it in the main script. Or is there any difference?

https://bitmessage.org/forum/index.php/topic,1543.0.html

Why is it better than i2pBote?

I set up Bitmessage in daemon mode on Debian 6 with one address configured as special behavior pseudo-mailing.
On my home computer I added this address to my subscriptions and tried to send a message to it. Usually it should return to me due to subscription. But it didn't.

Here is my server output which appears directly after the necessary work to send the message was done by client.

...
remoteCommand 'addr'  from 94.52.138.87
addr message contains 1 IP addresses.
knownNodes currently has 183 nodes for this stream.
remoteCommand 'addr'  from 94.52.138.87
addr message contains 1 IP addresses.
knownNodes currently has 183 nodes for this stream.
remoteCommand 'addr'  from 94.52.138.87
addr message contains 1 IP addresses.
knownNodes currently has 183 nodes for this stream.
remoteCommand 'inv'  from 62.244.11.42
sending getdata to retrieve object with hash: f28991853548d92776d02d96995804bc896f36738fbd0bceebdab72cb27b3656
remoteCommand 'msg'  from 62.244.11.42
broadcasting inv with hash: f28991853548d92776d02d96995804bc896f36738fbd0bceebdab72cb27b3656
This was NOT an acknowledgement bound for me.
EC decryption successful using key associated with ripe hash: 0000993559531650b422356c908e8273bc8c2a6b
ECDSA verify passed
As a matter of intellectual curiosity, here is the Bitcoin address associated with the keys owned by the other person: 1DVju4ha26pULwDp9qeG3tSCo27DJH6Xm4   ..and here is the testnet address: mt1hC7nYq8Fj83hRsQcdsoeXf1hv9t8YdT . The other person must take their private signing key from Bitmessage and import it into Bitcoin (or a service like Blockchain.info) for it to be of any use. Do not use this unless you know what you are doing.
We don't need this pub key. We didn't ask for it. Pubkey hash: 00fc92f05ec84f50efb8a0e0d3388b92d85ca41c
fromAddress: BM-oriDZJ7VAEjphwQmt7fACFqZJVwds26vW
First 150 characters of message: 'Subject:awegawegaweg\nBody:awegawgawgawgaweg'
Exception in thread Thread-40:
Traceback (most recent call last):
  File "/home/user/python/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "bitmessagemain.py", line 279, in run
    self.processData()
  File "bitmessagemain.py", line 355, in processData
    self.recmsg(self.data[24:self.payloadLength+24])
  File "bitmessagemain.py", line 896, in recmsg
    self.processmsg(readPosition,data) #When this function returns, we will have either successfully processed the message bound for us, ignored it because it isn't bound for us, or found problem with the message that warranted ignoring it.
  File "bitmessagemain.py", line 1085, in processmsg
    toLabel = addressInKeysFile
NameError: global name 'addressInKeysFile' is not defined

remoteCommand 'getdata'  from 66.108.210.240
received getdata request for item: f28991853548d92776d02d96995804bc896f36738fbd0bceebdab72cb27b3656
sending msg
remoteCommand 'inv'  from 97.118.177.61
Inventory (in memory) has inventory item already.
remoteCommand 'inv'  from 46.5.237.55
Inventory (in memory) has inventory item already.
remoteCommand 'inv'  from 94.52.138.87
Inventory (in memory) has inventory item already.
sock.recv error. Closing receiveData thread (HOST: 169.233.39.160 ID: 46960770080208). [Errno 104] Connection reset by peer
The size of the connectedHostsList is now: 9
sendDataThread (associated with 169.233.39.160 ) ID: 46960634746512 shutting down now.
Exception in thread Thread-60:
Traceback (most recent call last):
  File "/home/user/python/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "bitmessagemain.py", line 2064, in run
    self.sock.shutdown(socket.SHUT_RDWR)
  File "/home/user/python/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 107] Transport endpoint is not connected

remoteCommand 'inv'  from 84.211.84.168
Inventory (in memory) has inventory item already.
remoteCommand 'inv'  from 14.105.124.15
Inventory (in memory) has inventory item already.

From this point the client says "Waiting for acknowledgment".

What happened?

Date/time stamps on non-english locales are crappy. Add unicode() around strftime().

I made a patch by myself. Tried to create pull request, but maybe I have no permission to do it.

My echo server showed that a message was queued when the message before it was sent (waiting on ack). Unfortunately I do not run it with the console open so I have no other data. I did let it sit for over an hour before I restarted the client (which fixed the wait and allowed it to start processing the message 'doing work necessary')

Screenshot - http://imgur.com/IcCoLOK

.dok

Currently it's possible to open multiple instances of the application. Ideally if you try to open pybitmessage more than once it should just focus on the original instance - i.e. enforce a single instance.

as in the subject, using pybitmessage 0.3.0 and xfce4-panel 4.10.1 the tray icon is empty
on the console pybitmessage says:

Listening for incoming connections.
ERROR:root:Could not find any typelib for MessagingMenu
QGtkStyle was unable to detect the current GTK+ theme.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile

At startup:
"Problem: The version of SQLite you have cannot store Null values. Please download and install the latest revision of your version of Python (for example, the latest Python 2.7 revision) and try again."

$ python --version
Python 2.7.2+

Linux Mint 12