bitmessage / pybitmessage Goto Github PK
View Code? Open in Web Editor NEWReference client for Bitmessage: a P2P encrypted decentralised communication protocol:
Home Page: https://bitmessage.org/wiki/Main_Page
License: Other
Reference client for Bitmessage: a P2P encrypted decentralised communication protocol:
Home Page: https://bitmessage.org/wiki/Main_Page
License: Other
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
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?
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.
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.
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.
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.
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
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.
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 ;)
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.
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.
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?
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?
My issue is very similar to:
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?
Please, make a UPnP support standart.
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.
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.
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)
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
When setting this option to true the application does not minimize itself on startup, which I expect is the intended behavior.
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 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)
Why is it better than i2pBote?
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
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.
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?
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.
It would be really cool if there were a message encoding type to transfer files, in simple binary format.
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 -
Please add indention to replies like in most other email programs
Seems to copy some of the top line's qualities.
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
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.
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 :) )
It is 2013, we're just about out of IPv4.
Please consider implementing IPv6.
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)
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. :)
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?
It would be nice if you could provide signed git tags for new releases.
I tried to install OpenSSL via brew, but no effect. I exported needed PATH for it.
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
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.
Linux distributions have a pretty stable toolchain to package Python programs with standard setup.py
file
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))
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.
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.