Counterparty Desktop GUI Bounty thread

The Counterparty team will be paying out a bounty on February 14th, at 00:00 UTC (three weeks from today, midnight on Saint Valentine’s Day) for work on a desktop GUI Counterparty client built on top of counterpartyd. The size of the bounty will be the balance of our donation address, [tt]12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs[/tt] (both BTC and XCP), at the time that the bounty is closed, and the winner(s) will be chosen, thereupon, by a consensus of PhantomPhreak, xnova and myself. N.B. We prefer, but will not require, that clients be cross-platform.

All submissions must be open sourced and freely licensed by the end of the burn period (but the earlier the better).

I’ll have a client out before then. It’s going to be real simple. I don’t expect any reward for it.

[quote author=halfcab123 link=topic=8.msg132#msg132 date=1391519747]
I’ll have a client out before then. It’s going to be real simple. I don’t expect any reward for it.

Could you please give us  a screenshot?

Hi, in case the GUI client is written in Python, I can help with packaging the binaries for Windows.
It’s usually rather tricky to make standalone Python apps run seamlessly across Windows versions and I have extensive experience with that (see my Windows builds for Electrum, Chainsnort, NoBrainr, Deep Space Vagabond, etc)
I think I would be willing to do it (as well as document the build process) for 15%-20% of the bounty.

Good Morning XCP’ers!

I have just connected the architecture from my nxtFreeRider to the counterpartyd backend for one function (the ‘get_burns’).

This is a proof-of-principle for me that this works. Now I don’t really know how to continue.

The API is quite different from the nxt api - I have found 25 calls. Also, the input paramters are way more complex than for nxt.

The preparation of the next object is different also: nxt uses ‘GET’, xcp uses ‘POST’ - that was interesting to change the prototype from the nxt std to the xcp.

But again - there is much more data going into the xcp query than into the nxt query. I am not sure if it is possible to plonk it in without at least a basic understanding of what it is and does, which I do not have atm.

Also, I am very much involved in the nxt project, and thus my understanding of nxt and my nxtFreeRider are far more advanced.

The nxt AE is launching soon, and the main reason for creating nxtFreeRider was the AE in the first place, so I can’t miss that.

Although I do have a definitive grip on how to do this, getting an even half-finished GUI client for xcp running until Friday (14th?) is unrealistic.

Having a workable API backend is one thing. Connecting all the bells and whistles on the widget side frontend is much easier, but also much more time consuming!

I am planning to release nxtFreeRider (beta) by the end of next week. But since the architectures are very similiar, it is worth a try to move forwards

in parallel with nxtFreeRider and xcpFreeRider.

I think that at the very least I will be able to provide a solid backend implementation to the api, so that others in the community can connect more widgets by modifying existing examples.

very much interested in thoughts and feedback,

I will have a working GUI out by Friday. Here is a screenshot of one of the pages in action:

[quote author=btcfanatic link=topic=8.msg334#msg334 date=1391931240]

I will have a working GUI out by Friday. Here is a screenshot of one of the pages in action:


That looks good. I’m excited for this!

The thing I love about the bitcoin community is that stuff gets released super fast because there is no approval process

[quote author=btcfanatic link=topic=8.msg334#msg334 date=1391931240]

I will have a working GUI out by Friday. Here is a screenshot of one of the pages in action:

[quote author=blackbeard link=topic=8.msg360#msg360 date=1391990789]

The thing I love about the bitcoin community is that stuff gets released super fast because there is no approval process

[quote author=btcfanatic link=topic=8.msg334#msg334 date=1391931240]

I will have a working GUI out by Friday. Here is a screenshot of one of the pages in action:

However, this makes proper testing and quality control all the more important. Not as critical for a GUI addon (as opposed to the reference client implementation), but very important regardless.

I do not compete for the Bounty, because I’d never done before February 14.
But this GUI is ready for actions: send, order, cancel and btcpay.

I just made a push. These actions are now available:
send, order, btcpay, cancel, issuance, dividend, callback, broadcast and bet.

I talked with a friend (much better than me) yesterday and he convinced me that:

1) there was no need to use CFE, and the vast majority of users had no problem using web wallet as BCI (or the upcoming "Counterwallet"). The paranoid could always use CFE standalone as a "browser safe". So there is no reason that this is not the same for a GUI. And this will leave me much time to improve the GUI.

2) That the easiest way for the user to use the GUI, is to integrate it into counterpartyd. In this way, the user does not need to install multiple software and GUI can be automatically accessed when counterpartyd works.

3) my GUI was functional and that there was no reason why I do not participate in the Bounty.

So despite my huge backlog in my real job (much less funny), I took the time to changed my code to use CherryPy instead of Bottle and it is fully integrated in counterpartyd.
I tried to respect the style of code:

Here are the new arguments of counterpartyd:

–activate-gui : run GUI web server
–gui-host : the host to provide the counterpartyd GUI
–gui-port : port on which to provide the counterpartyd GUI
–gui-user : required username to use the counterpartyd GUI (via HTTP basic auth)
–gui-password : required password (for gui-user) to use the counterpartyd GUI (via HTTP basic auth)

And the corresponding keys in config file:


Default values are:

gui-host = rpc-host
gui-port = 8080
gui-user = rpc-user
gui-password = rpc-password

I made a pull request here:

Thank in advance to the developers for time to check this code.

Following the excellent kanzure, xnova and phantomphreak suggestions, I separated GUI into two repositories:

The Webserver serving GUI:
The GUI:

Dependencies are exactly the same as counterpartyd, it should be easy to install if counterpartyd is already installed.

<br />counterpartyws [-h] [--data-dir DATA_DIR]<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [--counterpartyd-dir COUNTERPARTYD_DIR]<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [--counterpartygui-dir COUNTERPARTYGUI_DIR]<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [--gui-host GUI_HOST] [--gui-port GUI_PORT]<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [--gui-user GUI_USER] [--gui-password GUI_PASSWORD]<br /><br />Web server for Counterparty GUI<br /><br />optional arguments:<br />&nbsp; -h, --help&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; show this help message and exit<br />&nbsp; --data-dir DATA_DIR&nbsp; the directory in which to keep the config file<br />&nbsp; --counterpartyd-dir COUNTERPARTYD_DIR<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the directory in which counterpartyd is installed<br />&nbsp; --counterpartygui-dir COUNTERPARTYGUI_DIR<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the directory in which counterpartygui is installed<br />&nbsp; --gui-host GUI_HOST&nbsp; the host to provide the counterpartyd GUI<br />&nbsp; --gui-port GUI_PORT&nbsp; port on which to provide the counterpartyd GUI<br />&nbsp; --gui-user GUI_USER&nbsp; required username to use the counterpartyd GUI (via<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; HTTP basic auth)<br />&nbsp; --gui-password GUI_PASSWORD<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; required password (for gui-user) to use the<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; counterpartyd GUI (via HTTP basic auth)<br />

Here is my open-sourced, cross platform GUI written in PyQT:

[quote author=btcfanatic link=topic=8.msg476#msg476 date=1392335320]
Here is my open-sourced, cross platform GUI written in PyQT:

Great work! I’m going to try it out now!

Here a build for MacOS :

1) Download:

2) Unzip

3) Update configuration file ~/Library/Application Support/counterpartyd/counterpartyd.conf

