SENDER always points to the caller's address.
SOURCE points to the implicit account that initiated the current transaction.
SmartPY example: https://smartpy.io/ide?cid=QmevNhUmzeDBzi5uYyxcWdMphrqurJz8TGiVQpeJRgKu58&k=1adea9375ecba75eaab6
This functionality is not available in Taquito, however, if you need that kind of information in your dapp, you can use an indexer, for example, with the TzKT API, you can retrieve a list of smart contracts.
Flextesa comes with 2 preinstalled accounts: Alice and Bob. You can find their secret key in the link that you provided (the value after unencrypted:):
The advantage of big_map a (map b c) over big_map (pair a b) c is that it allows to iterate over all the bs of a specific a. In your case, IIUC, this means iterating over all the token ids that a given address owns. I guess this might be useful in some occasions but here is what it costs:
storage cost: if you want to minimize the amount of tez that is burnt ...
Big maps are lazy while regular maps are not:
If you have big_map (pair nat address) nat, each big_map update will consume O(1) gas¹.
If you have big_map nat (map address nat) (where nat key is token_id), each big_map update will cost O(size(map address nat)) for the corresponding token_id. So the operation cost will grow as the number of token holders ...
I believe you are talking about the ledger property.
The spec specifies this:
Single asset contract
big_map %ledger address nat
where key is the owner's address and value is the amount of tokens owned.
big_map %ledger (pair address nat) nat
where key is the pair [owner's address, token ID] and value is the amount of tokens owned.
No, there is no such opcode. You can however add functionality to you contract that puts it in a final state, sends any funds in it to a designated heir contract, and then rejects all incoming transactions.
The main benefit of such an instruction would be an automatic transfer of existing resources and tokens to a heir contract. However, the current Tezos token contracts do not seem to support "inheritance".
It also would allow to save space for the contract storage, but this is secondary issue as compared to the safety of resources.
Without such a ...
The callback_address can be tz1...%getProofsCallback.
The smartpy code would then look like:
c = sp.contract(TGetProofsResponsePayload, callback_address).open_some()
The CONTRACT instruction CONTRACT %name t has annotation as you can see and those cannot be dynamic.
To get the address with entry_point information you can do:
# when building the callback