(Testers Needed) PeerAssets Community Test 2

Github: https://github.com/peerassets
Donations: PAdonateFczhZuKLkKHozrcyMJW7Y6TKvw

This milestone is reached after completing pypeerassets v0.2 and pacli v0.2.3.
To remind you pypeerassets is the official reference implementation of the PeerAssets protocol made as a library and coded in Python.
Pacli is simple command line user interface to PeerAssets built around pypeerassets.

What is new in pypeerassets?

  • major code overhaul for pypeerassets (~1700 lines changed)
  • performance improvements for pypeerassets (7x speedup in some cases)
  • more PeerAssets protocol functions in pypeerassets (multi-issue_mode decks for example)
  • filtering of invalid cards from the deck
  • deck state is implemented and to be publicly tested now.

What is new in pacli?

  • built using latest pypeerassets
  • implemented per-user configuration using pacli.conf file in /home/$USER/.config/pacli
  • implemented logging, log is saved to /home/$USER/.config/pacli
  • pacli can now show card balances
  • pacli now warns user if card balance is insufficient for card_transfer or card_burn
  • more new features, see tutorial bellow for more details


(Linux only, Windows is not supported for now)


  • ppcoind running in testnet mode
  • some testnet coins (post address bellow if you have none)
  • python3.4 or higher
  • python3-pip

sudo pip3 install pacli

This will automatically fetch all dependencies and install pacli as system wide command.


pacli -h

see here for commands: https://github.com/PeerAssets/pacli/blob/master/README.md

If you see this kind of warning:

/usr/local/lib/python3.4/dist-packages/secp256k1/__init__.py:228: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
self.ctx, res_compressed, outlen, self.public_key, compflag) 

is just a warning, not an error. We need to wait for this to be resolved in the library we use.

Goals of this test

  • get user feedback and allow us to polish user tools (pacli)
  • gather enough of random data for tests and analysis, data like decks and card transfers
  • check if our DeckState code is doing the job well (double spending prevention)
  • find bugs, fix them

This is first usable PeerAssets release so far, with most of functions presented to user in friendly way.
Please dedicate some time to help us test it out. We very much depend on community helping us out with this one.

More detail tutorial and possibly video to be released later.



pacli -h

show all commands

pacli -status

show current network, all subscribed decks and their card balances

pacli -newaddress

generate a new address and load it into wallet

pacli -addressbalance

show card balance of the address

pacli deck -search “My little pony”

search for deck called “My little pony”

pacli deck -list all

list all decks on the network

pacli deck -info deck_id

show detail deck information,
use this command if you need full deck ID hash and not shortened id.

pacli deck -subscribe deck_id

subscribe to this deck to enable balances and card listing for this deck

pacli deck -balance deck_id

show balances of all addresses involved with this deck

Complex operations take JSON-like sturucture as argument, mimicking peercoind JSON-RPC interface.

  • amount variable is always a list
  • receiver variable is always a list

pacli deck -new ‘{“name”: “My own asset”, “number_of_decimals”: 1, “issue_mode”: “ONCE”}’

issue a new asset named “My own asset”.

pacli card -list deck_id

list all card transfers related to this deck

pacli deck -checksum deck_id

verify deck checksum, checksum is difference between issued cards and balances of all the addresses.
If it is not zero, something is wrong with deck balances. This function will return True if all is fine.

pacli card -burn ‘{“deck”: “d460651e1d9147770ec9d4c254bcc68ff5d203a86b97c09d00955fb3f714cab3”, “amounts”: [11]}’

burn 11 of card on this deck, this transaction will be denied if you have no cards on this deck.

pacli card -issue ‘{“deck”: “hopium_v2”, “receiver”: [“n29g3XjvxqWLKgEkyg4Z1BmgrJLccqiH3x”], “amount”: [110]}’

issue 110 cards to n29g3XjvxqWLKgEkyg4Z1BmgrJLccqiH3x, this transaction will be declined if you do not own deck issuing address.