[Default]<br />bitcoind-rpc-connect=<br />bitcoind-rpc-port=8332<br />bitcoind-rpc-user=xxxxx<br />bitcoind-rpc-password=xxxxx<br />rpc-password=xxxxx<br /><br />gui-host=localhost<br />gui-port=8080<br />gui-user=xxxxx<br />gui-password=xxxxx

4) Double click

5) Open you browser: http://localhost:8080


[center][size=14pt]We are taking submissions for the Desktop GUI Bounty[/size][/center]

Those who have made Desktop GUIs and would like to be eligible for the desktop GUI bounty should provide the following:

[list][li]a link to source code[/li]
[li]screen shots[/li]
[li]a short description[/li]
[li]a list of features[/li]
[li]platform support and an installation guide[/li]
[li]your future plans: do you plan on maintaining your client? What if there were a "client maintenance" bounty?[/li][/list]

Post the above on the official forum bounty thread and also PM it to cityglut, xnova and PhantomPhreak.

I am working very closely with l8orre, he will be posting links to src code, etc. We got started way too late to be able to get a fully functional XCP GUI, but the foundation is there to relatively quickly complete the features. It is also designed to be more of a low level GUI direct to API calls, so this would allow power users who are not programmers to test counterparty.

The long term plans are to create a seamless bridge between NXT Asset Exchange and XCP Dex. with NXT block times being once per minute, it allows for much faster transaction latency, however there is no BTC escrow process. Clearly, both NXT and XCP have there respective advantages and disadvantages and it is always a better market when it has more liquidity and smaller spreads.

