You are not reading what I wrote. I hence stop here the conversation. Cheers
I know it’s hard for non-technically-inclined people to absorb technical stuff. I understand that this is not your area of strength.
Yes, we can end our exchange here. Cheers.
Well, no, it is not. It is clear you do not understand what is written in the specification. Maybe a video would be easier to absorb? Try watching https://www.youtube.com/watch?v=CU1wqF6lQQ0. I know this is complicated stuff to understand, but do not give up!
1 Like
Thanks for chiming in @mmahut. I’ll definitely dig more into this. For now, I consider myself wrong and corrected on that specific assumption.
But this only means that one of my example filters cannot be used.
This still doesn’t totally remove the merit of @nachocm’s idea originally mentioned above, which is what our main discussion with @Psychomb is about.
Can you also comment on that? It would be great to see what the devs think of a feature like that. Psychomb’s position is he doesn’t want to see people providing technical specifications for the pools they’d like to delegate to and the protocol or the wallet will implement them. I say it would be a useful feature.
1 Like
This might be the case for a number of very involved delegators, but it’s not at all a general (let alone realistic) rule. That’s implicitly assumed by Daedalus, when it ranks by profitability, not geographical proximity, for example.
Saturation makes matters worse, so that, even if you know and trust an operator, or you spend time investigating pools background, you have to find another one when it saturates.
I can understand that most of the participants in these forums prefer to handle delegations on their own, as do I. However, I participate in a group where newcomers frequently ask about their first delegation.The usual advice is something along the lines of “look at this list, and choose a small one” that has to be followed by some notions of what is small, when is big too big, the intricacies of block production in small pools, the need to keep an eye out for saturation and fee changes, avoid pools lacking appropriate resources (¿how?)… it’s really awfully complex to be the required minimum. And we’re completely ignoring actual pool performance, which is almost impossible to assess, and it’s paramount to a robust network.
With this in mind, I really think it’d be a great option to have, and I’d love to hear some feedback on its feasibility (probably once smart contracts are out).
Ok I’ve gone through that video of Sebastien on VRFs. At a high level, not that complicated for a mere mortal’s brain like mine to understand. I see the point you’re making is that we can only verify the outputs of these functions but we cannot know the outputs beforehand, or if we don’t have the required keys for verification. So, in relation to our discussion above, no one else knows the blocks scheduled for a pool aside from the pool’s owners.
On the other hand, the design specs require the following:
- That the leader schedule be calculated ahead of the start of the epoch.
- That the nodes “retain that state, to use it for rewards calculation at the of the epoch”.
If the nodes retain this schedule, they can check in the next epoch if the blocks scheduled for specific nodes have actually been minted or not and consequently, the corresponding rewards. This means the protocol can also use this info as filters for programmatic or conditional delegation.
The video you referenced about VRF then, doesn’t seem to be proving me wrong.
But if I am missing something, I’d be glad to be corrected. No need for subtle insults. I just would like an intellectual discussion, not being dismissed by the other person when the counter-arguments run out.
1 Like
I suggest you open a new convo if you want to get more informations regarding that specific topic. Or may be look for similar convos in the forum. I would not be surprised if that point was already discussed.
Cheers
Thanks for the suggestion. But if you take a closer look, I wasn’t asking for more info. 
You don’t know you’re still looking for them. That’s the problem.
See here
“In Ouroboros Praos, deciding whether a certain participant of the protocol is eligible to issue a block is decided via a private test that is executed locally using a special verifiable random function (VRF) on the current time-stamp and a nonce that is determined for a period of time known as an “epoch”.”
Definition of private: belonging to or for the use of one particular person only.
Cheers,
A much better reply! One that I would expect from an ambassador.
You think someone has a mistaken understanding of how something works, you tell them why. You don’t tell them to open another thread and ask for more info. That behavior is a problem also.
As to your quoted excerpt, that alone still doesn’t make my assumption wrong. It only describes how the protocol determines if a pool can issue a block at a certain timestamp.
I’ll just assume for now that the rest of the paper goes on to prove my current understanding wrong, until I get the time to read it.
Still, going back to our main subject, this is only one of my example filters. As I’ve said above, if this filter cannot be used, it doesn’t mean the suggested mechanism will not work. We can just use other available filters. Whatever ones are relevant and usable.
But anyway, I’ll give this a rest now. I rest my case for this particular suggestion.
I asked a few month ago a question about geographical decentralisation which from my point of view is the basis of power (and real) decentralisation.
And It does not seem technically hard to add an ip based parameter (of the relay node at least) in a ranking algorithm.
It would also have the advantage of making the network more resilient to political or governmental attacks which by essence are still defined by geographical borders.
2 Likes
Just replied to the other tread that we are currently shifting from the centralized (development) phase to the decentralised (‘final’) phase. Live Stake Control Over Cardano Network Today - Stats & Visuals
1 Like
Having an IP based parameter could lead to people hiding their pools behind a vpn with the proper IP.
I think we move towards decentralization at the moment, while the endless cloning of pools might actually pose a risk to real decentralization. Like the multiple binance nodes - I’d not want to put Cardano into the hands of Binance 
2 Likes
The ideal solution to avoid groups of interest controlling the Cardano network would be to have a bullet-proof solution to detect them, so we could just add a factor in the reward formula to negatively impact it.
There doesn’t seem to be such a way available right now, since it’s quite an easy task to just create multiple stake pools.
But there are a number of factors that could be used together (with some kind of ponderation) to intelligently determine the probability of a stake pool beeing in a group. Pushing such factor will make the work complicated for group operators. For instance:
- Website: it’s easy to detect stake pools that refers to the same website
- Similiarities in titles/descriptions (for instance: using levenshtein distance to detect similar title/description/ticker)
- IP ranges
- port used
- Pledge amount / fixed fees / variable fees
- language
- IP address from which the stake pool is declared
- etc.
If you’re a group operator, you don’t want to have to manage your multiples pools in different ways, on different hosts, setting different websites, etc. Maybe we should use that to design a solution.
1 Like
to eliminate the incentives of having multiple pools by one entity.
Otherwise you cannot do anything (waste of time as it’s like symptomatic treatment) does not matter how hard you would try it.
It is similar with the elimination drugs as an example (just for simple model for analogy) what the governments are trying to do for almost a century. And now where are we at?
1 Like
Not that I would disagree with that, but thoses are essentially the same as for operating one pool. If you have concrete ideas in mind, i’d love to hear it.
Play with this, what I just created in the last couple of days, and you will see, what is the issue.
Not the a0, not the RSS function, but the reward distribution /w cost and margin.
Originally, cost was not considered, but margin which had some slightly bad impact in rewards, but /w cost it’s accummulated a lot.
Nice work you did there.
It seems indeed that margin has quite a significant impact on reward distribution (PO versus members). But i’m still not seeing how this relates to the current discussion.
AFAIK, Group operators declare multiples stake pools to work around the saturation limit, and it’s hard to prevent. I don’t believe they are really incentivised to do so before reaching this limit, am I wrong?
No it’s not. If you understand the math and those graph, then you can see that the issue is that the pools with pledge before the turning point (when d/dx f(x)=0). This causing that all pools (small or large pledged) are incentivized to split their pledge to smaller pools to maximise their profits. Which is a rational behavior, as we can see with pool groups (more than 1 pool /w the same entity)
In simple words:
If you can earn 33.8x (assuming full saturation) with 2x35K (average pledge of the Cardano network) pledged pools, and only 32x /w a 70K pledged pools, or more realistic ones with the current settings, as 1PCTs with 50K pledge each /w ~50M stakes
- 1x50K pledged pool can earn 50K+ a year, therefore 10 pools 500K ADA (sorry, this is the correct as I left the margin at 3%) in a year.
- 1x500K pledged pool can only earn 103K ADA in a year.
So, what do you think would incentivize the 1PCT only having 1 pool instead of 10?
In the weekend I just sit down and grabbed a pen an paper and went through all of it (and during and after that I created the graph in desmos), it was not easy, but there can be some solution but the Pool operators would not like it as they do not want to loose these extreme profits.
Do not get me wrong I am a pool owner and one of the very first community members.
6 Likes
Is there no way to prove your geographical whereabouts on internet?