after digging around a bit more I believe the problem is more than simply encoding. The consumer of my signature (bitcoin-otc's verifier) is expecting the signature output from Bitcoin-Qt which is base64-encoded. I thought that the Armory signature was equivalent but I now think there's a missing byte. Bitcoin-Qt's signature is 65 bytes while Armory signatures are 64 bytes. It looks like Bitcoin-Qt includes a header byte that Armory does not.
Can you make Armory's signatures compatible with Bitcoin-Qt?
key.cpp:
// create a compact signature (65 bytes), which allows reconstructing the used public key
// The format is one header byte, followed by two times 32 bytes for the serialized r and s values.
// The header byte: 0x1B = first key with even y, 0x1C = first key with odd y,
// 0x1D = second key with even y, 0x1E = second key with odd y
bool CKey::SignCompact(uint256 hash, std::vector<unsigned char>& vchSig)
Oh, that's some special format that allows them to do key reconstruction from the signature. Except, I don't even know how to do it, so I couldn't implement it if I wanted. At the moment, it's not even used for anything (that I'm aware of). The core devs gave me some documents about it, but I never grokked them.
Armory signs the data the same way as the rest of the network does, or else it wouldn't get accepted into the blockchain. The signature scheme you're looking at there is special. Perhaps there's a different code interface that you can access that takes the default, DER-encoded signatures that go into the actual transaction serialization.
Or you could implement the key reconstruction for me
