# Ticket Receipts

Meeting notes for work on the [Ticket Balance Transparency](https://gitlab.com/tezos/tezos/-/milestones/118#tab-issues) milestone.

## 2022-11-04

- Ticket receipt (originated->originated)
- implicit -> originated
- implicit -> implicit
- originated -> implicit
- Need to be sure that receipt comes together with implicit `M` (early Dec)
- TORU
- SCORU
- Originated -> SCORU (internal transaction)
- SCORU -> Originated
- Lower prioritiy. Can be recovered via transaction payload in receipt + `ticket_balance` RPC
- RPC
- `ticket_balance`: ticket_token -> number
- RPC/CLI is done
- `all_ticket_balances`: originated contract -> tickets
- RPC is in MR
- CLI will come shorty

## 2022-09-08

## 2022-09-01

Atendees: Lin, Joel, Sylvain

Topics:
- Finished design doc: https://hackmd.io/@linoshitani/SyLXJQcJs
- Got postive response from some indexers, one of them being Alexander Eichhorn who initially raised concern about the ticket transparency.
- We will go with the current proposed implementation.
- Implementation in progress. There is some discrepancy between how the ticket table is updated and how the receipt is shown, making it a little awkward to implement (not blocker though)
- Testing:
- Make sure compare:
- The aggregated receipt.
- Ticket scanned from context.
- TORU/SCORU already have implicit account owned tickets. We should get the receipt out before there is usage of TORU/SCORU.
- SCORU planned to be enabled `L`.
- People will need to implement many things before using SCORU, unlikely to have users soon.
- One more reviewer:
- Thomas L
- Medhi
- Raphael?
- Ask Fedor for help if trouble.
- People worked on outbox messages:
- Andrea Cerone
- Nicolas A
- Feature freeze end of Sep? 16?
- Receipt for implicit->originated and implicit->implicit.
- Coordinated with XF
- `implicit->SCORU/TORU` doesn't exist yet.
- Only through smart contract.
- `TORU->implicit` can be implemented without being blocked. (separate MR.)
- Probably TORU won't be used.

A -(ticket)-> B (stores ticket)

## 2022-08-26

Atendees: Lin, Joel

https://hackmd.io/@linoshitani/rk1HcWUJi/edit

* Go with solution 2 and 3 and ask feedback

## 2022-08-25

Atendees: Lin, Joel, Yun-Yan

Topics:
* [Milestone](https://gitlab.com/tezos/tezos/-/milestones/118#tab-issues) is ready to be shared.
* Current proposal.
* We will go with this.
* What you own is storage + parameter.
* Check nesting case.
* Global summary.
* Doesn't match the balance at the top level
* Heuristic.
* Advantage: matches the balance.
* Downside:
* May not match with what is acutally happening.
* Difficult to implement (impossible?).
* Post to #indexers and #scoru-ecosystem
* Reach out to Fedor if we have problem with reaching conclusion.
* Set up meeting if there are things to discuss?
* Indexers are not the only stakeholders.
* Code reviewer
* Joel thinking of checking with Sylvain R.
* Maybe Mehdi
* Set up meeting
* Good to get buyin from him.
* Nicolas
* Thomas Letan is busy
* Implementation:
* Testing is cruicial.
* Write tests that aggregate the ticket updates, check with the actual ticket table state.
* Two internal representations of "ticket diffs". Need to combine them for receipt:
* Ticket diff of contract
* Implemented as `(ex_token, Z.t) Ticket_token_map.t`
* Ticket diff of outgoing operations:
* Implemented as

          type ticket_token_diff = private {
          ticket_token : Ticket_token.ex_token;
          total_amount : Script_int.n Script_int.num;
          destinations : (Alpha_context.Destination.t * Script_int.n  Script_int.num) list;}

* Why do we need separate representation for this?
* Why `Script_int.n Script_int.num` instead of just `Z.t`?

A -> mints one -> B
  -> read one -> C
(mints one, reads one) 

A...-1
B...+1
C...+1

Manager signed operations:
    ...
    Transaction:
      From: alice
      To: A
      Parameter: 0
      ...
      Ticket updates: 
        Ticketer: T
        Content: "blue"
        Content type: string
        Account updates:
            alice... -1

      Internal operations:
        Internal Transaction:
          ...
          From: A
          To: B
          Parameter: (Pair T (Pair "blue" 1))
          Ticket updates: 
             Ticketer: T
             Content: "blue"
             Content type: string
                 A ... -
             Account updates: 
           Ticket received:
               ...
               B ... +1
          ...(no ticket updates for this operation)...
          
          
        Internal Transaction:
          ...
          From: A
          To: C
          Parameter: (Pair T (Pair "blue" 1))
          ...
          Ticket updates: 
            Ticketer: T
            Content: "blue"
            Content type: string
            Account updates:

Manager signed operations:
    ...
    Ticket updates: 
        Ticketer: T
        Content: "blue"
        Content type: string
        Account updates:
           alice ... -1
           A     ... +1    
    Transaction:
      From: alice
      To: A
      Parameter: 0
      ...
      Ticket updates:
        Ticketer: T
        Content: "blue"
        Content type: string
        Account updates:
           alice ... - 1
           A ... -2
           B ... +1
           C ... +1    
      Balance updates:
        alice ... -ꜩ7
        A ... +ꜩ7

      Internal operations:
        Internal Transaction:
          ...
          From: A
          To: B
          Parameter: (Pair T (Pair "blue" 1))
          ...(no ticket updates for this operation)...
          
        Internal Transaction:
          ...
          From: A
          To: C
          Parameter: (Pair T (Pair "blue" 1))
          ...
          Ticket updates: 
            Ticketer: T
            Content: "blue"
            Content type: string
            Account updates:
               C ... -1

Manager signed operations:
    ...  
    Transaction:
      From: alice
      To: A
      Parameter: 0
      ...
      Ticket updates: 
        Ticketer: T
        Content: "blue"
        Content type: string
        Account updates:
           alice ... -1
               A ... +1       
      Ticket updates: 

      Internal operations:
        Internal Transaction:
          ...
          From: A
          To: B
          Parameter: (Pair T (Pair "blue" 1))
          ...(no ticket updates for this operation)...
          
        Internal Transaction:
          ...
          From: A
          To: C
          Parameter: (Pair T (Pair "blue" 1))
          ...
          Ticket updates: 
            Ticketer: T
            Content: "blue"
            Content type: string
            Account updates:
               C ... -1
              

## 2022-08-23

Attendees: Lin, Joel

Topics:
* Priority of tasks
* Had a chat with Fedor.
* Receipts are more important.
* L would be a stretch goal.
* RPC on hold for now.
* Get input from indexers.
* Explain the output. The JSON structure.
* Add JSON for the receipt example.
* Updated milestone
* Accumulate result:
* Accumulate the map and thread them through all operations.
* At the end:
* Merge the maps at the end (or merge them as we thread), or
* Scan the before/after storage and check net difference, or
* Query ticket balance via old context V.S. query ticket balance via new context.
* All the above should result in same net balance.
* Check how the XTZ balance is threaded.
* Jeol to paternity leave. Who can help with reviews?
* Thomas Letan
* Mehdi
* Nicolas Ayache
* Talk with Fedor for more reviews

## 2022-08-19

Attendees: Lin, Joel, YunYan

Discussed
- Clarify balance updates for internal ops
- 3rd RPC probably needs ticket-content and ticketer in the body
- Do we need to block on implicit account
- Without implicit account owners:
- still receipts originated contract calls
- Lookup ticket ownership for originated contracts (KT1)
- Lookup ticket ownwership (3rd RPC) for SCORU addresses and implicit accounts
- Need to make sure that receipts are working or implicit to any contract where payload contains tickets
- Coordination depending on which project completes first

TODO:
- Let's notify indexers and ask for feedback (follow up with more details)
- Describe exact format of RPC endpoints and rectips

Be ware of: Request for notifications on `JOIN` and `SPLIT`

Question: Why ticket-tokens (ticketer + content) rather than tickets?

Atomic transactions:
Example:
Implicit `tz1XYZ` calls `KT1`:
`KT1` calls `KT2`
`KT1` calls `KT1`
`KT1` originates new contract `KT3`

Receipts:
- Have a look at `update_script_storage_and_ticket_balances`
- `Transaction` and `Origination` ops

RPC 1:
- `Ticket_accounting.ticket_balances_of_value`

RPC 2:
- Take the payload and hash the combo of content, ticketer, owner. Lookup from `Ticket_balance` table.