pacli card -transfer ‘{“deck”: “08c1928ce84d9066f120”, “receiver”: [“n1GqTk2NFvSCX3h78rkEA3DoiJW8QxT3Mm”, “mv8J47BV8ahpKq7dNXut3kXPgQQCQea5FR”,
“myeFFDLXvpGUh8gBPZdCNEsLQ7ZPZkH7d8”], “amount”: [1, 9.98, 200.1]}’

transfer cards of “08c1928ce84d9066f120” deck (queried by short id, it is clementines deck) to three different addresses.
This transaction will be denied if you have no address which holds cards of this deck or if your balance is not sufficient.


I just wanted to remind everyone of the following…

Hi, I have synced testnet now and installed the newest pacli version. Can do some tests this week.

My testnet address is: msr8sCnZzv8ip1Vo7Tu5eaVyXXy7C98Kmu

Have already received some assets last round from another member.



So was anybody able to do any testing work on this yet?

I’m currently trying it out. Unfortunately, even pacli -h throws an error:

 File "/usr/bin/pacli", line 11, in <module>
    load_entry_point('pacli==0.2.4', 'console_scripts', 'pacli')()
  File "/usr/lib/python3.4/site-packages/pacli/__main__.py", line 629, in main
  File "/usr/lib/python3.4/site-packages/pacli/__main__.py", line 44, in set_up
    assert provider.getinfo()["connections"] > 0, {"error": "Not connected to network."}
  File "/usr/lib/python3.4/site-packages/peercoin_rpc/peercoin_rpc.py", line 82, in getinfo
    return self.req("getinfo")
  File "/usr/lib/python3.4/site-packages/peercoin_rpc/peercoin_rpc.py", line 69, in req
    "jsonrpc": "1.1"})
  File "/usr/lib/python3.4/site-packages/requests/models.py", line 866, in json
    return complexjson.loads(self.text, **kwargs)
  File "/usr/lib64/python3.4/json/__init__.py", line 318, in loads
    return _default_decoder.decode(s)
  File "/usr/lib64/python3.4/json/decoder.py", line 343, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib64/python3.4/json/decoder.py", line 361, in raw_decode
    raise ValueError(errmsg("Expecting value", s, err.value)) from None
ValueError: Expecting value: line 1 column 1 (char 0)

Am I missing a dependency? It looks like that. I’m using the ppcoind daemon 0.5.4-beta for 64 bit from peercoin.net in testnet mode and I’m on a Linux machine.
Ah, I’m seeing now the "“error”: “Not connected to network.”. But I’m connected with ppcoind, with 7 connections. Do I have to open a port or something like that?

Maybe an iptables rule that prohibits pacli from calling the RPC?

Just a wild guess.

Yes, I suspected something like that … the error seems to be generated by the peercoin_rpc module.

When I call “getinfo” via a subprocess.call() in a test Python script it works, but using the peercoin_rpc module it doesn’t.

How can I spot and desactivate such an iptables rule? I’m not familiar with iptables (only did a bit of copy-and-paste configuration).

Edit: Looking at the last lines of the error, it seems to be more probably a encoding error.

Edit2: Confirmed. I was using a non-ASCII rpc password, that was the problem. Now pacli -h works. Will now continue with the tests.


I’ve successfully tried the first couple of commands.

To issue own Peerassets and play around with them it seems I would need testnet coins. Can I have some?

My “PACLI” testnet address is: muyWBBPhtWeyM37KZ4hJxYpX1woRkT8YxC

With ppcoind -testnet getbalance, I’ve got the following balances now (is this correct behaviour? It seems a bit strange with the negative balance.): It’s a totally fresh testnet wallet.

    "" : -0.63000000,
    "MoonRocks" : 0.01000000,
    "PACLI" : 0.00000000,
    "PAPROD" : 0.62000000

The negative amount is a common accounting error in bitcoind and ppcoind. Did you recently use sendfrom or move?
Accounts in bitcoind/ppcoind tend not to work the way most people seem to expect them to.
This is separate from pacli. The PACLI account is only used as the default address to issue assets with so if you plan to do so I would recommend sending some testnet coins to one of the addresses of that account in order to cover transaction fees for deck spawn and issuances. If you would like to check your balance of testnet assets the command is pacli --status

