In the [3PP doc](https://hackmd.io/@JI2FtqawSzO-olUw-r48DQ/BJ_tSlId3) there were some problems with the way user's data was signed by the exchange. We try to solve these problems by introducing a more complicated signing technique.

_(it's assumed that the above-linked document has been read)_

## Original signing technique

At a particular timestamp the exchange would, for each user, create a record of that user's balance, account ID and timestamp, sign it and send it to them via email.

These are the problems with this technique:
1. **Friend attack:** this was a goal of the 3PP doc but it was not achieved. The idea was to ask the exchange for a PoL sometime in the past, making it impossible to have a friend transfer funds; but the exchange knows exactly which timestamps it is signing for it’s users, so it can preemptively do the friend attack on those timestamps. The risk of this can be reduced by having the signing frequency increased to daily or even hourly; the reasoning behind this is that a friend is less likely to lend funds if the lending has to be done 24 times a day everyday. But there is still the collusion attack where exchanges share funds between one another, and this attack is easy no matter how high the frequency of signature production is, as long as the colluding exchanges sign at different timestamps.
2. **On-demand requests of records:** users may want to request records from the exchange on-demand, but they cannot send these to the 3rd party in hopes that they will aid in the PoL effort because on-demand would imply a timestamp unique to only 1 record so the exchange would know exatcly which user will be verified when the 3rd party gives them that timestamp in a PoL request. Even if an auditor came around and requested on-demand a large set of records they would likely not ask for every user so the exchange could leave out some users from the PoL.
3. **Faking data in records:** if we try to allow auditors to come in and request signed records for multiple users the exchange could create fake data and sign that. The auditors wouldn’t know if the data it contained was correct or not unless they reached out to the users, but this means the user's identities would have to be given to the auditors. The same issue applies to users requesting records in the past: if they don’t remember what their balances should have been at the time then they cannot tell if the data has been tampered with.

## New signing technique

The exchange signs every change that a user makes to their account balance.

This is a more continuous approach compared to the original one, and requires a more invasive change from the exchnage's side because more data will need to be stored in the database. What exactly needs to be stored is up to the exchange but every time a user makes a change to their account a record needs to be created, signed and sent to them via email. The records should look like this:


Balance, account ID and timestamp are there same as in the original technique, but transaction count has been added. The reason for this is to deter exchanges from creating records with fake data, as will be explained below.

### PoL over an interval

Because every record potentially has a different timestamp the 3rd party cannot request a single timestamp PoL from the exchange since the exchange will know exactly which user is going to be verified. The 3rd party must request an interval instead of a particular timestamp.

Since an account may have multiple different balances over a particular interval existing PoL protocols have to be adjusted slightly. If we restrict ourselves to the Maxwell tree example of PoL then we can easily adjust it to fit the interval: every balance for a user in the interval is used to make up their leaf, and we make the tree 'double' by having both the min and max balances of every user bubble up to the top. Using min and max works well with the PoA because the final asset sum should be between the min and max values from the PoL.

Here is an example of how a part of the tree would look:


There are a few drawbacks with this tree:
- it is larger than a regular Maxwell tree
- if the balances are to be hidden via Pederesen commitments then 2x more range proofs would have to be done for an inclusion proof
- more data is leaked than a regular Maxwell tree; even if the balances are hidden behind Pedersen commitments the number of txs is leaked

It is also possible to make the tree only use max, which means it would basically be a regular Maxwell tree but with different leaf nodes. But without a min it is difficult to judge how far off the total asset sum should be allowed to be from the max: is it 0.01%? Or maybe 1%?

### Example

To see why the tx count and hashes are necessary let's look what users balances look like over some period of time. Suppose these are the balance changes for 6 users over some interval:


and suppose the balances in green are those that were shared by users to the 3rd party:


The 3rd party asks the exchange to perform a PoL over an interval:


The 3rd party knows some of the balances, and can check those in the PoL returned by the exchange. The tree would look like this:


Let's see how the exchange could cheat. Suppose the records were not as described above but rather just balance, timestamp & account ID. The exchange could add fake balances of 0 into the tree to lower their min value.


The exchange has added fake balance 1.2 with a value of 0, and has just changed the number of the old 1.2 to 1.3 (value stays the same). No matter how many records the 3rd party had they would not be able to catch this cheat. If we were to add tx count to the records then the exchange would get caught in this instance because the tx count of balance 1.2 changed.

But tx count is not enough because the exchange can still cheat by adding 0-balances onto the end of a user's balance chain, like so:


The exchange can send the real 3.2 to the user when they eventually make another tx. This case will only get caught if the user sends the 3rd party the real 3.2 but will go undetected otherwise, even if the user sends all balances after 3.2.

Ideally we would like a record system that would be able to detect any kink in the chain but that will have to be explored later down the line.