They inspect the state of the .pox contract as it was when the PoX anchor block was mined. The stacker is required to supply a BTC address when they stack directly, and a delegated stacker may either supply a BTC address (in which case, it must be used by the delegate when they lock up the STX), or defer to the delegate to do so on their behalf (e.g. so the delegate can take care of PoX reward disbursal out-of-band).
Nope.
SIP-007 also describes a way to move STX via BTC transactions, and a way to stack STX via BTC transactions. The reason it’s limited to these two options is because (1) these transactions contribute to the block’s total compute budget, and (2) the sender of these transactions does not pay a STX transaction fee. Instead, all Stacks nodes must process these on-BTC transactions, and must do so before considering any Stacks block transactions (meaning, the total compute budget available to the block is reduced by the budget consumed by the on-BTC transactions’ use). As such, arbitrary smart contract deployments and contract-calls from BTC transactions are not supported, and likely never will be, because it turns out that it’s unnecessary.
To run arbitrary Clarity code from a Bitcoin transaction, you’d structure the smart contract to only run the intended code if the caller can prove that there exists a Bitcoin transaction that contains whatever well-formed data that the smart contract needs. Then, once the Bitcoin transaction gets mined, the smart contract would allow anyone to send a corresponding Stacks contract-call transaction that contained a Merkle proof that the transaction was mined as one of its arguments. The smart contract function would authenticate the transaction with the Merkle proof, parse the transaction, and extract any useful data (e.g. an OP_RETURN, the sender’s public key, the payment amount, the recipient(s), etc.) that is needed for the contract-call to complete. This can be achieved today, even in the presence of flash blocks, via MagicStx’s clarity-bitcoin.clar code (which seems based on my clarity-bitcoin.clar code).
In nearly all cases, the Bitcoin transaction will need to include a value that represents the sender as a STX address (since tx-sender will not be the Bitcoin transaction sender). The biggest challenge to doing this today is that principal-of is broken (but fixed in 2.1). principal-of would be useful here because you could use it to convert one of Bitcoin transaction’s input’s public keys into a STX address, thereby ensuring that the smart contract can automatically deduce the STX address of a Bitcoin transaction (note that the resulting address would be a re-encoding of the Bitcoin address, and thus all the concerns here apply regarding derivation paths). You could also use principal-of to verify a signed payload in the Bitcoin transaction’s OP_RETURN, for example, and use that to deduce the STX address if it’s not evident from the Bitcoin address (which in turn permits you to use the status quo’s derivation paths). But principal-of being broken isn’t insurmountable if you want to deploy something today; you’d just need to add some kind of “pre-registration” process for new users, which binds their STX address to a public key in the smart contract before they send the Bitcoin transaction. This pre-registration step could be handled by the smart contract author on the user’s behalf.
Once the user sends the Bitcoin transaction, anyone can relay it as well as the proof to the smart contract (e.g. the smart contract author could do this), and the Clarity code associated with that transaction would execute “as if” the Bitcoin sender had called it. Again, the biggest challenge with this design pattern is making sure that the Bitcoin sender is properly authenticated (and converted to) a STX address, and this is solvable today and easily done in Stacks 2.1.