I follow this guide at http://counterparty.io/docs/multisig_counterwallet/ and can’t get thru the last point i.e. to send some btc to multisig counterwallet. Shed me some lights. Thank you.
Error making request to UNKNOWN/Default: JSON-RPC Error: Type: Server errorCode: -32000Message:
Bad status code returned: ‘500’. result body:
'{“result”:null,“error”:{“code”:-26,“message”:“64:
bad-txns-too-many-sigops”},“id”:0}
'.
I get this error also, no matter what I try to send to the multisig.
Turns out to be this:
I got the same issue (bad-txns-too-many-sigops) with the current counterparty wallet when trying to use a 2of3 MultiSig.
The PR is merged but is it also deployed to the https://wallet.counterwallet.io?
Is MultiSig support stable or considered experimental? Issuing a token from a MS address and then not being able to spend it would be a disaster for an issuance of an asset.
If MS is not supported well anymore, how about Trezor support?
Thanks for doing some troubleshooting on your own 
I think MultiSig wasn’t considered experimental, it was initially released last year, but as I recall it was limited in some ways.
In any case, to answer your question, as you can see this fix was merged into develop, not yet in master, so some additional QA would be necessary before it can be deployed and then the developers would have to agree to deploy it.
Although anyone could pull develop code and install it, I think it’s quite complex for a casual user.
In terms of h/w wallets, I know there’s some interaction going on with Ledger and the guys from Indiesquare Wallet know more about that. It may be a few weeks before there are further news, though. I think at this stage they need some additional information from Ledger and then they can try to support Ledger.
it is possible - but probably not worth it - to use Bitcoin Core and counterparty-client to craft multisig transactions manually, but it’s a ton of steps (maybe 10) in the CLI. If you’re interested in tinkering with that you could try, or when I find time I could post a tutorial similar to this CLI how-to.
Thanks for your answer!
One other question:
I tried to use Armory offline addresses but get errors when trying to spend or issue an asset.
Maybe it is because I added the address before I did a tx on Armory (to reveal the pubkey).
Is it possible to issue an asset directly from a offline Armory address?
I need a secure way to issue (unlimited) tokens. A normal address does not give the level of security I want to get.
So either MS, offline Armory or hardware wallet would be required.
To only transfer assets to offline armory is not enough, but to transfer ownership if the issuance is not supported might be another viable option. Does that work?
Is it possible to issue an asset directly from a offline Armory address?
I think it is (I assume it’s your address, which you have control of) - basically you need to create a Counterparty transaction first (which you can do in counterparty-client on your computer, assuming you haveBitcoin Core addrindex and counterparty-server, or Federated Node with counterparty (which includes Bitcoin Core, counterparty-server and counterparty-client)). The nice thing about Federated Node is it runs out of Docker with persistent volumes on the host, so you can install it easily and it’s configured on the fly. Then let it run for 2-3 days until the blockchain and counterparty DB are downloaded (http://counterparty.io/docs/federated_node/ has the documentation and instructions).
About creating tx outside of CW, take a look at this:
If you know some JSON, you could use the API, but if you’re more comfortable with the CLI you’d just use the issuance action.
Example for Testnet:
/usr/local/bin/counterparty-client --config=/home/user/.config/counterparty/client.testnet.conf \
issuance --source YOUR-ARMORY-ADDRESS --quantity QUANTITY --asset ASSET-NAME \
--description "ASSET-DESCRIPTION"
It’d spit out the same raw unsigned transaction as in the how-to I linked in this comment, but instead for send it’d be for issuance. Then you’d sign and broadcast that raw transaction with Armory.
If you want to decode the raw transaction to see what’s in it before you broadcast, you can do it out-of-band using another system (e.g. the public development server of CoinDaddy).
To only transfer assets to offline armory is not enough, but to transfer ownership if the issuance is not supported might be another viable option. Does that work?
Yes, you can use --transfer-destination after the asset has been issued (also use --unconfirmed if you haven’t waited for 6 confirmations).
$ counterparty-client issuance --help
usage: counterparty-client issuance [-h] --source SOURCE
[--transfer-destination TRANSFER_DESTINATION]
[--quantity QUANTITY] --asset ASSET
[--divisible] --description DESCRIPTION
[--fee FEE]
optional arguments:
-h, --help show this help message and exit
--source SOURCE the source address
--transfer-destination TRANSFER_DESTINATION
for transfer of ownership of asset issuance rights
I think you can’t issue 0 quantity, but that’s an interesting question so let’s try:
:~$ /usr/local/bin/counterparty-client --unconfirmed --config=/home/user/.config/counterparty/client.testnet.conf issuance --source n4D7ndiC4yLZxhAf726uMHXC914sEuUAcg --quantity 0 --asset ZEROQTY --description "test for 0 quantity issuance"
[2016-11-01 22:11:01][INFO] Running v1.1.2 of counterparty-client.
[2016-11-01 22:11:02][INFO] Transaction (unsigned): 0100000001789131f77fa4197014a7d616e543e24d33cb43bb246ec2f78eaabc337cdbf18d010000001976a914f8eb547223b286af4c069845bab650951de0ba8988acffffffff020000000000000000456a43ef337fb72f7e0914e5dd209539337347297a11169a8bbacd8661c5379215dc76e20f0e5eec9e426a75fa97e5cdde8c7e4fc2a9a13cf83fe851682205f7aabe2e27fa37bb423100000000001976a914f8eb547223b286af4c069845bab650951de0ba8988ac00000000
Sign and broadcast? (y/N) y
[2016-11-01 22:11:04][INFO] Transaction (signed): 0100000001789131f77fa4197014a7d616e543e24d33cb43bb246ec2f78eaabc337cdbf18d010000006b483045022100f996f54277e1d981d1e8af99dfb536cebf3e138aeff57d77b1fa146f11d329a202202e7bae59bf7f52378d174ccbb012f8db3379328b4a5cd9e192dfaee12acac53301210265f9763ea8f857571a003a9c7abddc9875a3dd921dbdb15c1659944869f945cdffffffff020000000000000000456a43ef337fb72f7e0914e5dd209539337347297a11169a8bbacd8661c5379215dc76e20f0e5eec9e426a75fa97e5cdde8c7e4fc2a9a13cf83fe851682205f7aabe2e27fa37bb423100000000001976a914f8eb547223b286af4c069845bab650951de0ba8988ac00000000
[2016-11-01 22:11:04][INFO] Hash of transaction (broadcasted): 2b3f4a924fe0974781ea6e094b15aec73d2f7b561796de2a50804d4b5a64802d
Apparently it works. I haven’t waited so I can’t see it yet, but I suggest you try on testnet first and then check the entire procedure. There’s an explorer here - https://testnet.counterpartychain.io/issuances - but you can also see in your own client using the balance or wallet command.
Note that the testnet is quirky and can take a long time for tx to get confirmed because people are abusing testnet quite a lot.
I was going to say if you can’t issue the quantity of zero then you would need to both transfer the ownership of the asset as well as all issued assets, but if it’s possible (it seems it is) you just need to issue the asset and transfer it to another address.
Pay attention to divisible/indivisible! Some people discovered that distinction too late (after the launch).
If it’s very important to you I’d also suggest to have a backup of the private key or other method stored someplace safe as per usual bitcoin safety best practices.
Cool - it just got confirmed - https://testnet.counterpartychain.io/asset/ZEROQTY.
I’ve been trying to look into this further in free time, it appears that bad-txns-too-many-sigops happens when one of addresses used to create the multisig address tries to send funds to the multisig address.
On the bitcoin (underlying) side here’s what the error means:
// Check that the transaction doesn't have an excessive number of
// sigops, making it impossible to mine. Since the coinbase transaction
// itself can contain sigops MAX_STANDARD_TX_SIGOPS is less than
// MAX_BLOCK_SIGOPS; we still consider this an invalid rather than
// merely non-standard transaction.
Apparently (the link to Github in earlier comments) it’s already fixed, but not yet in “production” Counterwallet, it’s in develop (aka testing version).
But even now I can use multisig just fine if I use addresses that aren’t in the multisig (say I have multisig that’s 2-of-2 and then I use a 3rd address in Counterwallet to send to the multisig address - no issue with that).
I created few multisig transactions in both the CLI and Counterwallet today, e.g. https://testnet.counterpartychain.io/address/2_mxuskkUxSRwTU9ddR86Z2GT1poyq2JEVnY_mzJAEHoho8ddcRoByPRnpHRLnW5r4D2UmN_2
But I need to do some additional work before I document the exact steps.