ion DELEGATION discussion

[smoothie]

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.

The higher the frequency of delegate election, the worse the service they can provide

True (for various reasons such as ratios relating to propagation, denial-of-service, etc).

- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.

False assumptions galore.

Wait for the white paper. Amazing to me that what I invented seems so obvious in hindsight yet it isn't obvious to you all. Interesting.

All discussion about delegation should stop now. Otherwise I will be forced to delete some posts. We are cluttering this thread with too much detail.

Wait for the white paper then you will all understand.

Continuing discussion here as Anonymint doesn't want to continue the discussion in his own thread.

[1714807844]

1714807844

[1714807844]

1714807844

[1714807844]

1714807844

[smoothie]

It is definitely interesting to have a system that is DELEGATED yet requires no trust.

As part of the definition of the word delegated is to "entrust".

Seems like a poor word choice.

[monsterer]

- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.

Here is my reasoning:

Extreme lower end

100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block.

Extreme upper end

Ever changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.

[Fuserleer]

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.

[traumschiff]

I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".

I don't see the point of the thread.

[smoothie]

- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.

Here is my reasoning:

Extreme lower end

100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block.

Extreme upper end

Ever changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.

Is there any middle ground in your mind?

[monsterer]

- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.

Here is my reasoning:

Extreme lower end

100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block.

Extreme upper end

Ever changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.

Is there any middle ground in your mind?

Personally, I really dislike trust based models in crypto-currencies - trust is for the centralised banking system we've all come to know and hate.

edit: and whenever you combine anonymity with trust, you are asking for trouble IMO

IMO 'Trustless' is a completely revolutionary concept which deserves to be applied to anything and everything possible.

[Fuserleer]

- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.

Here is my reasoning:

Extreme lower end

100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block.

Extreme upper end

Ever changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.

Network latency isn't an issue if you apply some simple ruling to delegate selection.

You are correct that it is impossible for all nodes to know the current set of delegates if they are selected below a certain interval, in real time, due to CAP theorem.

However, if you base the set selection on an offset of time in the past, say 60 seconds, you can be sure that the majority of the network has information on transactions up to 60 seconds ago.  Thus you select the delegates from a set between say T-60 and T-120 (if you want a set duration of 1 minute).

This approach allows you to have per second delegate set generation, as it provides a "sliding window" over time.

[Fuserleer]

I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".

I don't see the point of the thread.

Heh I say that all the time "wait for more documents from me!"

Then I end up getting into a deep technical discussion soon after

[ion.cash]

- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.

Here is my reasoning:

Extreme lower end

100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block.

Extreme upper end

Ever changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.

Is there any middle ground in your mind?

Personally, I really dislike trust based models in crypto-currencies - trust is for the centralised banking system we've all come to know and hate.

edit: and whenever you combine anonymity with trust, you are asking for trouble IMO

IMO 'Trustless' is a completely revolutionary concept which deserves to be applied to anything and everything possible.

You didn't answer his astute question. And your dichotomous assumptions are very myopic. You do not entertain all the possibilities. You are going to receive a very big surprise when you read my entire white paper.

I told everyone that I am not ready to discuss my design at this time. When I am ready, we will in great detail.

I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.

P.S. no personal offense intended. I will appreciate the debate and discussion with you at the appropriate time. I allowed you to push me for more information and discussion than is advisable at this time for my project.

Add: I really appreciate all the interest in this topic. It is an important one.

[smoothie]

I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".

I don't see the point of the thread.

Yeah I have to say that was uncalled for.

Why not just wait until it is ready then announce.

Sounds like he enjoys the attention.

[monsterer]

I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.

You realise you sound like John Connor?

[smoothie]

- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.

Here is my reasoning:

Extreme lower end

100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block.

Extreme upper end

Ever changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.

Is there any middle ground in your mind?

Personally, I really dislike trust based models in crypto-currencies - trust is for the centralised banking system we've all come to know and hate.

edit: and whenever you combine anonymity with trust, you are asking for trouble IMO

IMO 'Trustless' is a completely revolutionary concept which deserves to be applied to anything and everything possible.

You didn't answer his astute question. And your dichotomous assumptions are very myopic. You do not entertain all the possibilities. You are going to receive a very big surprise when you read my entire white paper.

I told everyone that I am not ready to discuss my design at this time. When I am ready, we will in great detail.

I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.

