<p dir="ltr">Den 10 dec 2015 21:02 skrev "realcr" <<a href="mailto:realcr@gmail.com">realcr@gmail.com</a>>:<br>
><br>
> It has been a while, but I think I know now about an idea to solve this problem.<br>
> I really appreciate all the help I got from your responses.<br>
><br>
> I wrote a document that explains it here:<br>
><br>
> <a href="https://www.newtolife.net/the-trusted-supernode-and-distributed-banking.html">https://www.newtolife.net/the-trusted-supernode-and-distributed-banking.html</a><br>
><br>
> Abstract: <br>
><br>
> The Trusted Supernode is an abstract idea for a distributed secure and efficient banking system. This system allows payment operations that disturb only small amount of participants. It overcomes adversarial attacks by applying a useful proof of work, combined with node mixing.<br>
><br>
> The Trusted Supernode bank system relies at its core on a special form of trusted entity called the supernode. In addition to its ability to manage payments, the supernode should allow to securely exchange computation and storage services for money.</p>
<p dir="ltr">Interesting approach. </p>
<p dir="ltr">So you create a top-level supernode W as a gatekeeper? How do you handle the abnormal incentives to become corrupted for these members? And hacking risk? What about node selection attacks (including RNG manipulation) performed by existing bad members trying to increase the share of bad nodes? Any kind of trust / reputation / behavior based node priority in the node selection? </p>
<p dir="ltr">Then of course having separate T_user's risks synchronization issues too, how do you ensure consistency with 3 or more of these at once, simultaneously sending and receiving multiple requests?</p>
<p dir="ltr">And network disruptions and hacking with zerodays are also not dealt with. Also, it looks like you didn't deal with the risk of good nodes that used to be in the group turning bad after the fact and faking the history, which is really critical over long time periods. And overall, it looks easy to disrupt by messing with the network. </p>
<p dir="ltr">Also what if somebody prevents a supernode from communicating with good nodes (a variant of sybil where you isolate the target, an eclipse attack) during node selection? Forcing the choice of bad nodes? </p>
<p dir="ltr">And your risk calculation is a point-in-time value for one single supernode. What's the aggregate risk over time, given some defection rate and some transition rate? The birthday paradox is relevant, for example. </p>
<p dir="ltr">While still not yet practical, Zero-knowledge proofs would enable signature set compression. </p>
<p dir="ltr">As far as I can see, in stable trusting groups it can work reasonably well even if large, but I doubt it can work in the long term in fully open groups. In the latter case, you can not effectively defend against being overrun by dishonest users. </p>
<p dir="ltr">Where I can see this being applied is for something like say cooperating groups of sensors (maybe environmental sensors) with different owners (different research teams?) in a large mesh network *without any explicit adversaries* (but maybe some greedy users), where you can't guarantee a reliable link to any trusted servers. So they coordinate themselves the best they can with an algorithm like yours. There must be a low incentive for malice. </p>