user_balance db

[0xbok]

I have created a new postgres db called user_balance with the schema:

CREATE TABLE user_balance (
    owner NUMERIC(49,0) NOT NULL, -- 20 bytes
    balance NUMERIC(13,0) NOT NULL, -- 5 bytes
    PRIMARY KEY (owner)
);

it's added to a psql file.

Features in this PR:

• A new GraphQL endpoint initiate_send(&self, ctx: &Context<'_>, address: [u8; 20], amount: [u8; 8]). You can query it as:

  query {
  initiateSend(
    address: [78, 171, 15, 165, 90, 108, 113, 192, 194, 59, 208, 230, 124, 6, 104, 43, 76, 231, 138, 127],
    amount: 11
  )
  }

  It returns true/false depending on if the balance stored for user_balance[address] is >= amount.

• Replace Mutex with RwLock.

  This type of lock allows a number of readers or at most one writer at any point in time.

• MerkleTree's postgres backend now also uses RwLock.

[0xbok]

i agree with the change. however, i still think this api is useful. We should be accommodative of low storage client devices. In case they are not willing to store the coin ownership information, this api will let them use arcpay.

[BlakeMScurr]

I think it's actually quite critical for the user's device to store ownership proofs. The main reason is in case of shutdown, the proofs will be needed to retrieve their money. I think we should be quite explicit in making people store their proofs, and ideally even backing them up on cloud providers, rather than relying on us to store them.

Also, I don't think the overhead is that high. Facebook messenger is 99mb (OK, that's obviously quite extreme, but many apps are large) and a coin range is only 80bits (1 million times smaller)! Even with the full merkle proofs they're about 1kb, and people should generally only have a max of 10, since they should be tidied up to minimize claims costs. So we're looking at 10-50kb (being generous), whereas the app itself will be a few megabytes.

[0xbok]

Ok, the argument of low data overhead is convincing. for your first point, i'd say we can still provide the api while agreeing with the critical nature of having ownership proofs.

it's critical in case of a shutdown, but we shouldn't make the app unusable in case the user loses the ownership proofs for any reason. This api is only an added feature, the rest of the system can function the same way as it would without this api.

However, the absence of this api shouldn't be a problem since the data overhead is really low.

[0xbok]

documenting offline discussion: merging it now, and we can come back to it if we have. To complete this API, we'll need a way to retrieve leaves given transfer amount.