Thanks for adding QuadrigaCX.
The second biggest exchange in Canada right now is https://www.cointrader.net/
Maybe you could replace CaVirtEx with them.
Cheers.

I have a similar but different problem:
I've been able to sign and send single input transactions from a multisig address using bitcoind like this one:
https://blockchain.info/tx/68b45d27ca8405285b4d5490095bfad50ac94c314b75e82bd976e8b40d435408
But, after signing a spent from multiple inputs, I was unable to send the following transaction from bitcoind, it also failed on blockchain tx:
https://blockchain.info/tx/6bf129bc2ef572fbf61af3ff181dc080a69adf8d0951be55d3f6588534d3645d
I got it to work by transmitting it through the same service you did: coinb.in.
Why did the transaction not send from bitcoind? Do I need to connect to a certain node before I send?

0.075BTC payment acknowledged. Thank you.

While I agree with your statement that I still maintain that it is the responsibility of the person posting the bounty to clearly outline what is to be done. In this case, you said Base58Encode and Base58Decode, and that is what I did according to the common definition of the bitcoin community (that is why I quoted point 4 in the article you later stated as authoritative on the definitions.) This doesn't mean you need to be more technically aware than the person filling the job, but it does mean that you need to understand and be clear about the job requirements. When there was a disagreement, I offered up documentation of a common held view, you returned with: well, that was not what I was wanting I'm sorry, but that is unfair as you can keep changing your mind and the requirements as the job progresses, which is what you have been doing. Originally it was base58encode, then base58encode plus '1s' character addition and in your latest post you again add more work, stating I should also do whatever is needed to prepend the base58 string with the requirements of p2sh. To be fair, you should pay the bounty for the work that has been done and negotiate a price with the worker for additional work. As it is, you are holding me hostage to continue doing more work to receive the pay due me for the work I've already done.

Never-the-less, regarding 1, that the added work of encoding the '1s' characters is still not done, you must have overlooked my post from May 21, 3:43:13. Note the addition to the front half of the code that counts the number of zero-bytes and adds the appropriate number of '1' characters and the corresponding test and output. I did the extra work anyway so that we could move on.

Please pay.

And by all means, contact a moderator if you think I'm being unfair.

For the sake of thorough code, here is some Mathematica that prepends the correct number of leading '1s' according to the Base58Check criteria when you put in the n->25 optional argument.
It produces the correct result with the number you give:
About your other comments, I don't agree that you have the right to refuse pay based on 4 and 6 as the added work of performing the Base58Check was never part of the bounty described in the OP, and I went beyond the requirements of the bounty to provide you with the additions to the code you wanted.

According to the OP, on which the bounty is detailed, the bounty hunter was to do a base58 decode and encode:
There is no mention in the OP as to the number or nature of leading '1s' to include.
However, according to the document, https://en.bitcoin.it/wiki/Base58Check_encoding, which is the one you encouraged me to read, it defines what is meant by a normalized base-58 encoding in point 4:
I refer your attention to the last sentence, that the result should have no leading base-58 zeroes (character '1').
This is precisely the functionality provided to you on May 20 at 4:22pm when you use the default function without specifying n, the base-58 encoding with no leading '1s'.
What you have been asking for since is the next step, which is the Base58Check, and beyond the scope of the bounty as described.
I am open to discuss this further if you wish; however --- respectfully --- I submit that the bounty is already completed and that no more work is required on my part.
Please send 0.075BTC the bounty to: 19t2j4ZHfaNf1hX7YEDLZpdURcwvGywBhc

If you know the byte length you want encoded, you could do this instead:
and test with
The first column doesn't define a byte length and the second does. In the second column, you always get the "right" amount of leading '1s', even if you get a value that would normally result in too few '1s'

BTW, this is the only thread I have been reading. I found my own mistake this morning when I was doing the RIPEMD-160 in Mathematica. I started that before I saw your post above. My code is very similar to yours, with minor differences:
I prefer putting j ranges on the LHS of the function rather than with an If on the RHS. Other than that, things seemed quite similar. I also defined my Rotate function in a slightly different way then you:

Here is the fixed decode:
You can test these functions with:
and

I realize I botched this when I caught that after z should come 21 not 11 (all the leading unprinted digits are 1s), so here is the fixed version:
You can call it with a single parameter and get the shortest version of the number, or specify the number of digits (n) as an option.
I'll fix the decode in the next post, as it is wrong too. Sorry about that.