Proof of Access - Content Insertion

in #dev2 years ago

Proof of Access

It's day 8 of blog everyday November, things have calmed down from moving and I'm back on my grind

The Hard Part

A little while ago we posted a video of a few of us talking shop and reviewing some code. I mentioned some of the "hard part" was around the resource credit nature of BROCA tokens, and the handshake necessary to put content into the network. So here we are a few months later and a whole lot of thought, research, and prototyping later. It's time to talk through "Content Insertion."

craiyon_164319_file_upload_spy_v_spy.png

Mitigating Abuse

Our Solution to this problem has to mitigate several abuse vectors. Let's list and explain them.

  • Placing illegal content into the network
  • Attributing illegal content to somebody else on the network
  • Attributing false meta data to content to draw more rewards
  • Doublespend

Placing Illegal Content

People are not likely to want to run infrastructure that can directly get them into trouble. The TOR network has this issue with exit nodes, as it appears illegal communications are their responsibility. It's assumed that all TOR exit nodes are operated by state actors now, which lowers the overall security of the system. For this reason attributions about content must be transparent and accurate.

Attributing Illegal Content

Much like above, attack vectors exist where infrastructure operators could intercept uploads and replace those files with bad content. Wrecking trust in the network at every layer.

False Meta Data

Saying a 5MB file is 5GB to recieve a large payout.

Doublespend vectors

A multiparty transaction must be in a defined channel or be cleared at every step. Some solutions would require additional and unwanted user interaction... but this can't come at the expense of safety.

Solutions

We have a complicated multi-party transaction which means several parties have differing incentives. Front-Ends like 3speak will want to pay for content storage up front to enable their users to use their platform free of charge. Users will want to upload videos. Validators will want to verify videos to receive payment. Storage nodes will want to be verified to receive payment as well. Additionally encorders, indexers, and possibly other services like turn servers and p2p-coordination for chat features on live streams will need effective methods of trust.

To this effect I've been building state channels for these transactions. For ease of understanding, this is like buying a bearer bond, it can be transferred, with reciepts attached... and if nobody bears the bond at it's expiration... the sale is canceled and the funds return to your account.

Chain of Custody

It's important to note that contracts have obligations for each involved party. Payment obligations, storage obligations, content obligations, and so on.

Let's go through probably the most complicated type of transaction.

3speak.tv Content Upload

A user, Alice, logs into 3speak. When the user goes to upload a file they can trigger API that causes 3speak to promise a Broca amount for the storage of user generated content. 3speak has a vote bot and will be able to cover a certain amount of broca value even by voting on different content. To this effect a tally can be maintained and a true market condition might allow the average person to upload a 1GB file. So 3speak will initiate a state channel for Alice with a promise to pay for up to 1GB of content for Alice.

SPK network API can show the valid state of this channel with a certain expiration. The nodes in SPK network will debit the appropriate resources from their account and place them into this channel. This channel will include authorized upload nodes. They can also set a few expiration times for this. For example, if json_metadata in a hive post with rewards enabled and a benificary set to 3speak doesn't occur in 24 hours the remainder of the contract can be voided, and the resources returned to 3speak to aid another user to upload their content.

As Alice is uploading her files her computer will checksum the video, and sign the state channel contract with the additional checksum, and file byte size. This will prevent the upload node, Bob, from attributing other files to Alice's contract.

As Bob insert's Alice's video into IPFS, a hash is generated and Bob can sign the state channel contract that includes the IPFS locator hash and the checksum/size as verified. Bob can hold this contract to submit it to receive the 24 hour periods Broca to cover the cost of the file upload bandwidth/processor cycles. In the future, when Alice wants to upload a video the allocation might be a little smaller, or non-existent... as Bob might actually be Alice and trying to game rewards for non-content; Or the state channel may no longer list Bob as a upload provider.

This video may include some headers to have encoder nodes handle the video for online playback. When the file is ready to be distributed these contract and it's various signatures can be included as json_metadata and reconciled in the system. Building the contracts necessary to store files in the network and have them aperiodically checked via previously discussed psuedorandom algorithms.

Finalization

I believe this will cover most attack vectors but of course I welcome discussion about further vectors. How to improve this system or any additional conversations that spring from these topics.

Sort:  

The main reason I have not pursued running a three speak network node more than I have is the risk of getting caught up in illegal content.

Hopefully none of us wants to run that kind of risk. We hope this solution would place that responsibility in the correct place, Much like ISPs aren't going to get sued for content their networks carry as long as they can point a finger.

Congratulations @disregardfiat! Your post has been a top performer on the Hive blockchain and you have been rewarded with the following badge:

Post with the highest payout of the day.

You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Check out the last post from @hivebuzz:

CBRS Hive Infographic Contest - Get your badge and win 1000 HIVE
Our Hive Power Delegations to the October PUM Winners
Feedback from the November 1st Hive Power Up Day - New Turnout Record

It's blog everyday November?! I had no idea but I almost blogged everyday!

No one would want to take such a risk, I hope a perfect solution is given.

Yeah, very dense, might be interesting to run a full podcast on such topics. I'd bet Dan and you had a lot of such conversations already.

If I understand right, it would work something like this:

  1. 3Speak delegates Broca to Alice for 24 hours (the delegation automatically expires if not used)
  2. Alice uploads the video together with checksums/hashes of all the files uploaded
  3. Bob (upload node) sends the video to IPFS (and receives Alice's delegated Broca, if I understand right?)
  4. Validator nodes randomly check to verify that the video is still uploaded

If that sounds about right, I guess one possible attack vector you mentioned would be that Bob creates thousands of alternative accounts that get a delegation, so that he can get paid to keep uploading. Even if the uploaded files are real in the sense of their size and actual storage, there might not be interest in them, so 3Speak (or any delegator) pays for the upload of non-useful content. Essentially, if Bob makes any profit from the delegation, he is incentivized to game the system by continuously uploading any content.