Add kernel procedure that calculates note RECIPIENT hash about miden-base HOT 7 OPEN

The initial version of build_note_recipient procedure was implemented in #710. This version assumes that input parameter is a single element.

We should figure out how to modify the procedure so that it supports variable number of note inputs.

from miden-base.

Originally, I was thinking of keeping this issue open - but I agree, probably makes sense to close it. We should, however, create a new issue for making build_note_recipient more generic. @partylikeits1983 or @Dominik1999 - could one of you do that?

from miden-base.

#! Returns the RECIPIENT for a specified SERIAL_NUM, SCRIPT_HASH, and inputs hash
#!
#! Inputs: [SERIAL_NUM, SCRIPT_HASH, INPUT_HASH]
#! Outputs: [RECIPIENT]
#!
proc.build_recipient_hash
  padw hmerge
  # => [SERIAL_NUM_HASH, SCRIPT_HASH, INPUT_HASH]

  swapw hmerge
  # => [MERGE_SCRIPT, INPUT_HASH]

  swapw hmerge
  # [RECIPIENT]
end

Yes - that's exactly how it would look like!

from miden-base.

This is super nice!

The only open question is how we want to use this procedure.

Do we always want to provide [script_hash_word, serial_number_word, input]? It might make more sense to have [SERIAL_NUMBER, SCRIPT_HASH, input]. In that case, you don't need to swapw first.

We can add this here.

We don't need to touch a kernel procedure even.

from miden-base.

This is a very nice addition! And also agree with @Dominik1999 that it should go miden::tx module.

A couple of thoughts about the interface:

• I would probably call this procedure build_note_recipient to indicate that we are building the recipient rather than retrieving it from somewhere.
• I'm wondering if we should make it a bit more generic in how it handles inputs. Specifically, a note can take up to 16 input elements (and in the future potentially more). So, maybe instead of assuming the number of input elements, we should specify it as a parameter as well?

from miden-base.

Originally, I was thinking of keeping this issue open - but I agree, probably makes sense to close it. We should, however, create a new issue for making build_note_recipient more generic. @partylikeits1983 or @Dominik1999 - could one of you do that?

Yes, I agree. I've been working on a procedure that makes the build_note_recipient more generic.

Would something like this work?

#! Returns the RECIPIENT for a specified SERIAL_NUM, SCRIPT_HASH, and input
#!
#! Inputs: [SERIAL_NUM, SCRIPT_HASH, INPUT_HASH]
#! Outputs: [RECIPIENT]
#!
proc.build_recipient_hash
  padw hmerge
  # => [SERIAL_NUM_HASH, SCRIPT_HASH, INPUT_HASH]

  swapw hmerge
  # => [MERGE_SCRIPT, INPUT_HASH]

  swapw hmerge
  # [RECIPIENT]
end

I have a rudimentary test for it here: https://github.com/compolabs/spark-miden-v1/blob/bede38ad425e66f9c91d6152dd378e2a4c020636/tests/mock_integration/swap_recipient_test.rs#L83

This test is a bit messy, would improve it for a PR.

from miden-base.

Opened a PR to add this to the next branch

from miden-base.