Questions about asset descriptions


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.


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).