Proof of transcoding vs proof of delivery

I read the whitepaper when it first came out and I had a few questions (apologize if this has been answered in the whitepaper).

Has there ever thought about boiling down the protocol to the equivalent of an ordered BitTorrent using state channels?

This approach changes the problem from a “proof of transcoding” to “proof of delivery”. The assumption here is that a user will drop the stream if the event is not what they were expecting. This is where state channels come in. The channel doesn’t care what is being delivered, it just establishes a connection between peers. Each video player (or plugin to other video players or however you want to package it) is a viewer and a relay. This also opens the opportunity to support any streaming, ordered delivery whether live or not.

Thoughts?

1 Like

As regards to an ordered bittorrent, we’re planning to implement and test RFC 7574 - the Peer to Peer Streaming Peer Protocol - which is a high level design for this sort of ordered p2p delivery.

Where things get interesting, and there are open questions, is whether or not to incentivize the delivery with payments. This can be done using state channels as you mentioned, or checkbook contracts. The argument for this is that you create an equitable and fair structure with incentives to get people to participate in seeding and relaying content. The argument against is that peers are already willing to trade bandwidth in a tit-for-tat way because they’re incentivized to actually view the content, and adding the payment overhead means that consumers couldn’t even participate unless they had the token/payment mechanism.

It seems like the right feature that people want is to be able to pay to increase reliability of their stream. This is incentivized seeding or incentivized relaying, like Joystream. We should try to design incentives that bundle this value prop into the network itself.

Thanks for responding. I will look more in to RFC 7574 with an eye toward blockchain integration, thanks for sharing. I absolutely agree that we should try to design incentives that bundle the value prop into the network, crypto-economics is hard. Yes, I do think users would be willing to pay for increased reliability. I also think users would also pay for convenience and quality. Seems like you may have considered a system like Joystream. Do you think it is a viable solution? Are there incentive issues? Are there technical implementation details that are not solved?