Questions about asset descriptions

Many thanks. I think the bug only occurs for numeric name tokens not custom named tokens!

Do you agree?


Any idea why I always get errors?


EDIT: Ignore this post. See replies below.

I checked 46,000 assets from a one year old list (

Length #assets
0 30623 1 30 2 29 3 89 4 479 5 537 ... 37 96 38 99 39 97 40 365 41 304 42 1 43 6 44 6 45 7 46 7 47 0 48 0 49 0 50 44 51 0 52 0 53 0

What the list tells is that most asset descriptions are up to 41 characters. A few are up to 50 but none are longer.

BUT examining the 50 char descriptions further, these are actually not the descriptions. They have shorter url’s pointing to a .json file, which in turn have a longer description.

The longest “real” descriptions I found were 46 chars.

Very likely the max description length is set at 41 in Counterwallet while the max allowed length in the Counterparty protocol is 46.

But my assets above have 52 char descriptions and the source code and the CP protocol specification both allow that.
Admittedly this is on testnet but I am not going to spend real BTC to prove I am right.

If somebody shares the client error log or where in the code or CP protocol spec it says otherwise, I’ll take another look.

Nobody uses very long “real” descriptions because if the asset is any good or has a good name, long description is not really needed.

Edit 1) JP I updated my descriptions from Counterwalllet, the screenshots show that.

Edit 2) WINTERTALES - who the hell knows, maybe there was a bug before v9.55 that allowed these to sneak in.

I opened the DB in SQLiteStudio

The longest description is 252 chars !?!


Thanks for your advice and testing.

Yesterday I tested on production not testnet and found that I got “unspecified” error unless the numerical named asset ID had a description 41 characters or less - the same results as on testnet for me at least!

It also cost me 0.00032076BTC which is more than I was expecting as I read the docco and I thought it said “fee 5430 satoshis (0.05USD) and 0.0001 BTC tx fee (0.1USD)” ?

(there is no way to lower that cost and still guarantee miners accept it right?)

Many thanks

Thanks for testing.


I still get the error “Error making request to undefined: Unknown Error.” when I try your string


What is going on?

