user1983: For a contract, I want to use Constraints.mustPayToPubKey for an arbitrary pubKeyHash (pkh), such as a lucky winner in a lottery.
Question: Does the validator need to check that the transaction sees that pkh (using txSignedBy or similar)?  If so, why?

user1130: 
Does the validator need to check that the transaction sees that pkh?

Yes. There is more than one way to organize the logic though.
Whichever way you structure the lottery, I will assume that the winnings are owned by the script. Any transaction that spends UTxOs owned by the script need to meet the qualifications of the validator.
As you say, one way to construct the smart contract would be to make sure you mustPayToPubkey of the winner. The validator would then need to guarantee that the output of the "pay out winnings" transaction includes the winnings and they are going to the winner's pkh. This wouldn't use txSignedBy, but rather do some combination of checks to guarantee the winnings are going to the correct pkh.
The way I would suggest modelling it is by saying only the winner can claim the winnings. In that case you could use txSignedBy.
This approach is similar to how the vesting example works in the PPP. It doesn't use txSignedBy, but rather just checks that the beneficiary is among the signers, essentially doing the same thing.
You don't even need to specify mustPayToPubKey at that point because it will default to the transaction builder's wallet. See the vesting example's grab constraints.

1983: <p>For a contract, I want to use <code>Constraints.mustPayToPubKey</code> for an arbitrary pubKeyHash (pkh), such as a lucky winner in a lottery.</p>
<p>Question: Does the validator need to check that the transaction sees that pkh (using <code>txSignedBy</code> or similar)?  If so, why?</p>
 1130: <blockquote>
<p>Does the validator need to check that the transaction sees that pkh?</p>
</blockquote>
<p>Yes. There is more than one way to organize the logic though.</p>
<p>Whichever way you structure the lottery, I will assume that the winnings are owned by the script. Any transaction that spends UTxOs owned by the script need to meet the qualifications of the validator.</p>
<p>As you say, one way to construct the smart contract would be to make sure you <code>mustPayToPubkey</code> of the winner. The validator would then need to guarantee that the output of the &quot;pay out winnings&quot; transaction includes the winnings and they are going to the winner's pkh. This wouldn't use <code>txSignedBy</code>, but rather do some combination of checks to guarantee the winnings are going to the correct pkh.</p>
<p>The way I would suggest modelling it is by saying only the winner can <em>claim</em> the winnings. In that case you could use <code>txSignedBy</code>.</p>
<p>This approach is similar to how the <a href="https://github.com/input-output-hk/plutus-pioneer-program/blob/b50b196d57dc35559b7526fe17b49dd2ba4790bc/code/week03/src/Week03/Vesting.hs#L51" rel="nofollow noreferrer">vesting example</a> works in the PPP. It doesn't use <code>txSignedBy</code>, but rather just checks that the beneficiary is among the signers, essentially doing the same thing.</p>
<p>You don't even need to specify <code>mustPayToPubKey</code> at that point because it will default to the transaction builder's wallet. See the vesting example's <a href="https://github.com/input-output-hk/plutus-pioneer-program/blob/b50b196d57dc35559b7526fe17b49dd2ba4790bc/code/week03/src/Week03/Vesting.hs#L111" rel="nofollow noreferrer">grab constraints</a>.</p>
