Roku Mining overview:
This is just a rough idea of how roku mining would work. We can then make a more concrete design in a wiki page.
Roku mining appears to be a novel and a useful idea.
One of the bigger issues this type of mining (appears to solve) on the surface is the greedy mining issue. Greedy mining is the 'arms race' where the most powerful mining monopolies control the greatest share of the coinbase reward leaving the scraps for the home users. This is something we've been discussing at biblepay since we started, and we never did find a solution to this (we wrote it off as an inherent impossibility in open source software). An example of greedy mining is if John Doe makes $20 per month from mining activity that costs him $15 a month, he naturally goes out and tries to buy 10 servers to scale up. This gives him an advantage, but why is John more privileged than the poor user that can only afford 1 server? With Roku mining, we eliminate this effect by rewarding the distinct viewing activity. (Security discussed below).
The other issue roku mining solves is the opensource distinct user dilemma (an opensource challenge-response dilemma). This normally affects opensource systems in that any challenge presented to the end user can be circumvented by reverse engineering the opensource source code, thereby making it impossible to enforce distinct users, and valid captchas. Ill give a couple examples. In scenario A, we have John Doe who decides to circumvent the mining algorithm by creating 10 virtual machines, all running the same BBP code - or a person who signs up with 10 distinct email addresses, to link 10 servers to 10 accounts (if rewards were limited by email for example). Since the code is opensource, he need only respond to the captcha with the right 'programmable response' and therefore will receive the full mining reward per account. With ROKU, this attack vector is also eliminated, because the deviceid-captcha response is signed and cannot be scaled (see security details below), and when scaled onto multiple deviceIDs, a challenge response is required per device per duration watched.
I believe this gives us an exciting opportunity to design Roku Mining.
Lets talk about what this would look like for the end user, and how would it affect our popularity:
First a user who owns one roku device. The user adds the biblepay channel, and then signs up for mining by running an associate-roku command (with the blockchain). This command will store the roku-hardware-id and the users signature in the chain, therefore all sanctuaries will know we have a new distinct hwid and valid signature (as a miner). Next, as the user browses playlists and watches Christian content, the device will keep track of how many streaming minutes are received (in a secure verifiable way, discussed in Security), and these will be buffered until the BBP network sends out a "challenge request". The challenge request will go out to all the roku miners, presenting them with a pin dialog and a question. The answer, being encrypted and secure, cannot be hacked using opensource hacking techniques (since it can only be answered by the individual roku device bearing the hwid and sig). This challenge answer (an encrypted 4 digit PIN), will then "allow" the streaming minute content watched up from the last checkpoint to the current checkpoint to "count" towards the mining activity earned for this distinct device. If the pin is not answered or is wrong, the buffer is lost and those mining rewards are lost for that session. I imagine this challenge would be sent out once per day at a deterministic height - therefore giving every roku (sum of) minute(s) rewarded from the last checkpoint height to the new checkpoint height.
Then the sanctuaries will tally the roku hwid report by device id and minutes watched. And then provide a GSC reward for all the linked device IDs.
If a person attempts to set up 5 rokus in their house, they will be able to receive more rewards based on total streaming time, as long as the challenges are each answered. However we reserve the right to make the challenges more frequent on devices originating from the same IP segment (more on this in security). For now, we can leverage the sha-256 hash of the users email address (which is associated with their roku devices) as a way to limit or slow scaling. I believe it is possible to limit scaling, when you read the security section on encrypted code running in the roku. (This is actually exciting because there is a distinct difference between roku code and opensource end user non-encrypted code). Another words, I believe the mining activity can fully break monopolies and the report would show a very clear picture of the device-id-minutes ratio across the board in this system. Its clearly strong enough to handle unique advertisements for large corporations per 15 minutes viewed, therefore I believe it will be strong enough for this use case.
Security:
Verifiable minutes watched:
This can be tracked in Roku in two levels: Protected streamed content, and tamper proof captcha code.
A distinct difference in Roku (as compared to BiblePay c++) is the non-tamperable subroutine for the captcha. If we send out a challenge request, a hacker cannot tamper (or gain access to the answer) because we signed the subroutine when we developed it. If any code is changed or injected, it is not the same code. So captchas can be relied on fully on the roku.
Also, we can track the minutes viewed verifiably (because protected content uses a key server).
Yes, a user can start a playlist and walk away from the screen, but they will only receive watching credits once they enter the captcha which will come up randomly.
