[cryptography] Fwd: The Wandering Music Band

Natanael natanael.l at gmail.com
Thu Dec 10 16:17:52 EST 2015


Den 10 dec 2015 21:02 skrev "realcr" <realcr at gmail.com>:
>
> It has been a while, but I think I know now about an idea to solve this
problem.
> I really appreciate all the help I got from your responses.
>
> I wrote a document that explains it here:
>
>
https://www.newtolife.net/the-trusted-supernode-and-distributed-banking.html
>
> Abstract:
>
> 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.
>
> 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.

Interesting approach.

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?

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?

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.

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?

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.

While still not yet practical, Zero-knowledge proofs would enable signature
set compression.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20151210/8d9a080d/attachment.html>


More information about the cryptography mailing list