credit spam

[gkgoat1]

if a local program is managing credits, who's stopping it from being hijacked to make up bogus values ("credit printer"s which swap out the program via interception, for instance) and how?

[nmxmxh]

The credit supervisor is implemented in Go.
You can look at credits like CPU time in older computer architectures.
Credit is simply assigned for work done or storage used.

We kind of encourage gamification because attempts to manipulate or take advantage of the system would just mean more computing or storage, it's not been printed, it's just direct feedback for work done.

If you can expand on your concerns more, I love the feedback in the previous discussion, it's currently browser based, but I'd love to look into non-browser execution too.

[gkgoat1]

The credit supervisor is implemented in Go. You can look at credits like CPU time in older computer architectures. Credit is simply assigned for work done or storage used.

We kind of encourage gamification because attempts to manipulate or take advantage of the system would just mean more computing or storage, it's not been printed, it's just direct feedback for work done.

The concern is not that a program does a lot of useless work but that a program finds and updates the credit count in the shared address space--bypassing the nonexistent protections and becoming a dealbreaking problem with p2p.
Browser plugins or interception-based proxies and frameworks could also hijack the kernel, preventing it from loading or modifying the binary loaded to manipulate its behavior. They also could perform the same updates to credit counts, making them worthless in the p2p scenario.

If you can expand on your concerns more, I love the feedback in the previous discussion, it's currently browser based, but I'd love to look into non-browser execution too.