Thank you for the testnet coins! In my previous post, the command that lead to a negative balance was “listaccounts”, not “getbalance”. Now the “” balance continues negative (-0,63) and is exactly equal to the sum of the “MoonRocks” (that were sent to me in the previous test) and the “PAPROD” accounts.
The testnet account was never used prior to my first pacli tests (no “sendfrom” or “move”). Nevertheless, it is the same wallet I also used long time ago for real Peercoin transactions, but it seems the testnet datadir and the normal datadir are totally separated so I think there should be no interference?

OK, now I issued my first asset (deck). With 3 decimals it seems to have costed me 100 testnet coins. Name is “Asadito” and id 808ebcca1e246298cdb8b6ea7fbcc3105721daa7a9adac56498c8575dcf722cf

Balance (via pacli -status), however, is 0.

Perhaps first bug detected: pacli card -list 808ebcca1e246298cdb8b6ea7fbcc3105721daa7a9adac56498c8575dcf722cf
gives me an error:

Traceback (most recent call last):
  File "/usr/bin/pacli", line 11, in <module>
    load_entry_point('pacli==0.2.4', 'console_scripts', 'pacli')()
  File "/usr/lib/python3.4/site-packages/pacli/__main__.py", line 665, in main
    list_cards(provider, args.list)
  File "/usr/lib/python3.4/site-packages/pacli/__main__.py", line 382, in list_cards
    cards = pa.validate_card_issue_modes(deck, all_cards)
  File "/usr/lib/python3.4/site-packages/pypeerassets/protocol.py", line 177, in validate_card_issue_modes
    return [next(i for i in cards if i.type == "CardIssue")]

pacli deck -checksum (with the same deck_id) gives me an “ValueError: No cards on this deck.” OK, I have no cards issued still.
Issing cards leads to the following:

pacli card -issue '{"deck": "Asadito", "receiver": ["muyWBBPhtWeyM37KZ4hJxYpX1woRkT8YxC"], "amount": [110]}'
You are trying to issue cards on a deck which has not been confirmed yet.
/usr/lib64/python3.4/site-packages/secp256k1/__init__.py:228: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
  self.ctx, res_compressed, outlen, self.public_key, compflag)


and balance on the “Asadito” deck keeps “0” (although the address is the same than mine). OK, perhaps the network is a bit slow and I have to wait :wink:

Edit: Now a few blocks later, I get the correct balance with pacli card -list, but with 0 confirmations, but pacli -status stays at balance 0 for the Asadito asset.

The errors are gone, I think there is simply an exception handling missing for situations where no cards are issued still.

Ok so the MoonRocks account in your wallet was created during a previous version of Pacli (prior to Test 2). When subscribing to a deck it use to import the p2th key and name the account according to the deck name. This is no longer the case.

I do not see the Asadito deck listed which would explain the card --list error you’re seeing. Can you check to see if the transaction ever left your mempool?
You would be the only one capable of seeing it come up after pacli deck --list all but the transaction would have 0 confirmations. The TXID was imported due to automatic subscription of your own newly created deck.

I believe this is what you’re refering to https://github.com/PeerAssets/pacli/issues/7
The Issue was closed but it seems that it should be reopened.

Thank you for the tests! It’s greatly appreciated.

Edit: Was the deck issuance mode set to ONCE? It seems the card validation process needs exception handling for ONCE issuance modes. Will open up an issue for that :slight_smile:

Also, I was able to recreate the negative account balance through the use of the ppcoind move . There are a few ways this can happen. Here’s a discussion about it

I think you’re right, the “Asadito” transactions seem to be still stuck in my mempool. They have still 0 confirmations. What can be done to publish them?

Maybe it has to do something that I sent the first issued Asadito assets to the same account that issued them?

As you assume I used “ONCE”. I simply copied the original example from the second post of this thread and changed name and decimals.

This weekend I will try out another asset issuance.

are the Asadito transactions confirmed?
I can see the asset on (Mercator blockexplorer for PA)

Seems so. It’s also listed when using pacli deck --list all now.