Changelog
Jump to navigation
Jump to search
PyBitmessage Changelog
0.2.4
- Prevent user from sending messages to themselves since the client does not handle this properly
- Do the pubkey POW and broadcast it directly after generating a new address
0.2.3
- Defined rules for nodes to follow for storing and relaying pubkeys. Nodes now store keys for 4 weeks then delete them. They also will not accept pubkeys older than 4 weeks; the owner will have to retransmit them if they are needed.
- Added 'fuzzing' to the time embedded in msg and broadcast messages.
- Added timing attack mitigation to the function that processes incoming pubkeys
- Added a new file: messages.dat reader.py which can be independently used to print information stored in the messages.dat file to the console.
- Users who run the software for the first time will now be subscribed by default to a Bitmessage address used to send announcements.
0.2.2
- Don't use DNS-based bootstrapping method if user is connecting via SOCKS; just skip it. Hopefully the nodes listed in defaultKnownNodes are still up.
- Implemented timing attack mitigation measure
0.2.1
- Added ability to send Sent items to the trash
- Keep track of which objects each peer is already aware and don't advertise objects that they already know about
0.2.0
- Major upgrade to ECC:
- Elliptic curve secp256k1 is used for Bitmessage's signing and asymetric encryption. Keys are interchangable between Bitmessage and Bitcoin.
- Keys stored in Wallet Import Format in the keys.dat file
- Deterministic addresses
- Addresses are now shorter: Bitmessage now supports 18 and 19 byte RIPE addresses where the missing 1 or 2 bytes are assumed to be zeros.
- Moved pubkey POW responsibility from the receiveData thread to the singleWorker thread
0.1.6
- Added DNS-based bootstrap method so that updating defaultKnownNodes doesn't require a code push.
0.1.5
- Client now checks whether a getpubkey message has the correct time before storing in inventory and also uses embeddedTime rather than system time (the way it is done for all other messages). This was a bug that didn't cause any ill-effect.
- Fix so that today's Bitmessage client will properly handle future versions of Bitmessage addresses
- Updated defaultKnownNodes
0.1.4
- Added support for SOCKS4a and SOCKS5 proxies
- Adjusted UI so that it looks appropriate on OS X
- Changed UI to accept Bitmessage addresses which lack a "BM-". This makes copying and pasting easier.
- Fixed OS X issue: if user minimized client to tray then restored, segmentation fault occured
- Added locks to prevent ill-effect if the client receives the same object from two different nodes at the exact same time
- Commented out code that prevents the client from accepting a second connection from the same IP since this prevents users from running two clients within the same local network. When the Bitmessage network grows, this code will be re-enabled.
0.1.3
- Updated defaultKnownNodes so people who download Bitmessage on a fresh machine can bootstrap
- Sort received-message-time by actual time rather than by time-interpreted-alphabetically
0.1.2
- Fixed line break display issue
- Updated defaultKnownNodes so people who download Bitmessage on a fresh machine can bootstrap
- Bug fix: If subject in received message contained international characters, reply button wouldn't work completely
0.1.1
- Fixed bug that prevented user from deleting a recently received message
- On the "Send" tab, select your address automatically if you have only one
- Rewrote the SQLite version check more liberally accept SQLite revision numbers
- Fixed "reply" functionality
- Removed PyObjc dependency for OSX
0.1.0
- Initial release