---
# System prepended metadata

title: On using Taiga to build Sudoku with our existing API

---

# On using Taiga to build Sudoku with our existing API
## Personal Taiga notes: 12-01-2023

Notes in a transaction are either input or output notes.

- Whatever I **want** - It's an output note
- Whatever I **have** - It's an existing unspent note commitment. Somehow, we need to decrypt the commitment to construct this note and include it as a spend note in the transaction.


If both Dealer and Player knew about each other and wanted to interact with each other (i.e. not needing Taiga intent-gossip architecture), a transaction would look like:

![](https://i.imgur.com/yPjYfQB.png)

Note that in this case, a transaction has 2 inputs and 2 outputs. The **X** set in the `value` field of the sudoku_vp notes indicates that any value is valid.

The way I see this working is as follows:
- The dealer spends what he has: 100 units of a certain token. This is an already existing note commitment in the note_commitment tree that hasn't been spent yet. He needs to be able to decrypt the commitment. He also creates an output note of what he wants: a sudoku_vp solution.
- On his part, the player spends the sudoku vp and creates an output note of 100 tokens addressed to him.

Questions:
- How does one retrieve/access the contents of a note commitment?
    - When receiving a note, the recipient can decrypt the [encrypted_note](https://github.com/anoma/taiga/blob/10bde2ec33fbfeb3f96fc2a833dee5052747439c/taiga_halo2/src/action.rs#L25). Not implemented yet
- Does the dealer really need to create an output note with the sudoku vp? What does he do with this note? It doesn't look like someone is going to spend it.
- Can we enforce some consistency for the field `value` in those cases where `value` is irrelevant?

---

If both Dealer and Player don't know about each other, i.e. they use the intent gossip network, they will act as follows:

- The Dealer spends their note and submits their intent
![](https://i.imgur.com/jZA8KVS.png)

The `condition_note` field, which is a tuple that resembles a note, will let the solver know the condition by which the counter intent note of value -1 can be appended. In this case, it says: "if there exists a `sudoku_vp` spend note of a certain value X, then address it to me (Dealer) and spend my `token_vp` note".

- The Player "spends" their note and submits their intent
![](https://i.imgur.com/BkwFDqH.png)


The solver has the information he needs to create another partial transaction:
![](https://i.imgur.com/gQvn89m.png)


Now we have all the information to construct a transaction that can be submitted to the chain:
![](https://i.imgur.com/VAiM8Zn.png)


Questions:
- Note that the solver spends two `intent_vp` notes, but he doesn't need to have a condition (see that `condition_note` field is missing whereas in the other intent output notes it is not missing). Is it still considered an `intent_vp` note in this case?
- Since it has different fields (e.g. `condition_note`), is the `intent_note` a special type of note? Does it have a different type in our codebase?
- In the `intent_vp` notes, I didn't know how to fill the `user` field. What was the resolution we came up with for users?