Yes it has been supported since the launch of tezos however the contract was not publicly advertised in the beginning.
Now @arthurb has published an implementation.
Quoting his announcement on reddit
It is supported. You can deploy
for instance.* More user friendly ...
Questions was solved in another channel (https://t.me/TezosDevelopers).
Answer from BakingBad:
"Tezos supports pubkey revealing for tz2 addresses. You just need to use correct message Tag.
You can do that, for secp256k1
I guess, you set the incorrect Tag"
./tezos-client rpc get /chains/main/mempool/pending_operations
(same but less overhead) http://127.0.0.1:8732/chains/main/mempool/pending_operations
Output is a JSON object. Just parse it using your favorite programming language.
The Tezos command-line client features a few commands for interacting with the Michelson multisig smart contract.
These commands are listed in the section named "Commands for managing a multisig smart contract" of the client manual (https://tezos.gitlab.io/master/api/cli-commands.html).
More gas is required than for a direct transaction, the precise amount ...
No, there is no way to bypass the requirement to ack a transaction. You would have to write your own ledger-tezos app to support this. It can be done, as the baking app signs blocks without interaction using the same key. You would have to code a new instruction to sign without user button.
You can do it with a smart contract. Place the user's funds in a smart contract that takes
A lambda returning a list of operations
A signature by a given key of the above
(technically you don't really want to explicitly pass the counter, you can just assume the one in your storage is the one that was signed)
Checks the signature
Checks and ...
You must sign transactions from tz2 addresses with secp256k1. Eztz's sign function uses Ed25519, so that wont work. Easiest would probably be to just replace libsodium in eztz with something like bitcoinjs-lib.
I'm doing the exact same thing successfully.
I have set up a remote signer and SSH tunneled it to my baking server on port 7878.
It sounds from your description, and the symptom you describe, like you might have done your tunnelling backwards. The remote signer shouldn't initiate any tcp connections to your baking node. The remote signer's firewall ...