P.S. no personal offense intended. I will appreciate the debate and discussion with you at the appropriate time. I allowed you to push me for more information and discussion than is advisable at this time for my project.

Add: I really appreciate all the interest in this topic. It is an important one.

Please go elsewhere given you already asked people not to discuss delegation and this thread is simply about ion delegation.

Thanks 

[smoothie]

I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.

You realise you sound like John Connor?

Not to be mean, but posting an observation, Anonymint has a god complex.

He really thinks highly of himself.

The word humble does not appear to be in his mindset.

Carrying on discussion about delegation...

[ion.cash]

I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.

You realise you sound like John Connor?

I am not selling anything. There is no coin yet. VNL is a coin that is already on the market. In the opening post of the thread I created, it clearly states that I would not be discussing the consensus design at this time, and that the purpose of making a thread now was to get a vote on the naming and to show some code to prove I am real and to potentially solicit some other developers to help.

I apologize if I am I following what I wrote in my opening post. I should apologize for trying to maintain consistency between what I write and what I do.

You of course are welcome to discuss consensus designs and delegation in your own threads. I just won't be participating further at this time. I will soon when my implementation has reached the point where I can publish the white paper.

Again no personal offense intended. Carry on without me.

Why can't we have mutual respect? Am I a God to ask that I can be consistent? Come on stop acting like 5 year olds. We are more mature than that.

[Fuserleer]

I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.

You realise you sound like John Connor?

Not to be mean, but posting an observation, Anonymint has a god complex.

He really thinks highly of himself.

The word humble does not appear to be in his mindset.

Carrying on discussion about delegation...

He does indeed, I've expressed this to him a couple of times.

I can't deny the fact that he is very smart, and weirdly, I do respect his position on a lot of topics.  

Problem is I've seen many times that those kind of character traits cause the undoing of that individual, even though they have the capacity to do something truly great...

[smooth]

I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".

I don't see the point of the thread.

Mark this down for the history books.

I agree with traumschiff.

Seems like the only purpose is to hype vaporware.

I don't think it is really malicious but more driven by enthusiasm and being a bit impatient to wait until it's actually done (at least in part) before discussing it. The effect is similar though.

[r0ach]

Not to be mean, but posting an observation, Anonymint has a god complex.

He does indeed, I've expressed this to him a couple of times.

I can't deny the fact that he is very smart, and weirdly, I do respect his position on a lot of topics.  

Problem is I've seen many times that those kind of character traits cause the undoing of that individual, even though they have the capacity to do something truly great...

That's the entire point of reading an Anonymint thread, it's going to be exciting, and maybe even a little bit frightening.

[ion.cash]

I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".

I don't see the point of the thread.

Mark this down for the history books.

I agree with traumschiff.

Seems like the only purpose is to hype vaporware.

I don't think it is really malicious but more driven by enthusiasm and being a bit impatient to wait until it's actually done (at least in part) before discussing it. The effect is similar though.

I started a thread where I could update the public on progress of the development, with first order of business being getting a vote on the proposed name and the next step I said I would be uploading some code. Then from there on updates on the progress.

I don't understand what is wrong with making a thread for that purpose to track the early stage development of a coin?

So that the community of people who are interested in the progress can be updated. And so issues in the development stage can be discussed. First step of development interaction with the public is on the choice of a name.

Please enlighten me?

[smooth]

I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".

I don't see the point of the thread.

Mark this down for the history books.

I agree with traumschiff.

Seems like the only purpose is to hype vaporware.

I don't think it is really malicious but more driven by enthusiasm and being a bit impatient to wait until it's actually done (at least in part) before discussing it. The effect is similar though.

I started a thread where I could update the public on progress of the development, with first order of business being getting a vote on the proposed name and the next step I said I would be uploading some code. Then from there on updates on the progress.

I don't understand what is wrong with making a thread for that purpose to track the early stage development of a coin?

Please enlighten me?

Mostly the discussion, I suppose, where you answer questions and FUD but without being able to give any substantive answers (I'm not criticizing your reasons for that).

My suggestion is to lock the thread and bump it when you have substantive updates. Maybe reopen on a more permissive/permanent basis when there is actual substance to discuss (code, white papers, slides, etc.)

But if the idea was just to discuss the name (first order of business as you say), that's certainly reasonable but then the off topic (to the name) posts should be deleted and not replied with non-substantive replies.