Re: ion DELEGATION discussion

A point worth considering: If the delegated set is fixed over a prolonged period of time, then its not trustless. If the delegate set changes constantly as the result of some random function, then it may be trustless depending on how large the source set is.

Interesting point.

How does it change the issue of trust even if the delegating parties change randomly?

The delegating parties themselves for iteration n still are to be trusted right?

It reduces the exposure of the system to dishonest nodes, as providing that the function output that determines the set selection is random, these dishonest nodes will never know when they will have an opportunity to be dishonest.

This then requires these nodes to be online constantly in the chance that they do get selected in the next round of delegates. If the selection set is sufficiently large, and the function output is random (or close to), then the time between subsequent selection may be quite long, thus acting as a discouragement due to costs.

Furthermore, if the selected set of delegates is short lived, then any disruption caused by selecting a dishonest nodes in the previous set will be minimal, as transactions that failed which are deemed legitimate can simply be re-presented a short time later against a new set of delegates.

You can increase resilience further if you delegate the work to ALL selected delegates instead of just one or a few of them. Then they all perform the same work and you can think about using the output from that as a basis for consensus.

You have to consider Sybils and other things too, but the basic philosophy is as above.

Did I explain clearly? :| Not sure lol

Okay let's talk about the delegating party.

Supposing they are random then it is like a musical chairs type thing. Some times certain parties will play the delegator and some the delegat-ee.

But the delegator needs to be trusted in some form as they need to delegate correct tasks (within the specs of the system). Who decides who the delegator is?

If it is random don't you think that a malicious delegator could exist at some point?

Ok, so to circumvent possible dishonest delegators you simply ensure that to become a delegator involves some honest action, better still if there is some cost involved.

So for example, in eMunie, the delegator is the party that makes the transaction, which is for all intents and purposes an honest action. If the transaction is not for an honest intent, transactions have fees, so there is a cost associated with it.

The future delegate set is determined from recent transactions, and the process of making transactions essentially random. If I have a payment to make, I might make it now, or I might decide to do it later on, or maybe I don't do it all.

As I mentioned in the other thread, you have to consider Sybil and other similar attacks that attempt to reduce the random entropy of delegate selection, but those are for another discussion I think and would distract from the core concepts we're investigating here.