[Proof of Purchase] Purchase Transactions, non-blockchain

[kaykurokawa]

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.

[BrannonKing]

Checking a couple of assumptions:

1. Content providers need to have an always-on endpoint?
2. Content providers wanting dynamic pricing need an always-on endpoint, and that would have to be queried to display the correct price on a per-user basis?
3. We would still be keeping payments on the blockchain, and therefore limited by the current blockchain scalability issues (which won't affect our usage until we get a lot more traction).
4. We would allow the content download without confirmation time?
5. We're resistant to man-in-the-middle attacks that replace a buyer/seller's address with an attacker's address before a transaction is authorized?
6. Refunds are possible?

[kaykurokawa]

1. Yes. Content or data provider, or what we call reflector. (note that this is different from content creator/publisher)
2. Yes, something like that would be better than putting a fixed fee and address on the claim metatdata
3. Yes. Though this protocol could work on any blockchain, not lbrycrd (i.e. bitcoin)
4. That could be up to the download provider. He can use 0 or however many confirms he wants
5. It would be if over SSL/TLS. I think it might be safe if public key X and Y is known to the download/download provider before hand but I've not performed a thorough analysis here.
6. I suppose since download provider would know whether downloader ever downloaded his purchased content, it should be possible.

[kauffj]

Two main comments:

• Since payments are still on the blockchain, what is the argument for not including the claim id or equivalent in the transaction? I still do not understand the reasoning for not wanting to include this information. Is it a matter of space? Privacy? Something else?

• A solution that requires sellers to run dedicated servers is inferior to a solution that is fully decentralized. We should consider a solution like this only if we've deemed other designs impossible or infeasible.

[kaykurokawa]

Since payments are still on the blockchain, what is the argument for not including the claim id or equivalent in the transaction? I still do not understand the reasoning for not wanting to include this information. Is it a matter of space? Privacy? Something else?

Unnecessary computational burden and unnecessary lack of privacy. Unnecessary because the above solution is sufficient for what we want to implement: a) sync-able history and b) payment negotiation. The "blockchain proposal" https://github.com/lbryio/proposals/issues/6 or similar would still need to implement my proposal or a BIP70 like payment proposal which handles the data negotiation between a user's computer and the data provider's server to achieve a) and b).

A solution that requires sellers to run dedicated servers is inferior to a solution that is fully decentralized. We should consider a solution like this only if we've deemed other designs impossible or infeasible.

This solution does not require sellers to run dedicated servers. Only download providers, which need to run dedicated servers anyways. The download providers can pass his receipts down to the sellers when they need it. This process should be trustless , in the sense that a download provider cannot lie. However, they can refuse to give you the receipt or they may lose the receipt.

[kauffj]

Unnecessary computational burden and unnecessary lack of privacy. Unnecessary because the above solution is sufficient for what we want to implement: a) sync-able history and b) payment negotiation.

There are probably some additional things that should be on this list that we'd agree on, such as the ability for publishers to have clear insights into how their content is selling, and possibly some that we wouldn't, such as having transactions be unambiguous.

I'm trying to emulate your thinking on this manner re: privacy and struggling. Here is where I get stuck:

1. We already live in a world where transactions can be reconciled with purchases in the vast majority of cases, since addresses generally aren't re-used and transactions can be correlated.
2. Therefore, modifying transactions to include claim ids would only affect privacy at the margins.

I could understand the general position that allowing open inspection of transactions to see how content is performing is anti-privacy, but if that were the case, then the real thing to address is (1), not the addition of (2).

This solution does not require sellers to run dedicated servers. Only download providers, which need to run dedicated servers anyways. The download providers can pass his receipts down to the sellers when they need it. This process should be trustless , in the sense that a download provider cannot lie. However, they can refuse to give you the receipt or they may lose the receipt.

Ok, good to know, that certainly makes it better. However, it's introduced more questions.

1. How is the download provider performing a signing on behalf of the publisher that can't be replayed or abused?
2. How is the download provider receiving something that allows him to sign on behalf of the publisher and how is this done trustfully?
3. Or, if I'm still misunderstanding, and the download provider is not signing on behalf of the publisher, how is this signature worth anything?
4. How can we ensure publishers are able to receive insights into their publishes?

[kaykurokawa]

I could understand the general position that allowing open inspection of transactions to see how content is performing is anti-privacy, but if that were the case, then the real thing to address is (1), not the addition of (2).

Yes you are right, this is generally done through private endpoints that generate unique payment addresses per purchase. How this would work is that instead of a payment address in the metadata, there would be a server address that you contact to obtain this unique payment address. This is actually part of BIP70 and would replace step a) in the protocol.

Ok, good to know, that certainly makes it better. However, it's introduced more questions.

1/2/3. The download provider is not signing on behalf of the publisher. The download provider is signing on behalf for himself. You are right that the download provider's signature obtained in step c) has limited use. It's main use would be for dispute resolution as evidence that the download provider has acknowledged the payment negotiation with the downloader (the downloader can for example complain to the publisher, "hey I've completed the negotiation process with the download provider to buy your content but they haven't given me the content". Note that the publisher would still have to perform further investigation on his own to detect abuse as the downloader could be lying).

4 Publishers need to work with reliable download providers. Unreliable download providers who fail to provide receipts and detailed download informations for publishers will presumably be driven out by market forces. Note that some information will still be available to the publisher even if download provider fails to provide receipts, since they have a record of payments going to their payment addresses.

[kauffj]

At this point, I think I have a decent understanding of this proposal and have no further questions.

[BrannonKing]

Suppose we add this "payment oracle" to reflector. He speaks on behalf of the seller. He needs to record transactions that can be viewed later by sellers. Where does he store that data? In the DHT? We could come up with a data structure there that allows buys to view only what they've bought and vice-versa for sellers, but we would need some other mechanism for ensuring the integrity of that data store as it would change much more often than any single piece of content.