Future of Counterparty

General Counterparty
1

Dear Counterparty,

From the beginning of 2015 we recorded 3 at least major service downtimes.

January 21st, 2015
Problem with block 280006, which required emergent upgrade to 9.43.3 version + bitcoind 0.10.0 (with addrindex patch).

March 17, 2015.
Problem with integer overflow in block 348079

March 24, 2015.
Blockchain reorganization at block 349012 - fatal crash of Counterparty/Counterblock due to problems with DB

Some of Counterparty upgrades have feeling of a raw untested production, therefore, if given a chance, we try to wait up for some time before do the upgrade of our Federated Node.
However, in some cases, when working on blockchain and/or major protocol change, critical bug does not allow us to stay at previous version. In such cases our necessary upgrade turns out to be painful because instead,
of working version, we are getting another Exception in Counterparty or Counterblock services. For example, after installing version 9.50.0 we got problems with performance of Counterblock due to errors in blockfeed.py (https://github.com/CounterpartyXCP/counterblock/issues/115).

In addition, we are very concerned with the necessity of reparsing of the DB practically after every update. As blockchain is in fact permanent, we believe caching of all necessary data with the delay of let’s say 1000 blocks from actual,
would result in ten times faster update, than going every time thru the whole blockchain. Currently we have to spend from few hours to few days on blockchain parsing, depending from the ability to use bootstrap.
As well, one time during Counterparty upgrade we had to reparse the DB due to the change of the IP address. This problem doesn’t allow us to have cold reserve nodes.

Unfortunately, such instability and following long system outages, make us seriously doubt the ability to create serious financial technology products on Counterparty platform.

Based on the above, we would like to start a dialog about how do you guys plan to further develop and enhance Counterparty to make it number 1 blockchain development platform.
Just yesterday we were excited to read about your new collaboration with Symbiont.io to work on smart securities. As well, we know about your Overstock experience.

We would be happy to help with what we can.

Amilabs.co Team

2 Likes
2

It’s important to note that the immutability of Counterparty transactions is secured by the Bitcoin blockchain. The Counterparty software simply looks at the Bitcoin blockchain and parses the Counterparty data.

When you are experiencing downtime with Counterwallet, Counterblock, or counterpartyd, the network itself is still functioning as long as the Bitcoin network is functioning; you just can’t see the trees from the forest.

The best way to increase uptime and stability to Counterparty software is to have different implementations of counterpartyd. This would also help spur new development as it did with Bitcoin with the advent of BitcoinJS, btcd and others.

3

The fastest way to get a Counterparty server up and running is to bootstrap from a checkpointed DB.

mkdir -p ~/.config/counterparty-server && cd ~/.config/counterparty-server
wget https://s3.amazonaws.com/counterparty-bootstrap/counterparty-db.latest.tar.gz
tar xvzf counterparty-db.latest.tar.gz
counterparty-server --database-file ~/.config/counterparty-server/counterparty.db start &

The file download is about 256 MB iirc, and it takes less than 15 minutes to bring counterparty-server up to date once you’ve downloaded the tarball.

It’s possible to connect counterparty-server to btcd in addition to Bitcoin Core with addrindex, which means Bitcoin Core is no longer a single point of failure.

It always seemed to me like Counterblock and Counterwallet were the weak link. Counterparty-GUI is the future IMO.

4

Hi guys,

Thanks for the feedback. We try to avoid forcing updates whenever possible. However, the issues you mention required a forced update due to their impact on block parsing, and the fact that they were (or touched) protocol-level code. The nature of embedded consensus systems like Counterparty means that all nodes must run the same protocol (or consensus-sensitive) code. Thus, we only force updates when we make changes to this kind of code, to avoid network forks.

In reality, beyond the large architecture update of 9.43.x (which we shouldn’t have to go through again), these are very small changes from a code level. However, as you noted, they did cause service issues. We apologize for that, and have taken steps to minimize the frequency and impact of these kinds of updates over the last few months:

  • Currently, our development of counterparty-server is starting to slow overall, and focusing on the smart contracts functionality. Building on smart contracts allows developers to accomplish virtually anything, without layering in anything into the Counterparty protocol itself. This adds tremendous power to Counterparty, while minimizing the risk and frequency of these kinds of required updates.

  • The counterparty-server test coverage continues to grow, and is now almost 70%. Our goal is to get this to be as close to 100% as possible.

  • We’ve also been working to simplify the complexity of the Counterparty protocol as much as possible by removing certain unused features, such as callbacks, CFDs, and more. All of this functionality is now possible via smart contracts. By removing them (as they were hardcoded into the protocol itself), we further simplify the core protocol and reduce the space for error.

  • Regarding reparses, they are necessary when we make a change to the protocol-level code. We have to parse through the blockchain again because the result could have changed with the code update (even with earlier blocks). Especially over the last 4 months, we’ve made this parsing process very fast, so that on a modern server, it should only take a few minutes. If that’s not the case with you, please let us know.

  • A few months ago, we added an SMS list, where we will notify subscribers of urgent updates via text message, in addition to the broadcasting we do on our other mediums (forum, Slack, Gitter, etc). We’d be happy to add your number(s) to this list.

  • The bootstrap image should make rebuilds and new builds much quicker, and can be easily grabbed via counterparty-cli bootstrap command. The bootstrap file had issues over the past week or so, and has been regenerated.

  • counterblock has undergone a reorganization lately as well, and the upcoming version moves Counterwallet specific functionality into its own plugin, allowing the core counterblock to be more minimal, and thus decreasing the chance of bugs and issues in the long run (especially for those running basic counterblock API services, without Counterwallet). We’ve also corrected numerous stability issues as of a few days ago, and are continuing to make stability improvements there.

Despite the fact that Counterparty has been around for over a year, it is still a rapidly evolving platform, with new features being added and bugs fixed. The core protocol is pretty much in place, beyond the development of the smart contracts functionality. Our goal is for counterparty-server to receive much less frequent updates in a few months from now, especially once we’ve completed the smart contract work.

-Robby

1 Like
5

That’s understood, however is gives us no comfort as we still can’t read Counterparty transaction, and write them as well.

It’s very hard to look for a black cat in the dark room, especially when cat is not there.
Two problems that we face at the same time make this venture kind of hopeless.

  1. Protocol is undocumented. Example is description of (only) storage with OP_CHECKMULTISIG, but we may never have learned about OP_RETURN, OP_CHECKSIG, which would result with inconsistency of the system. And how many more surprises can then happen in the protocol going forward?

  2. Protocol changes when we the least expect it.
    Even if we spend lots of time on full code reversal and formalization, tomorrow everything can change and stop being consistent. So do we have to reverse the code again? And the most frightening part, that we may not know right on that our version is not correct anymore. This is unacceptable case for fintech application, gentlemen.

That’s great idea. Appreciate it. Although, in reality we already have downed block (see bug 115 above). And it’s been 2 days now and no changes or updates. About Counterblock, yes. It’s seem true. See below.

6

First of all, thank you for detailed answers!

In reality, problem is damn serious. As there is no predictability in system behavior which is unacceptable for fintech solutions. As well, there is no practical way to test system behavior after updates and decide when it can be applied to the project, which is written on official API CP, of course.

Also I want to point out that protocol changes are not being published and the information available for CP development community may be outdated from actual system status.

The rest of mentioned points, gives us hope that situation will improve, and thanks again for the details. However, I don’t see a solid solution for now, except as just to “lockdown” the project inside our own application, without ability to collaborate with other CP projects, such as wallet, blockchain, and DEX. Therefore, there is no difference from forking the Counterparty and creating independent ecosystem, as much as we want to keep it all together.

In fact, since the latest update, for already 2 days the Counterblock service on both of our Federated Nods is down due to exceptions in production.

Exceptions were brought to attention in Infinite redirect loop on block 348078 · Issue #115 · CounterpartyXCP/counterblock · GitHub, and Exception in unpack() · Issue #735 · CounterpartyXCP/counterparty-core · GitHub

Unfortunately, no response on those was received.

For the record, the counterpartyd WORKS, but based on your recommendations we access it through Counterblockd to keep the compatibility. Hence, we have no working system at all.

As said above, we try to write own production of transaction reading service for our own needs. But this process is very unpredictable and even if we setup everything by reversing CP code, there is still no guarantee that tomorrow something won’t change and we lose system uptime for the unknown period again.

We are open to help with making CP better and reliable, but it’s getting harder and harder to stay positive, given the complexity and time framing of the project we work on.

We really would like to work on your platform further, but we believe it’s now time to start taking matters of system stability and reliability seriously, as supposed to for financial application. We see and appreciate the large scope of your work, github activity, and we are truly impressed by your progress for the less than a year.

Thank you.

7

Changes in protocol would only affect transaction parsing post-change as past transactions cannot be altered. Should this happen, it would simply require you to update your code to reflect that change after the block where it takes effect. Any previous efforts would not be for naught.

Feel free to help out with the developer documentation effort here, GitHub - tokenly/counterparty-spec: Aims to be a complete specification for Counterparty transactions

I put together a Javascript library for manually creating and decoding send transaction using the OP_CHECKMULTISIG method which should be pretty easy to follow to help you get started with a reimplementation. GitHub - loon3/xcp-tools-js: Javascript Library for Counterparty (counterparty.io)

8

As a Linux sysadmin with some experience using the Counterparty API here are my thoughts on this.

The Federated Node script is ok for setting up Counterwallet, but if you don’t want Counterwallet, it’s too huge and bloated. I don’t like it almost as much as I don’t like Counterwallet.

On my systems, I have no need for the Federated Node script. Counterpartylib and counterparty-server is available globally, so you can always open ipython, import counterpartylib, and hack away no problemo. No virtualenvs. It’s super clean.

I can install and upgrade counterpartylib easily in isolation, along with all of its individual dependencies. Custom Bitcoin Core builds. btcd too.

Ubuntu makes me cringe. Anything involving Bitcoin is cutting edge. Ubuntu has outdated software galore. Apt-get makes it too difficult to build custom software on a moment’s notice. Pacman and PKGBUILDs are lightning quick to create from scratch and use it. On Arch, everything, including all dependencies, is up to date with the most recent upstream versions.

Try putting cutting edge software on rolling release systems that make it easy to run custom software. It works better.

Instability issues are common to all Bitcoin projects. Even old Bitcoin projects like Electrum have mysterious undocumented problems that will bite you. Most Bitcoin projects show great promise, and Counterparty is doing it right. You just have to be prepared and have the skills.

Why are you using Counterblock? Can you explain in detail?

1 Like
9

alex, thanks. I just committed a change to counterblock that should address counterblock #115. Try it out and let me know. I can follow up on counterparty #735 as well…

I’ve also invited you to our slack dev chat, where we can help address your issues better.

What kind of work are you doing? Depending on the nature of your work, counterblock may not be necessary (I can’t remember the exact conversation we had earlier, but we can chat about this on Slack). Historically, counterblock gets less attention that counterparty-server as less people use it, although these last few days I’ve been catching it up and fixing bugs. Will be releasing 1.2.0 shortly.

10

This is not enough, as told @robby_dermody above – all nodes and parsers should be last version. Elsewhere there may be no consensus and assets, wallets balances may be not actual, and that’s of course impossible for an app.

As well, system update takes a time to update, test, publish. It’s impossible for fintech app, just imagine that your bank hold the operations for a couple days (even weeks) due to unexpected API changes.

Yes, we researched that already. Thank you for this update.

11

[quote=“Hernando, post:8, topic:964”]
On my systems, I have no need for the Federated Node script. Counterpartylib and counterparty-server is available globally, so you can always open ipython, import counterpartylib, and hack away no problemo. No virtualenvs. It’s super clean.
[/quote] Sure, we setup it without wallet too.

We use it for two reasons:

  1. CP recommends to use it for access to counterpartyd :wink:
    But we’ve already changed this to use bitcoind and counterpartyd directly as often as possible.
  2. See below for the list of functions.

We use many functions from counterblock’s API to get information about assets & txs, for example: get_owned_assets, get_asset_history, get_balance_history, get_last_n_messages, get_raw_transactions
We need issuances and burns history, account & asset holder balances in specified time periods, list of assets sends and many others. Also we plan to use some market functions too.

We could do that without counterblock by developing all these functions if CP will provide acceptable tool for decode transactions, but it doesn’t yet. Unfortunately all we have for now is command get_tx_info that gets unencoded raw data as hex string.
Command unpack doesn’t work correctly yet, as it was just fixed and even after that supports only one command.

# TODO: Enabled only for `send`.
if message_type_id == send.ID:
    unpack_method = send.unpack
else:
    raise APIError('unsupported message type')

In general, all this functionality is the thing because we use the CP and those are important framework tools of the CP. If we will do most of things ourselves we will be close to forking it, but we believe that’s a wrong way.

Thank you soo much, bugfix for #115 helps us and we got counterblock live at our nodes.
Unfortunately, fix for #735 was not enough because it has limited the functionality.

In summary, the most important thing for us now is to get some API function to decode transactions, because any own development of such things may get useless after another update or what’s more important, we can’t be sure that we used all the necessary things.

@robby_dermody I would ask you few questions about the decoding.

  1. Why you can’t reuse code from existing decoding functions and
    provide it via API? Why do you create new code for decode?

  2. Is there some API’s way to detect transaction type by it’s raw data? Then we can read transaction info from corresponding table (issuance, send, etc) using get_{table} method. We can try to add this method to CP’s code and submit pull request.
    Actually it doesn’t solve tasks with decoding of not broadcasted transactions but at least we are moving somewhere!

As for contact – we already in your gitter channel and thanks for your team’s support there.

Thank you!

12

alexnsk:

You only need to use Counterblock if you are using API functionality that counterblock supplies. If you don’t, you can just use counterparty-server directly. We never recommend that you use it just to access counterparty-server, and I’m not sure where you got that idea.

Nodes may be at different versions, but only if the version differences don’t touch any consensus-sensitive code. Indeed, this has been the case before where people were running different versions of counterparty-server. With counterparty-lib/counterpartyd, this is denoted by the version number: revision version changes (e.g. 9.43.3 to 9.43.4) are for when no update was made for consensus sensitive code, and minor changes (e.g. 9.43.3 to 9.44.0) are made when there are, which means that a reparse is necessary. Major version changes mean that the database core schema was updated, and a rebuild is necessary, which takes much longer. These kinds of updates don’t really happen anymore.

As for your comment:
“As well, system update takes a time to update, test, publish. It’s impossible for fintech app, just imagine that your bank hold the operations for a couple days (even weeks) due to unexpected API changes.”

Unless it’s a critical downtime issue, we normally give at least a week or more notice of new version releases that will require folks to upgrade. An update takes only a few minutes (on a federated node or with counterparty-lib/counterparty-cli directly via pip), and the reparse takes only a few minutes as well. On mainnet the counterblock reparse takes some time longer, but unless it’s a showstopper issue, you can have multiple fednode/counterparty servers running and do a rolling upgrade. In fact, this is how we upgrade counterwallet, to avoid unnecessary downtime.

As far as your two specific questions:

  1. Not sure I understand you here. What is the new code for decode that you’re talking about? If it has to do with #735, this would be a good question to ask in the ticket for #735, as Adam will be able to provide the best answer.

  2. Right now, data is stored in one form in the counterparty-server database (SQLite) and in several other “processed” or “digested” forms in the counterblock (mongoDB) database. Blockscan, for example, reads directly from counterparty-server’s SQL database, but this is not recommended for several reasons. It’s best to use the APIs, as the underlying data structure can theoretically change without notice, while we try to preserve backwards compatibility with the APIs (or at least provide notices when things change).

You may just want to look into using counterparty-lib directly, if you are building with python. See http://counterparty.io/docs/counterparty_lib/ …this could be a good alternative to running a separate counterparty-server daemon. However, if you are using counterblock for its APIs, counterblock does not offer a similar kind of embedded mode, so that would be a moot point here for it.

The other thing I’d do is call counterparty-server APIs directly, and not proxy through counterblock. Counterwallet proxied through counterblock due to security model concerns that no longer really apply, and we may depreciate this proxy functionality in the near future. Calling counterparty-server will increase stability in cases where counterblock is causing issues.

Counterparty is an open source project, and you are of course, welcome to fork it. However, it will no doubt place more of a load on your team to maintain your fork moving forward (especially as our team continues to make changes), unless you were to just fork it and do nothing but fix critical bugs, essentially. Your team’s time and talents might be better spent (in my biased opinion) learning the code some and helping to contribute by fixing any bugs you run into – which we normally merge quite quickly. If this is your intention, once you figure out if Counterparty will work for your product, then we appreciate it, as it will help make Counterparty better for all.

13

I’ve updated previous post too late, sorry for that. So, I repeat updated question there.

Is there some API’s way to detect transaction type by it’s raw data? Then we can read transaction info from corresponding table (issuance, send, etc) using get_{table} method. We can try to add this method to CP’s code and submit pull request.

14

@robby_dermody others thing are now clear, thank you for the explanation. Hope next updates will always be compatible, easy, and we get time to test it.

15

counterblock 1.2.0 BETA released: https://github.com/CounterpartyXCP/counterblock/releases/tag/1.2.0-BETA

Please test that out. Unlike with counterparty-server, you can keep running with 1.1.0 if you have issues with this release, but I’d like to make sure it still works with what you guys are doing (it works fine for counterwallet uses on both mainnet and testnet, from my testing).

16

After update:

# sudo su -s /bin/bash -c 'PYTHON_EGG_CACHE=/tmp/counterblock.eggs counterblock --reparse' xcpd

Traceback (most recent call last):
  File "/usr/local/bin/counterblock", line 9, in <module>
    load_entry_point('counterblock==1.2.0', 'console_scripts', 'counterblock')()
  File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/counterblock/__init__.py", line 4, in server_main
    from counterblock import server
  File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/counterblock/server.py", line 20, in <module>
    from counterblock.lib.processor import messages, caughtup, startup #to kick off processors
  File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/counterblock/lib/processor/startup.py", line 8, in <module>
    from counterblock.lib.processor import StartUpProcessor, CORE_FIRST_PRIORITY, CORE_LAST_PRIORITY, api, tasks, start_task
ImportError: cannot import name tasks

Running without arguments - returns same error.

# sudo su -s /bin/bash -c 'counterblock' xcpd
Traceback (most recent call last):
  File "/usr/local/bin/counterblock", line 9, in <module>
    load_entry_point('counterblock==1.2.0', 'console_scripts', 'counterblock')()
  File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/counterblock/__init__.py", line 4, in server_main
    from counterblock import server
  File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/counterblock/server.py", line 20, in <module>
    from counterblock.lib.processor import messages, caughtup, startup #to kick off processors
  File "/home/xcp/federatednode_build/env.counterblock/local/lib/python2.7/site-packages/counterblock/lib/processor/startup.py", line 8, in <module>
    from counterblock.lib.processor import StartUpProcessor, CORE_FIRST_PRIORITY, CORE_LAST_PRIORITY, api, tasks, start_task
ImportError: cannot import name tasks