They say the limit isn’t enforced on the protocol level (but as far as I can tell, that’s also not true -
I do know that it is enforced in the CLI because I tested this few weeks back.

Here it says from August 2014 and on Testnet, there’s no 41 char limit.

Well, I just changed description on mainnet, for a “paid” (letters-only) asset, to 52 characters.
It worked fine so as far as I am concerned there’s no issue - Counterwallet allows 52 characters for both mainnet and testnet (and maybe more is possible).

If anyone has a problem they should try a different client (Indiesquare Wallet?) or another browser or the CLI.

It also cost me 0.00032076BTC which is more than I was expecting as I read the docco and I thought it said “fee 5430 satoshis (0.05USD) and 0.0001 BTC tx fee (0.1USD)” ?

The minimum transaction fee, yes. But it can be, and usually is, higher. And if you operate from a multisig address, you can pay triple as much.


Did you manage to raise a bug? Any work around for me?


I’ve no plans to raise any bugs, as I said this is working fine for me on both mainnet and testnet and with both alphanumeric and textual assets and there’s no bug report from anyone.

Any work around for me?

Stated above: “If anyone has a problem they should try a different client (Indiesquare Wallet?) or another browser or the CLI.”

Understood. It does not allow more than 41 for me.

Can you please advise how I can show you what I’m doing so you can tell me the stupid thing I’m doing wrong?

Thanks for all your time and patience.

Many thanks for the info.

Counterwallet Testnet was down so I used - I do hope that is acceptable?

I made a new wallet

velvet pretty course autumn tough respect girl commit essence kingdom grown army

Funded with BTC and attempted to make a new asset with description


But for hours I’ve been getting the error

Insufficient BTC at address n2cgcDonaipCEDpUHKXcVjW7QjUmLEkcdM. (Need approximately 0.0006844 BTC.). You must have a small amount of BTC in this address to pay the Bitcoin miner fees. Please fund this address and try again.

Yet the balance has said for hours

Bal: 0.03599999

But reducing the description to 41 and that incorrect error goes away and it works. Attached are logs:

[5/1/2017 21:37:26.478] checkMessageQueue. last_seq: 22295
counterwallet-deps-min.js?v=9f03958320d8:457[5/1/2017 21:37:26.804] feed:receive IDX=mempool
counterwallet-deps-min.js?v=9f03958320d8:457[5/1/2017 21:37:57.524] checkMessageQueue. last_seq: 22296
counterwallet-deps-min.js?v=9f03958320d8:457[5/1/2017 21:37:57.863] feed:receive IDX=mempool
counterwallet-deps-min.js?v=9f03958320d8:457 [5/1/2017 21:38:27.863] checkMessageQueue. last_seq: 22297
counterwallet-deps-min.js?v=9f03958320d8:457 [5/1/2017 21:38:39.795] JSON-RPC Error:

Type: Server error

Code: -32000

Message: {“message”: “Error composing issuance transaction via API: Insufficient BTC at address n2cgcDonaipCEDpUHKXcVjW7QjUmLEkcdM. (Need approximately 0.0006301 BTC.) To spend unconfirmed coins, use the flag --unconfirmed. (Unconfirmed coins cannot be spent from multi\u2010sig addresses.)”, “code”: -32001}

counterwallet-deps-min.js?v=9f03958320d8:457 [5/1/2017 21:38:47.929] TXN CREATED. numTotalEndpoints=1, numConsensusEndpoints=1, RAW HEX=01000000016d7d198fb6fdc4d61b34a64902e867b0639a42f1a85195ad855b0ed2b0614392010000001976a914e7700ae65e7ed041dd1bb44404ae3aa1d61dc75588acffffffff020000000000000000536a4c500b2bb60bf4e8a3be6b536766a99cd60db2ad004880dfc8d8663cdf7143ce43cdea54e8d05599374e0dacbef56736c8cb341a3dd80513c0580e04b9c2c54f43ff8afee7e091c9a2e95fc0f16416c54deb655f2700000000001976a914e7700ae65e7ed041dd1bb44404ae3aa1d61dc75588ac00000000
counterwallet-deps-min.js?v=9f03958320d8:457 [5/1/2017 21:38:47.930] RAW UNSIGNED HEX: 01000000016d7d198fb6fdc4d61b34a64902e867b0639a42f1a85195ad855b0ed2b0614392010000001976a914e7700ae65e7ed041dd1bb44404ae3aa1d61dc75588acffffffff020000000000000000536a4c500b2bb60bf4e8a3be6b536766a99cd60db2ad004880dfc8d8663cdf7143ce43cdea54e8d05599374e0dacbef56736c8cb341a3dd80513c0580e04b9c2c54f43ff8afee7e091c9a2e95fc0f16416c54deb655f2700000000001976a914e7700ae65e7ed041dd1bb44404ae3aa1d61dc75588ac00000000
counterwallet-deps-min.js?v=9f03958320d8:457 [5/1/2017 21:38:47.977] RAW SIGNED HEX: 01000000016d7d198fb6fdc4d61b34a64902e867b0639a42f1a85195ad855b0ed2b0614392010000006b483045022100e31f116dd8d00c1d97af610304f7c866ca7edc0809a3d09c2b3667e68adbf8fe022053fd2cf11a886cdcfb372d3c5a5738d92f551d60f0aab3f8613ccee8367eecdd012102c7f75d42aa177aa0aa46b31480b2dc3d608ce0de1cc450109ffbecf6d0ce9d63ffffffff020000000000000000536a4c500b2bb60bf4e8a3be6b536766a99cd60db2ad004880dfc8d8663cdf7143ce43cdea54e8d05599374e0dacbef56736c8cb341a3dd80513c0580e04b9c2c54f43ff8afee7e091c9a2e95fc0f16416c54deb655f2700000000001976a914e7700ae65e7ed041dd1bb44404ae3aa1d61dc75588ac00000000
counterwallet-deps-min.js?v=9f03958320d8:457 [5/1/2017 21:38:48.320] broadcast:35f8d9d147194c9bb2227a254eee7fa31eefa2231759dae5cb3dd386372eb49f: endpoint=
counterwallet-deps-min.js?v=9f03958320d8:457 [5/1/2017 21:38:48.321] pendingAction:add:35f8d9d147194c9bb2227a254eee7fa31eefa2231759dae5cb3dd386372eb49f:issuances: {“source”:“n2cgcDonaipCEDpUHKXcVjW7QjUmLEkcdM”,“asset”:“A10695164304203958000”,“quantity”:1,“divisible”:false,“description”:“01234567890123456789012345678901234567890”,“transfer_destination”:null,“encoding”:“auto”,“pubkey”:“02c7f75d42aa177aa0aa46b31480b2dc3d608ce0de1cc450109ffbecf6d0ce9d63”,“allow_unconfirmed_inputs”:true}
counterwallet-deps-min.js?v=9f03958320d8:457 [“n2cgcDonaipCEDpUHKXcVjW7QjUmLEkcdM”]

Well, yes, the silly issue with “insufficient” bitcoin balance is a bug and it’s known.
So if that impacts you you may not be able to send BTC or do other things as well.

But I just did it again from my testnet wallet:

So yes, when the insufficient bitcoins bug starts pestering you, I think it’s because the smallest “fragment” of BTC is less than the tx size so you get this stupid error.

But, descriptions can be longer and it can be done directly from Counterwallet.

Why there’s a difference between 41 and more than 41? I think after 41 maybe a different transaction size kicks in, and then the wallet starts looking for larger fragments of unspent outputs. But that’s just my speculation at this moment. The bug with incorrect “insufficient BTC balance” is yet to be solved.

In the meantime you can very likely use Indiesquare Wallet to change description of your wallet (using the same pass phrase as for CW), as well as from the counterparty-client. I’ll try the CLI later this week because I am sure it will work fine as well (and in fact I used it before to create 52-byte long descriptions, but I want to take another look into costs and transaction sizes of 41 vs. 41+.)

Many thanks for your expert investigation and advice.

So are you saying that 41 character descriptions are considerably cheaper than 52?

Did you manage to get any more details about how to have a 52 length one in couterparty?

I’ll try changing the description using indiesquare - is this possible using testnet?

Thanks again.

I don’t know by how much 41 might be cheaper than 52, but 9 bytes is not a big difference. If you look at the transaction size (maybe you need to use Bitcoin explorer) for my 52 byte example above, and compare with yours, you’d probably see that the former is maybe 430 bytes whereas the latter is 421 bytes (or something like that - the point is what matters is the difference).

Since BTC tx fees are calculated on a “per KB” basis, 9/1024 means you’d pay just 0.001% more, so if you normally pay 10,000 satoshis (assuming 20K/KB), you’d pay only 10,010 for 52 bytes. But you could also pay less to begin with (and wait 1 or 3 blocks longer) so in the end the difference is not worth mention unless you are a mega issuer of assets (and no one is).

Note that Counterwallet right now is fairly fixed in the way it calculates fees (that should be improved in the future), so you can use Counter-Tools or other way to set your a lower tx fee. With Counterwallet as of now maybe there’s no difference between 52 and 41 bytes. I issued the above with Counterwallet, by the way, but the fees can vary depending on time and congestion on the network, so if the difference in size is small to begin with, it’s not impossible that a larger transaction be cheaper than a small one (if the first one was created during congestion).

Not sure but I believe 41 is the max amount of characters to include in an op_return encoded transaction.

If that’s the case, then 41 is the max in CounterTools. Other wallets may switch to multisig encoding if longer description, with the expense of a higher cost.

1 Like

Yes JPJA that seems to align with what I’ve found with countertools - max 41 characters.

Two weeks ago when I changed asset description to 52 bytes (above) the transaction was multisig.

This asset description change was made in Counterwallet as shown on the screenshot above, so as long as one doesn’t run into the annoying insufficient BTC balance bug, Counterwallet can do it. (I haven’t had much time and success troubleshooting that bug yet.)

To your point, it could be that when OP_RETURN is used only 41 bytes are allowed.

So in theory maybe “forcing” MULTISIG could help. That’s something I’ve been planning to check in the CLI first (there’s a transaction type option in the client, but I’m not sure if it works, haven’t tried it yet. The default is “auto” and this has worked for me as well, because I successfully set 52 byte descriptions in the CLI as well, but not consistently - sometimes it fails and perhaps that’s when “auto” picks OP_RETURN). bytespersigop took effect in v9.54.

###Workaround for Incorrect "Error composing issuance transaction via API: ['insufficient funds']" Message during Issuance Attempt with Long (> 41 bytes) Asset Description

Firstly, there are correct “insufficient funds” messages. And there may be other incorrect “insufficient funds” messages.

This workaround is for one specific case (although it may apply to others), and that is when you issue an asset with more than 41 bytes in description and have sufficient funds, Counterwallet and the CLI may throw this message.

  • Cause: by default OP_RETURN is used and can’t fit more than 41 bytes in asset description
  • Workaround: use one of other choices from the documentation. Those are multisig and pubkeyhash and if you try the former you’ll also get an error saying it won’t work after 0.12.1, which means you need to try pubkeyhash. That does work.
  • Solution: a bug-free app would consider the length of issuance, and use appropriate encoding. I don’t know why Counterwallet doesn’t always do it (as I mentioned above I was able to change assets to 52-byte descriptions recently on testnet Counterwallet), but probably after multisig was removed it “mostly” worked and because most assets are issued via the API or 3rd party wallets and/or use Enhanced Asset Info, this stayed under the radar. If Counterparty starts using 80 bytes of OP_RETURN, then the default encoding should work (80 byte OP_RETURN seems enabled in the code, but apparently that’s not enough). A new issue existing for this in the counterwallet repo but maybe this will be improved in some other place in the code.


  • If you use Web wallets, until changes in Counterwallet (or elsewhere in the code) fix this, use another wallet or the CLI or the API
    • You can also use 41 bytes, or - even better - consider using Enhanced Asset Info so that you only need a short URL in Description (CoinDaddy and Indiesquare Wallet provide these services, and you can also host Enhanced Asset Info on any other reliable server)
  • If you have the client, just use --encoding pubkeyhash.
  • If you use the API, in issuance parameters set "encoding": "pubkeyhash" instead of "encoding: "auto" (which now means OP_RETURN).