<p>I found the answer myself. Turns out it has to do with the use of the wrong <code>PubKeyHash</code> in the endpoints. I followed the lecture where Lars used <code>mockWalletPaymentPubKey $ knownWallet 1</code> to find the <code>PubKey</code>. I used that instead of the hash of this. To get the hash one has to observe the type signature of <code>mockWalletPaymentPubKey $ knownWallet 1 :: PaymentPubKey</code>, I saw in the haddock files that this is just some type wrapper around PubKey, to undo this wrapper simply use its constructor <code>unPaymentPubKey :: PaymentPubKey -&gt; PubKey </code>. Now to hash this <code>PubKey</code> one can use <code>pubKeyHash :: PubKey -&gt; PubKeyHash </code>. So in the end we can easily generate these wallets <code>pubKeyHash's</code> via the following</p>
<pre><code>pubKeyHash $ unPaymentPubKey $ mockWalletPaymentPubKey $ knownWallet 1
a2c20c77887ace1cd986193e4e75babd8993cfd56995cd5cfce609c2

</code></pre>
<p>and</p>
<pre><code>pubKeyHash $ unPaymentPubKey $ mockWalletPaymentPubKey $ knownWallet 2
80a4f45b56b88d1139da23bc4c3c75ec6d32943c087f250b86193ca7
</code></pre>
<p>Hopes this helps anyone. In conclusion there is nothing wrong with the off-chain code, it was just weird that it validated for grabbing if the deadline past which put me on the wrong track. If anyone knows why this happened, please enlighten me :)</p>

CC BY-SA 4.0
2022-02-03T11:27:46.950Z
You can also use `mockWalletPaymentPubKeyHash $ knownWallet 1`, which yields the same result but is shorter
rkstgr
CC BY-SA 4.0
2022-02-03T11:13:21.917Z
2022-02-03T11:13:21.917Z
Fermat
<p>I was solving homework1.hs of week 3 of the third cohort and I think there is something wrong with the off-chain code of the solution given the validator. Namely the following, the off-chain part does not specify the end of the txInfoValidRange for the grab endpoint.</p>
<p>I think the current implementation sets this range to <code>[currentTime, Inf]</code>. For the grab of a beneficiary 2 that can grab after the deadline this poses no problem. This since the txInfoRange is contained in the range <code>[deadline, Inf]</code>. But if beneficiary 1 tries to grab before the endpoint the txInfoRange is not contained in the [0, Deadline] since 0 is in general not contained in txInfoRange. This makes that the current proposed solution of the validator can not construct transactions for beneficiary 1 before the deadline?</p>
<p>This can be solved in two ways,</p>
<ol>
<li>Change the off-chain code to make transactions such that the grab for beneficiary 1 will not fail. How can we set this valid range to before the deadline?</li>
<li>Change the validator (I can not see how one could make this work if we permit the txInfoRange to be indefinite. This because it would also permit beneficiary 1 to collect the vesting funds after the deadline, what we want to avoid.)</li>
</ol>
<p>I had a similar solution to the solution provided by the IOG acadamy <a href="https://github.com/input-output-hk/plutus-pioneer-program/blob/main/code/week03/src/Week03/Solution1.hs" rel="nofollow noreferrer">(1)</a> but both of course use the same off-chain code and thus don't work. For example if do the following
<a href="https://i.sstatic.net/4D14P.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/4D14P.png" alt="enter image description here" /></a></p>
<p>Where wallet 1 is beneficiary 1 that can claim after the deadline of slot 10 (<code>POSIXTime = 1596059101000</code>) and wallet 2 with PaymentPubKey <code>98c77c40ccc536e0d433874dae97d4a0787b10b3bca0dc2e1bdc7be0a544f0ac</code> is beneficiary 2 which can claim the funds before the deadline of slot 10. This emulation in the above screenshot works, wallet 1 can grab the funds. But if we set it up to test if wallet 2 can grab by the following simulation it fails with the following error at slot 6</p>
<pre><code>Add slot 3
Contract instance for W872cb83: (ContractLog (RawJson &quot;made a gift of 50000000 lovelace to 98c77c40ccc536e0d433874dae97d4a0787b10b3bca0dc2e1bdc7be0a544f0ac with deadline POSIXTime {getPOSIXTime = 1596059101000}&quot;))
Add slot 4
Add slot 5
Add slot 6
Contract instance for W7ce812d: (ReceiveEndpointCall (EndpointDescription { getEndpointDescription: &quot;grab&quot; }) (RawJson &quot;{\&quot;contents\&quot;:[{\&quot;getEndpointDescription\&quot;:\&quot;grab\&quot;},{\&quot;unEndpointValue\&quot;:[]}],\&quot;tag\&quot;:\&quot;ExposeEndpointResp\&quot;}&quot;))
Contract instance for W7ce812d: (ContractLog (RawJson &quot;found 0 gift(s) to grab&quot;))
Add slot 7
</code></pre>
<p>Is my assessment of the off-chain code correct? How can we solve this?</p>

