This week our development efforts were mostly focused on code reorganization and refactoring. With 90 commits issued this week, there has been a lot of improvement made, so let’s take a look at exactly what was changed.
Improved Release Process
First of all, we’d like to address the release process again. As announced in the community update post, as of the next counterpartyd release, we’ll be publishing official Release Notes with each new client version. The Release document will be hosted on GitHub and sent out to all our SMS and Email subscribers, as well as linked in our regular Counterparty posts. The notes will include protocol changes, interface changes, mandatory upgrade block, upgrade procedure, API and CLI changes.
An example of the release document has been made for the counterpartyd v9.49.1 and can be found here.
Development of a Comprehensive Wiki Guide
We begun developing a new Counterparty Wiki which will be hosted on GitHub and contain all the information about Counterparty and its technology. The current Counterparty Wiki: https://wiki.counterparty.io/w/Main_Page will be shut down once all the information is updated and copied over to the new Wiki.
The goal is to have all the relevant information in once place and avoid redundant material which is hard to maintain and keep up-to-date.
It will take some time for us to collect all the material that is currently scattered around different channels, update it with the latest information, and organize it efficiently on the Wiki. As soon as we have a comprehensive developer guide we will notify the community, so everyone can start using it as the reference source for Counterparty development.
Changes Across Our Repositories
All changes this week were made on the counterpartyd repository. Please note that most changes are still in develop
. Here’s what was included:
- Fixed the bug when moving an asset from a single signature address to a multisignature address [#516] – used canonical addresses to check transaction construction
- Fixed the bug with ungraceful fail upon send when using only vanilla Bitcoin Core as backend [#520]
- Removed addrindex cache for unconfirmed transactions
- Added logging for unhandled exceptions
- Replaced
getinfo
withgetblockcount
- Fixed the bug related to the use of python-bitcoinlib
- Updated asset names coverage in the API docs
- Added CLI parameter for backend poll interval [#524]
- Added automatic generation of RPC password if one is not specified
- Removed example CLI usage and non-technical information from README, Introductory material was moved to our Wiki page:
- Moved the code dealing with backend interaction from
util.py
tobackend.py
- Improved logging when handling
SIGTERM
andSIGKILL
- Moved code from
bitcoin.py
to:util.py
,transaction.py
,backend.py
andscript.py
– this was part of the code reorganization to have transaction-related functions in thetransaction.py
, backend-related functions in thebackend.py
module, and so on. - Moved address-handling functions out of
util.py
intoscript.py
- Moved logging and message functionality to a new module ‘logging.py’
- Improved process locking on OS X – on Windows and OS X
socket.AF_UNIT
was replaced withsocket.AF_INET
[#529] - Fixed
sign_tx()
and addedget_wallet()
API method - Added a checkpoint at mainnet block 334000
- Enabled running without a backend using –force: If
--force
is used, the system won’t check if the backend is available, and when polling for blocks inblocks.follow()
, if the backend can’t be reached, it will try again repeatedly. This is useful for testing purposes, when a complete copy of the blockchain isn’t available, but a reasonably complete database is. - Added multiple python-bitcoinlib proxies to backend
- Added more
unpack
API calls [#352]: Now, theunpack
API method is defined automatically for all message modules for which there exists anunpack()
function. Also, added differentiation between balance errors and validation errors for new message parsing code. - Optimized ‘get_tx_info2()’ [#542]: Exit early from
get_tx_info2()
if the transaction in question isn’t a burn and it contains no data. - Allowed manually providing pubkeys for multi-sig [#413]
- Implemented RPC catch for
unconfirmed_transations()
- Cleaned up the logic of
transaction.construct()
That covers our development updates for this week. If you have any questions regarding recent or upcoming changes you can contact us via our support channel, forum or github.