Both NXT and XCP will benefit greatly from a bridge between their exchanges. Any support for this will be much appreciated, especially if denominated in XCP.


[size=24pt]Submissions for the Desktop GUI Bounty[/size]

a link to source code

screen shots

a short description

The GUI consists of three components:
- The counterpartyd daemon that scans the blocks.
- A webserver that use the counterpartyd lib
- An interface in html/css/ javascript
My opinion is that modern interface must be done in html/css/js. This is of course a subjective opinion I do not think an absolute truth. The advantages of HTML are amongst others:
- Speed of development with complete freedom in the look and feel (why all wallet should look like twins?)
- The possibility for many more people to contribute to the GUI
Note that I am not saying that the GUI must necessarily be used from a web browser, but only that the interface must be in html/css/js. I think, as I get more time I will embed the GUI in any webview to avoid opening a browser.

a list of features

- no difficult installation, just launch the app
- balances by asset
- balances by address
- action send
- action order
- action btcpay
- action cancel
- action issuance
- action dividend
- action callback
- action broadcast
- action bet

platform support

- For those who know how to manually install counterpartdy from scratch: all platform
- For others: yet only MacOS, Windows in the coming weeks.

and an installation guide

1) Download:

2) Unzip

3) (optional) Update configuration file ~/Library/Application Support/counterpartyd/counterpartyd.conf

gui-host=localhost (default: localhost)
gui-port=8080 (default: 8080)
gui-user=xxxxx (default: rpc-user)
gui-password=xxxxx (default: rpc-password)

4) Double click

5) Open you browser: http://localhost:8080

your future plans: do you plan on maintaining your client?

Course. This is my first open source project and more in an area that fascinates me. I’m really excited, and I slept only 2 hours per night all week to move forward on this project (I am married with 2 children and I work more than full time). I could of course not continue at this pace, but I intend to spend most of my free time on the GUI.
Here is my todo list for next weeks:

- Optimize how each process is running (for the moment I use Greenlet because Thread and Process cause blocking problems in the MacOS app. I have to test with subprocess.Popen to avoid hacks in counterpartyd code to works with greenlet)
- clean code (split code, comments, etc…)
- When you start the app, open a small window (with Tkinter) with:
  * start/stop button
  * textarea to display logs (in the MacOS console yet)
  * text fields to update configuration file
- Make a windows exe
- Add a popup confirmation to review transaction before submitting actions
- Add tabs “open orders”, “open bets”, “feeds”
- Add a DEX screen: classical presentation of the “order book” in two columns, with a simplified form to place an order in the top of each column (like btce, havelock, etc…)
- Conduct a survey to find out if it’s worth it to embed the GUI in a standalone webview (Chromium or alternative) to no longer need the browser.
- work with a designer to make an interface to a professional level (I work with several designers who would be interested).

What if there were a “client maintenance” bounty?

It would be great :slight_smile: If I could spend time working on a project that fascinates me without compromising income of my family, I said yes without hesitation.

[font=verdana]Source code:[/font]


XCP-Qt is a GUI for the counterpartyd platform that was developed with PyQt. It has the benefit of being natively cross-platform, and its UI will automatically match the look and feel of the OS. On startup, it optionally starts and runs the counterpartyd server, and automatically kills it on close.

[font=verdana]This is the first XCP client that compartmentalizes the API actions within tabs based on logical action, rather than by API call. The two major sections (Exchange, and My Portfolio), give the user access to all the major XCP actions.[/font]

