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.
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 https://counterwallet-testnet.coindaddy.io/ - 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
“0123456789012345678901234567890123456789012345678912”
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
BTC
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}
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:
https://testnet.counterpartychain.io/asset/A18240135782950339000
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.
https://www.blocktrail.com/tBTC/tx/d893e5ee4cf3fb6ef72f9f8c6bfc09c7deb71f8f18b5f5fc62bd1c22ea6cf283
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.
OP_RETURN
is used and can’t fit more than 41 bytes in asset descriptionmultisig
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.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.####How-To
--encoding pubkeyhash
."encoding": "pubkeyhash"
instead of "encoding: "auto"
(which now means OP_RETURN
).