CC BY-SA 4.0
2022-02-03T09:47:33.370Z
Someone on the IOG discord channel mentioned that this problem arose due to the PubKeyHashes of the wallets being different in this cabal build. I'll do some testing and logging of the PubKeyHashes to check this out.
Fermat
<plutus><plutus-pioneer-program><plutus-playground>
On the off-chain code of homework 3 cohort 3
# On the off-chain code of homework 3 cohort 3

(Asked by: username_0 on 2022-02-02)

I was solving homework1.hs of week 3 of the third cohort and I think there is something wrong with the off-chain code of the solution given the validator. Namely the following, the off-chain part does not specify the end of the txInfoValidRange for the grab endpoint.
I think the current implementation sets this range to [currentTime, Inf]. For the grab of a beneficiary 2 that can grab after the deadline this poses no problem. This since the txInfoRange is contained in the range [deadline, Inf]. But if beneficiary 1 tries to grab before the endpoint the txInfoRange is not contained in the [0, Deadline] since 0 is in general not contained in txInfoRange. This makes that the current proposed solution of the validator can not construct transactions for beneficiary 1 before the deadline?
This can be solved in two ways,

Change the off-chain code to make transactions such that the grab for beneficiary 1 will not fail. How can we set this valid range to before the deadline?
Change the validator (I can not see how one could make this work if we permit the txInfoRange to be indefinite. This because it would also permit beneficiary 1 to collect the vesting funds after the deadline, what we want to avoid.)

I had a similar solution to the solution provided by the IOG acadamy (1) but both of course use the same off-chain code and thus don't work. For example if do the following

Where wallet 1 is beneficiary 1 that can claim after the deadline of slot 10 (POSIXTime = 1596059101000) and wallet 2 with PaymentPubKey 98c77c40ccc536e0d433874dae97d4a0787b10b3bca0dc2e1bdc7be0a544f0ac is beneficiary 2 which can claim the funds before the deadline of slot 10. This emulation in the above screenshot works, wallet 1 can grab the funds. But if we set it up to test if wallet 2 can grab by the following simulation it fails with the following error at slot 6
Add slot 3
Contract instance for W872cb83: (ContractLog (RawJson "made a gift of 50000000 lovelace to 98c77c40ccc536e0d433874dae97d4a0787b10b3bca0dc2e1bdc7be0a544f0ac with deadline POSIXTime {getPOSIXTime = 1596059101000}"))
Add slot 4
Add slot 5
Add slot 6
Contract instance for W7ce812d: (ReceiveEndpointCall (EndpointDescription { getEndpointDescription: "grab" }) (RawJson "{\"contents\":[{\"getEndpointDescription\":\"grab\"},{\"unEndpointValue\":[]}],\"tag\":\"ExposeEndpointResp\"}"))
Contract instance for W7ce812d: (ContractLog (RawJson "found 0 gift(s) to grab"))
Add slot 7

Is my assessment of the off-chain code correct? How can we solve this?

**Tags:** plutus, plutus-pioneer-program, plutus-playground
> **Comments:**
> **username_0**: Someone on the IOG discord channel mentioned that this problem arose due to the PubKeyHashes of the wallets being different in this cabal build. I'll do some testing and logging of the PubKeyHashes to check this out.  

---

## 1 answers

### Answer by username_0 on 2022-02-03. Score: 1

I found the answer myself. Turns out it has to do with the use of the wrong PubKeyHash in the endpoints. I followed the lecture where Lars used mockWalletPaymentPubKey $ knownWallet 1 to find the PubKey. I used that instead of the hash of this. To get the hash one has to observe the type signature of mockWalletPaymentPubKey $ knownWallet 1 :: PaymentPubKey, I saw in the haddock files that this is just some type wrapper around PubKey, to undo this wrapper simply use its constructor unPaymentPubKey :: PaymentPubKey -> PubKey . Now to hash this PubKey one can use pubKeyHash :: PubKey -> PubKeyHash . So in the end we can easily generate these wallets pubKeyHash's via the following
pubKeyHash $ unPaymentPubKey $ mockWalletPaymentPubKey $ knownWallet 1
a2c20c77887ace1cd986193e4e75babd8993cfd56995cd5cfce609c2


and
pubKeyHash $ unPaymentPubKey $ mockWalletPaymentPubKey $ knownWallet 2
80a4f45b56b88d1139da23bc4c3c75ec6d32943c087f250b86193ca7

Hopes this helps anyone. In conclusion there is nothing wrong with the off-chain code, it was just weird that it validated for grabbing if the deadline past which put me on the wrong track. If anyone knows why this happened, please enlighten me :)

> **Comments:**
> **username_1**: You can also use `mockWalletPaymentPubKeyHash $ knownWallet 1`, which yields the same result but is shorter  

---

