[Proof of Purchase] Purchase Transactions, non-blockchain

### Problem Statement

There are two practical problems being solved by "proof of purchase":

a) Sync-able history ( user downloads something on one device, want to sync this action to other devices)
b) Payment negotiation before download (user wants to download something, he will get payment information and make the payment, user must than prove that they made the payment to get the data)

The problems are mostly identical, the only difference being that a) is done after the payment and b) is done while the payment is being performed. There are two parties of interest, the downloader, and the download provider. This problem must be solved by the downloader providing a cryptographic proof that he created a transaction (i.e, prove ownership of a payment address) to the download provider. This must be done regardless of whether there is some blockchain solution or not that records payment recipt. Merely recording some receipt like metadata on the blockchain does not solve the above two issues because it does not show who created the payment (it only shows that a payment was created by an address, but there is no procedure for the download provider to know who owns that address and thus have rights to download the data). "Payment protocol" is a more accurate description of this problem, and BIP70 is an example proposal that addresses it. BIP70 does not exactly meet our needs, but it gives a good general structure for how we can solve the problem. Below I will present another alternative that is more suited to the current LBRY network:

### Solution

Currently our solution for payment is extremely primitive, and completely by-passable. We utilize payment addresses recorded on claim metadata, and the downloader is trusted that he made some payment before he gets the data. There is no verification involved so this process is by-passable (as is the process of syncing). This can be improved by the below example process:

a) There is a payment address A on a claim containing metadata for content C (also there could be additional payment addresses for data fees..). This already exists on LBRY network.
b) Downloader contacts download provider, he says "hey I'd like to buy C, I'm paying from this address B and here is proof I own address B". This message is signed with key X controlled by the downloader. Proof of address ownership is needed in order to prevent people from piggybacking off of other people's transaction.
c) Download provider waits for payment from B to A, if he receives it he says "you can download C now, and also whenever you can sign with key X". This message is signed with key Y controlled by the download provider. Download provider records this in his database.
d) Downloader can now sign with key X whenever he wants to download C from download provider. Downloader can record this in his database.

*Note that unique addresses per content is not inherently required in this protocol.

*Downloader can not lie about what content he paid for because he told the download provider what he is paying for, and the download provider made a record of this.

*If downloader loses his records, but retains key X, he can still get download rights through a trusted download provider. In this way, it is possible to reconstruct from seed the downloader's complete download history.

*Downloader can resolve disputes if he retains the message obtained in c) because it is signed by the download provider

*This protocol does not take into account the possibility of there being multiple download providers, but should be extendedable for this without a complete overhaul.

*This protocol likely needs to be done over an encrypted communication channel to prevent spoofing. There is likely a way to make this unspoofable even over unencrypted communication channel, but I have not made any effort to consider this in this issue

This procedure provides a clean way to solve a) and b) without introducing a dependency on the blockchain layer. The only weakness is that if both the downloader and download provider loses their records, the records are gone. But since the download provider will in general be specialized merchants, it should not be a major problem. Also the blockchain should not be used as a back-up database for matters concerning only two parties, and this solution avoids that.

This is a protocol proposal rather than a file-level task; start by reviewing the proposed downloader/provider flow in the issue and compare its structure with BIP70. Done would require an accepted, scoped design for non-blockchain purchase proofs, including the open encrypted-channel and multiple-provider concerns.

Written by the indexing model from the issue text.