search

lbryio / proposals

Discussion of large projects
1 stars 0 forks source link

[Proof of Purchase] Via the Lightning Network #10

Open BrannonKing opened 5 years ago

BrannonKing commented 5 years ago

Assumption: you've read the other Proof of Purchase proposals. Second assumption: you can and have read some introductions to the Lightning Network (LN) online. Disclaimer: I don't think this is necessarily the right approach, but I'm the kind of person that has to see all the options before I can make a decision.

The lightning network transmits an invoice from the seller to the buyer (through some means outside the LN); they buyer then submits the money & confirmation of the invoice back to the seller. The invoice contains a particular field for describing the item (see https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#data-part).

The proposal:

  1. Incorporate the Lightning Network into our solution. Ship its daemon alongside our wallet, seed it with our wallet's seeds.
  2. Use the LN for content payments. Use the LN's description field in the invoice to contain the claimID and any other necessary metadata.
  3. Store the receipts locally on each end.
  4. Create a number of "central hubs" around the world that are well-funded and interconnected (maintained by LBRY). Behind the scenes have each user join one of those hubs.

Pros:

  1. There is good, pre-existing code/libraries that we can utilize for this. Simply pull it off the shelf.
  2. This removes content purchase traffic from the blockchain.
  3. There would be no discussion of waiting for confirmations on content purchases.

Cons:

  1. LN has a well-know weakness of devolving into centralized hubs. It doesn't get better over time. We would be enabling that rather than removing ourselves from the equation.
  2. Restoring the wallet from seed would be insufficient to restore the receipts; they would have to be backed up separately. We would have to be careful to separate receipt data from channel data (as you don't want to back up the latter).
kauffj commented 5 years ago

Suppose we started with an onchain solution like #6 - would there be a graceful evolution to this approach should the onchain approach face scaling challenges?

BrannonKing commented 5 years ago

Once our upstream merge is done, the blockchain support for LN is there. The work for this solution would be integrating a LN library at the wallet-level, and securely backing up the receipts. (There may be overlapping work if we need to back up wallet data anyway via #11 .) One the other hand, #6 is a lot of work that would sit idly by if we ever switched to the LN.

If we modify our codebase to simplify the rollback code, that would help make an implementation of #6 easier. We could use Roy's roll-forward-only approach (but store all historical changes in the DB). That way you only have to parse/handle the messages going forward, which is quite a bit easier.