[font=verdana]In exchange, the user can see a list of all of his open orders, along with how much is remaining if some but not all of the order has been matched. Double clicking on any of these allows the user to optionally cancel any of these orders, without having to memorize or tediously do an API call in the background to view this transaction hash.[/font]
[font=verdana]On the bottom half of the exchange tab, the user is present with a list of all order match objects pending BTCpay (both incoming and outgoing BTCpay). Any that require outgoing BTCPay allow the user to double click and then confirm the amount needed to pay.[/font]

[font=verdana]Portfolio allows the user to see all of his assets, at a glance, separated by address in the wallet. Depending on which address is selected (above), the portfolio page will show the balance of all assets for that address. On the left, there is a way to send any of the assets to someone, and the drop down menu is filtered to only the assets owned by the currently selected asset. The payment spin box only allows entry from 0 up to the amount of the owned asset. [/font]
[font=verdana]Below, there is a panel where the user can issue a new asset, and perform actions on any assets the user owns (send dividends, callback, transfer the asset, and issue more).[/font]

[font=verdana]-Logical satoshi asset unit conversion[/font]
[font=verdana]All assets are presented in the units in which they should be viewed. The GUI automatically converts between the language of the API and the language of the user. For example, if the asset is divisible, the GUI will automatically present a spinbox with 8 decimal places whenever the user needs to specify an amount for this asset (in orders, asset issuances, etc). If this asset isn’t divisible, only whole numbers will be listed and whole number spin boxes will be used. This holds true in tables as well, as the UI looks up the divisibility of the asset before deciding how to format the amount of the asset[/font]

[font=verdana]-Auto-Updating app[/font]
[font=verdana]The app stays up to date with the block chain, and any new orders/portfolio changes that come through on the block chain will be immediately shown without having to restart the app or manually hit the refresh button.[/font]

[font=verdana]-Self-contained app bundle[/font]
[font=verdana]On startup, the app goes through the startup steps, in order, and provides status updates for the launch process in this order:[/font]
1. Make sure bitcoind is up and running
2. Verify bitcoind has an up to date blockchain, and if not it will wait and show progress until it does
3. Starts counterpartyd
4. Makes sure the counterparty db is up to date, if it isn’t show progress of the blockscan
5. Starts the app[/font]
[font=verdana]If any conditions are not met, the app will throw a human readable alert error before closing.[/font]

Platform Support and Installation Guide:
- The app is cross-platform, and can be run on any computer with the dependencies installed (copied from

Python 3

To download and install first clone the repo

then initialize the submodules:

[color=rgb(51, 51, 51)][font=consolas]git submodule init[/font][/color]
[color=rgb(51, 51, 51)][font=consolas]git submodule update --recursive[/font][/color]

[font=verdana]Then run the file with the following parameters:[/font]

[color=rgb(51, 51, 51)][font=consolas]python3 --rpc-user=rpcuser --rpc-password=rpcpassword --bitcoind-rpc-password=PASSWORD --[/font][/color][color=#333333][font=consolas]bitcoind-rpc-user=bitcoinrpc[/font][/color][color=rgb(51, 51, 51)][font=consolas] [–testnet] [–no-counterpartyd][/font][/color]

[font=verdana]If you would like to run the GUI without starting up another instance of the server, run it with the --no-countepartyd option. Any of these options can also be specified in the default counterpartyd configuration file.[/font]

I had hoped to get an executable of the app out as well, but am having some trouble with packaging the PyQt library but will be able to release one shortly once that’s all sorted out.

In the mean time, the script does nothing but once fixed,
[color=rgb(51, 51, 51)][font=consolas]python3 py2app[/font][/color]
[font=verdana]will compile and make the app for mac os x and [/font]
[color=rgb(51, 51, 51)][font=consolas]python3 py2exe[/font][/color]
[font=verdana]will compile and make the app for windows[/font]

Future Plans
The most pressing, unimplemented features are
- Bring the UIs historical transaction history support up to date with I can imagine a transaction history tab built into the app
- Add support for bets and broadcasts
These I intend on rolling out in the next few weeks, and yes, time permitting/ depending on the bounty, I would definitely be willing to continue working on this client as needed.