Open ghost opened 2 years ago
Each address in Taiga is used in two places, spending:
For example, suppose Alice builds a transaction that creates Notes that belong to Bob. These new notes contain Bob's address (and the token address). Alice also needs to prove Bob's receiving VP. So Alice must know:
Therefore the desired requirements for the address format are (roughly):
This last property may not be possible to achieve (and is not achieved by the current design). The sender may substitute any receiving VP they want and construct a new address with the existing spending VP, and the new receiving VP. So receiving VPs are essentially useless currently.
Some above descriptions and tasks are done, and some need to be updated. But we might still need the new address format design. The address-relative fields are nullifier_key_commitment, app_data_dynamic, viewing key(note encryption), and other potential data. #132 #123
Addresses now must commit to VPs, so we must distinguish between old-style public key addresses (which we are also keeping, but only have meaning inside of VPs) and new-style VP addresses.
com_vp
as public input and check it againstaddress
field in Notecom_vp
(initially, letcom_vp
be transparent), such as BLAKE2s (overlaps with heliaxdev/pbc#1)address
There is a special case to handle of mutually-self-referential addresses. This does not appear to require any protocol level or address format changes, but rather is a VP implementation task (#2)