We just need something similar on the bitcoin end too...
Why don't you just hold the GATEBTC until you get a signed message telling you where to send it?
The default Bitcoin client can sign a message with private key corresponding to its address. So you could just have the person send you a signed message from the Bitcoin client saying "send GATEBTC from <bitcoin_txid> to <account>, sincerely, <signer>". Then check:
- <bitcoin_txid> represents a transaction that exists
- And is sufficiently confirmed
- And is sending BTC to your ingress address
- And has not yet had its GATEBTC claimed
- And has at least one input controlled by <signer>
Then you issue GATEBTC (or whatever your gateway's BTC IOU UIA is) to the corresponding address.
The message could be published somewhere on the blockchain, but it's easier (and doesn't require them to pay a fee) if you just have an HTTP(S) interface on your webserver to submit the message.
You could also have semantics to remember the association between a BTC address and account, i.e. the message could instead be:
"if your ingress address gets any BTC from <my_address>, please send the GATEBTC to <titan_account>, sincerely, <signer>"
Then you just check that <signer> controls <my_address>. The user can then send you BTC in any number of transactions, past or future. As long as the user has at least one tx input from <my_address>, it will all go to the right place. If the user forgets and you get BTC from unknown addresses, you can just hang onto it until one of the addresses files a signed message claiming the new GATEBTC. Of course, with the way Bitcoin makes a new change address by default and de-prioritizes recent balances, it may be a little extra work to make sure <my_address> always has a balance that is included.