<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>

CC BY-SA 4.0
2021-08-12T17:50:11.080Z
But what would happen if the tran does not see the pkh? Why can he **not** get paid in that case?
Kwaggy
CC BY-SA 4.0
2021-08-12T17:59:28.913Z
I'm not sure what you mean by "tran does not see the pkh." Do you mean if the validator doesn't see the pkh as a signer of the transaction?
Mitchell Turner
CC BY-SA 4.0
2021-08-12T18:03:27.007Z
Yes. Why is that a strict requirement?
Kwaggy
CC BY-SA 4.0
2021-08-12T18:07:50.380Z
Isn't that the behavior you want? You only want the winner to be able to spend the lottery winnings? When you spend ADA from your own wallet, the transaction is only valid if the owner of the ADA signed the transaction. This is the same as that, but the winnings are at the script address, rather than your own wallet, so you need write those requirements into the validator.
Mitchell Turner
CC BY-SA 4.0
2021-08-12T18:08:43.787Z
If you didn't have that requirement, anyone could spend the winnings.
Mitchell Turner
CC BY-SA 4.0
2021-08-12T18:20:11.973Z
I guess I don't understand what forces the winner to be hooked up to the transaction in the first place -- is that perhaps one of the purposes of the constraints when submitting the transaction?
Kwaggy
CC BY-SA 4.0
2021-08-12T18:20:44.580Z
More questions: So there seems to be two approaches, either focused on the current owner who `mustPayToPubkey` or as you recommended , focused on the winner who `mustSpendScriptOutput `. First why is your approach preferred -- simply because the use-case uses it? Second, is it wrong to use both approaches together? And third, why are both approaches allowed, being that it (apparently) only serves to complicate  the matter?
Kwaggy
CC BY-SA 4.0
2021-08-12T18:33:24.220Z
You might be thinking about what smart contracts do slightly wrong. I pointed out in your other question here: https://cardano.stackexchange.com/a/2315/1130. Scripts on chain are completely passive. In the case of a lottery, I'm imagining after a series of events, there is a pot of money that has been won by some pkh. We want that pkh to have access to the money. We have two options: Allow _anyone_ to submit a transaction to send those funds to the winner pkh, OR allow the pkh to spend the money however she chooses. Since only the winner is motivated to submit a tx, I went with that approach.
Mitchell Turner
CC BY-SA 4.0
2021-08-12T18:40:05.690Z
Scripts take of space on the chain and cost gas to execute. Simple is better. Not to mention safer. And, as I mentioned. Only the winner is motivated to submit a tx to claim the funds, there is no need to provide multiple ways to access the money. Both approaches are allowed because there are infinite different smart contracts people might want to write. It's easy to imagine a script that would require you to send funds to some wallet. Maybe a tip to the contract writer or something :P
Mitchell Turner
CC BY-SA 4.0
2021-08-12T18:46:01.790Z
I see, so according to your approach, the winner would be notified externally (e.g., email), and thereby be instructed to open their wallet in order to request request the winnings -- such that if they fail to do so, they forfeit?
Kwaggy
CC BY-SA 4.0
2021-08-12T18:48:15.210Z
I also do not understand what you wrote above _Allow anyone to submit a transaction to send those funds to the winner pkh_. This obviously would not just be anyone but rather only one entity: The owner of the lottery who actually has the funds to disburse!
Kwaggy
CC BY-SA 4.0
2021-08-12T18:54:57.013Z
I imagine that the funds are on the script, and no-one owns them. That's the point of a decentralized smart contract after all. If there is some central owner of the funds, there would be no need for a smart contract on-chain, you could just have an agreement off-chain.
Mitchell Turner
CC BY-SA 4.0
2021-08-12T18:59:17.757Z
Thanks for clarifying that last point.  Kindly advise regarding your approach that the winner would in fact need to proactively submit tran in order to claim.
Kwaggy
CC BY-SA 4.0
2021-08-12T19:14:11.000Z
Yes. Since the script is passive, the winner wouldn't get paid unless they proactively submit a "claim" transaction of some sort. This of course could be automated off-chain, either to notify the winner or possibly have the wallet submit the "claim" transaction automatically.
Mitchell Turner
CC BY-SA 4.0
2021-08-12T21:07:17.677Z
FYI the [SimpleEscrow plutus use-case](https://github.com/input-output-hk/plutus/blob/1f9569aec76e2a4c641a16807d5a157c07db69c9/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L148) uses `mustPayToPubKey`
Kwaggy
CC BY-SA 4.0
2021-08-12T21:22:51.543Z
That's a perfect example of a transaction that needs to send outputs to different parties. Notice in the validator https://github.com/input-output-hk/plutus/blob/1f9569aec76e2a4c641a16807d5a157c07db69c9/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L113
it only checks that the payee was paid. The line you linked isn't technically necessary, it's just explicitly saying you want the rest of the money. You could send it anywhere and the validator would still pass, as long as the payee gets their due. You would probably never do that, but it's a good example of how validators stay simple.
Mitchell Turner
CC BY-SA 4.0
2021-08-12T21:40:20.477Z
I do not understand your assertion that `mustPayToPubKey` is superfluous (_isn't technically necessary_).  Where else in the [`redeemEp`](https://github.com/input-output-hk/plutus/blob/1f9569aec76e2a4c641a16807d5a157c07db69c9/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L136) contract do you see instructions for sending money to target, or only allowing target to claim?
Kwaggy
CC BY-SA 4.0
2021-08-12T21:57:56.623Z
`redeemEp` is off-chain code for building a transaction. There is nothing preventing me from writing different off-chain code that builds a different transaction as long as it satisfies the same on-chain validator (validate). The validator doesn't mention anything to do with the our public key, only the payee's key. So for a transaction to be valid, the constraint `Constraints.mustPayToPubKey (Ledger.pubKeyHash pk) value` isn't necessary.
Mitchell Turner
CC BY-SA 4.0
2021-08-12T22:02:55.510Z
Question: From where did you gain your expertise in Plutus? Is there some book you can recommend?
Kwaggy
CC BY-SA 4.0
2021-08-12T22:14:59.977Z
I'm far far far from an expert. Unfortunately there isn't a book yet. I've been through the Plutus Pioneer Program, I've written my own SC (which took me a while), and I try to answer people's questions here. We're all figuring this out together since Plutus is so new. Trying to get as much exposure as possible.
Mitchell Turner
CC BY-SA 4.0
2021-08-13T16:32:38.960Z
There actually is a downside to the `mustPayToPubKey`  approach, in that that the tran is subject to sabotage unless [`geq` is used in the validator](https://github.com/input-output-hk/plutus/blob/d19766f484d5524ff39e6715312338a2a116fb08/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L113), as is explained [here](https://github.com/input-output-hk/plutus/blob/32e6dd65e803afa014f2ef784c1ee9518a09a837/plutus-use-cases/src/Plutus/Contracts/Escrow.hs#L177)
Kwaggy
CC BY-SA 4.0
2021-08-12T16:58:29.637Z
2021-08-12T17:05:11.777Z
2021-08-12T17:05:11.777Z
Mitchell Turner
<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>

<plutus><plutustx>
Constraints.mustPayToPubKey requires txSignedBy?
# Constraints.mustPayToPubKey requires txSignedBy?

(Asked by: username_0 on 2021-08-12)

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?

**Tags:** plutus, plutustx

---

## 1 answers

### Answer by username_1 on 2021-08-12. Score: 2

> 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](https://github.com/input-output-hk/plutus-pioneer-program/blob/b50b196d57dc35559b7526fe17b49dd2ba4790bc/code/week03/src/Week03/Vesting.hs#L51) 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](https://github.com/input-output-hk/plutus-pioneer-program/blob/b50b196d57dc35559b7526fe17b49dd2ba4790bc/code/week03/src/Week03/Vesting.hs#L111).

> **Comments:**
> **username_0**: But what would happen if the tran does not see the pkh? Why can he **not** get paid in that case?  
> **username_1**: I'm not sure what you mean by "tran does not see the pkh." Do you mean if the validator doesn't see the pkh as a signer of the transaction?  
> **username_0**: Yes. Why is that a strict requirement?  
> **username_1**: Isn't that the behavior you want? You only want the winner to be able to spend the lottery winnings? When you spend ADA from your own wallet, the transaction is only valid if the owner of the ADA signed the transaction. This is the same as that, but the winnings are at the script address, rather than your own wallet, so you need write those requirements into the validator.  
> **username_1**: If you didn't have that requirement, anyone could spend the winnings.  
> **username_0**: I guess I don't understand what forces the winner to be hooked up to the transaction in the first place -- is that perhaps one of the purposes of the constraints when submitting the transaction?  
> **username_0**: More questions: So there seems to be two approaches, either focused on the current owner who `mustPayToPubkey` or as you recommended , focused on the winner who `mustSpendScriptOutput `. First why is your approach preferred -- simply because the use-case uses it? Second, is it wrong to use both approaches together? And third, why are both approaches allowed, being that it (apparently) only serves to complicate  the matter?  
> **username_1**: You might be thinking about what smart contracts do slightly wrong. I pointed out in your other question here: https://cardano.stackexchange.com/a/2315/1130. Scripts on chain are completely passive. In the case of a lottery, I'm imagining after a series of events, there is a pot of money that has been won by some pkh. We want that pkh to have access to the money. We have two options: Allow _anyone_ to submit a transaction to send those funds to the winner pkh, OR allow the pkh to spend the money however she chooses. Since only the winner is motivated to submit a tx, I went with that approach.  
> **username_1**: Scripts take of space on the chain and cost gas to execute. Simple is better. Not to mention safer. And, as I mentioned. Only the winner is motivated to submit a tx to claim the funds, there is no need to provide multiple ways to access the money. Both approaches are allowed because there are infinite different smart contracts people might want to write. It's easy to imagine a script that would require you to send funds to some wallet. Maybe a tip to the contract writer or something :P  
> **username_0**: I see, so according to your approach, the winner would be notified externally (e.g., email), and thereby be instructed to open their wallet in order to request request the winnings -- such that if they fail to do so, they forfeit?  
> **username_0**: I also do not understand what you wrote above _Allow anyone to submit a transaction to send those funds to the winner pkh_. This obviously would not just be anyone but rather only one entity: The owner of the lottery who actually has the funds to disburse!  
> **username_1**: I imagine that the funds are on the script, and no-one owns them. That's the point of a decentralized smart contract after all. If there is some central owner of the funds, there would be no need for a smart contract on-chain, you could just have an agreement off-chain.  
> **username_0**: Thanks for clarifying that last point.  Kindly advise regarding your approach that the winner would in fact need to proactively submit tran in order to claim.  
> **username_1**: Yes. Since the script is passive, the winner wouldn't get paid unless they proactively submit a "claim" transaction of some sort. This of course could be automated off-chain, either to notify the winner or possibly have the wallet submit the "claim" transaction automatically.  
> **username_0**: FYI the [SimpleEscrow plutus use-case](https://github.com/input-output-hk/plutus/blob/1f9569aec76e2a4c641a16807d5a157c07db69c9/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L148) uses `mustPayToPubKey`  
> **username_1**: That's a perfect example of a transaction that needs to send outputs to different parties. Notice in the validator https://github.com/input-output-hk/plutus/blob/1f9569aec76e2a4c641a16807d5a157c07db69c9/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L113 it only checks that the payee was paid. The line you linked isn't technically necessary, it's just explicitly saying you want the rest of the money. You could send it anywhere and the validator would still pass, as long as the payee gets their due. You would probably never do that, but it's a good example of how validators stay simple.  
> **username_0**: I do not understand your assertion that `mustPayToPubKey` is superfluous (_isn't technically necessary_).  Where else in the [`redeemEp`](https://github.com/input-output-hk/plutus/blob/1f9569aec76e2a4c641a16807d5a157c07db69c9/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L136) contract do you see instructions for sending money to target, or only allowing target to claim?  
> **username_1**: `redeemEp` is off-chain code for building a transaction. There is nothing preventing me from writing different off-chain code that builds a different transaction as long as it satisfies the same on-chain validator (validate). The validator doesn't mention anything to do with the our public key, only the payee's key. So for a transaction to be valid, the constraint `Constraints.mustPayToPubKey (Ledger.pubKeyHash pk) value` isn't necessary.  
> **username_0**: Question: From where did you gain your expertise in Plutus? Is there some book you can recommend?  
> **username_1**: I'm far far far from an expert. Unfortunately there isn't a book yet. I've been through the Plutus Pioneer Program, I've written my own SC (which took me a while), and I try to answer people's questions here. We're all figuring this out together since Plutus is so new. Trying to get as much exposure as possible.  
> **username_0**: There actually is a downside to the `mustPayToPubKey`  approach, in that that the tran is subject to sabotage unless [`geq` is used in the validator](https://github.com/input-output-hk/plutus/blob/d19766f484d5524ff39e6715312338a2a116fb08/plutus-use-cases/src/Plutus/Contracts/SimpleEscrow.hs#L113), as is explained [here](https://github.com/input-output-hk/plutus/blob/32e6dd65e803afa014f2ef784c1ee9518a09a837/plutus-use-cases/src/Plutus/Contracts/Escrow.hs#L177)  

---

