I think most would agree these are pretty radically large changes. Appreciate your engagement regardless. I want to stop feeling like every interaction with CF is like a Kafka novel but I can’t help but feel a little gaslit.
4 Likes
I wont’t do it, but could be a possible scenario for others
1 Like
Meh, I hope the tongue-in-cheek sarcasm of my previous post was evident through the ROFLing emojis 
Just to clarify, if a successful SPO were to split their pool to avoid over-saturation through CF delegation, that individual would receive a perma-ban hammer from my list of stand up people.
One pool, always👨⚖️
New form: Delegation Application Form
2 Likes
It’s CF’s ADA, CF can decide what to do with them.
3 Likes
Doesn’t say much, though. People who feel that they have something to complain about are always much more incentivised to post.
That is not a change and has been the policy of CF’s delegations for years:
3 Likes
As was their policy to improve decentralisation.
If the Cardano Foundation believes that the current K value is too high such that it justifies some single owner’s to run multiple pools, which are not saturated by their own pledge, then they should come out and say what they think the K parameter should be. It would be better for Cardano Foundation to have a stance on what they think the K parameter should be rather than completely undermining it’s meaning. By undermining it’s meaning they are actively working against community beliefs and values. Read the research paper, it is very clear what is the intended meaning of the K parameter. People who are “invested” in Cardano came here for these reasons.
And before @HeptaSean or others bring up this argument again about how the protocol doesn’t currently enforce the policy that the K parameter embodies, this does not mean that we should simply drop the policy. We do have social consensus mechanisms and we can redesign and build other tools which can help to drive our policy objectives.
Cardano Foundation has an easy way out if they believe the current K value is too restrictive. There is no need to destroy the K parameter’s meaning. They simply state what they think the K parameter should be changed to. If their thinking is that it is OK under the current settings for a single owner to run two pools then they should campaign to reduce K to 250. This operator can then amalgamate his two pools to become a single pool operator and we can all call it a day.
6 Likes
Thank you, I would suggest to update the proposal with these footnotes.
1 Like
… what you believe to be “community beliefs and values”.
Are you sure that “people” came here for a five year old research paper whose predictions (“Finally, we experimentally demonstrate fast convergence to equilibria in dynamic environments […]”) famously did not work out in practice at all?
The “community” really does not seem to have much of a problem with the operators of the six DIGI* pools, the seven BCSH* pools, or the five CRDN* pools to be very prominent voices in exactly that community. Not that I would want them to be called out. It would be quite annoying and I think the k parameter is just broken, anyway. But if the claim is that “the community” (and not just a small faction of it) unequivocally frowns upon multi-pool operations, I would expect to see much more in that regard. Or maybe an outcry when COTI chooses WAV (seven pools plus some under different tickers if I remember correctly) to stake the Djed reserve? Not much to be seen.
But if the people deciding on CF’s delegations want the freedom to not having to exclude applications just because the applicant happens to run two pools, it’s a scandal in Cardania? Oh, please!
But maybe we just should drop it?
Not because it is currently not enforced, but because it is not enforceable in principle. Currently, multi-pool operations – at least the ones we know – can be honest that they are MPOs because few care. If people would care, it would be very easy to disguise that much better. Different tickers, different minimal websites, different domains, different IPs, but still pointing to the same multi-pool infrastructure? Not a problem at all.
Which is why it would be a very bad thing if CF would just randomly delegate to alleged single pools. That could really empower sybil attackers in disguise. Delegating to SPOs with a proven track record of contributions outside of just operating a pool is much better because it cannot be faked that easily.
And artificially making a random selection of the thousands of single pools viable shouldn’t have been the objective of CF (or IOG) delegation, anyway. I strongly believe that we don’t need thousands of pools (a large share of which never produce blocks, anyway), but just a few hundred. It should never have been marketed that everybody should run a pool and could hope for that to become profitable. In the long run, we cannot finance so many with just the transaction fees. And a few hundred are more than enough for sufficient decentralisation in my opinion.
We don’t have social consensus mechanisms. We do not even have communication channels to reliably reach “the community”. Everywhere – this forum, X, Discord, … – only small parts of it can be reached let alone be convinced to follow one particular ideology of what “decentralisation” is supposed to mean.
2 Likes
Good suggestion, done!
We do mate! This forum is an example of a channel we can use. People are looking for guidance from others that understand the technology and it’s limits.
So here we are at a fork in the road:
-
We can totally ditch the concept of parameter K by having CF, as the voice of the community, say that it is OK to totally disregard it. Run as many pools as you like. K has no meaning. There is no limit on the number of pools an individual should run because the protocol cannot fully enforce this currently. It is OK to become a pool mogul and control as much of other people’s Ada as you possibly can. Social consensus is too hard so WE DON’T CARE.
-
Or we can reinforce the concept that the K parameter embodies, which is that it represents a limit on the amount of other people’s Ada that one person should control. The protocol doesn’t currently enforce this well because it is difficult to achieve with software alone. Maybe there are better ways that the software can be modified in the future that can work towards this policy objective. Nevertheless, as a community we still believe in this concept of decentralising the block production and we will still push for it using social consensus. If the K value is currently set too high then let’s adjust it to what the community thinks is right. But let’s not totally throw away the concept: That we think there should be a limit to how much one single pool operator should control of other people’s Ada. Let’s state what that amount is and set the K parameter accordingly.
Take your pick: Which pathway do you want to take?
Those of you that feel strongly about the importance of decentralisation need to speak up because we are gradually watching this concept get chipped away, even by the one entity that is supposed to represent the voice of the community (CF). 
Don’t think that this K parameter has no value just because it is difficult to enforce programmatically. The K parameter is a nice clear figure that people can reference and use to judge the upper limit of a single pool operator’s size and it is already baked into the protocol. It is a parameter that we can vote on and calibrate over time. If we just throw away this concept then what are we left with as a clear metric to measure against? Are we going to invent another separate value that we all keep in our heads but isn’t actually codified into the protocol anywhere? Are we just going to hand the judgement over to CF to adjudicate at their total discretion? Maybe just let CF decide which multi-pool operators are “good” for decentralisation irrespective of size?
11 Likes
I couldn’t agree with this more!
2 Likes
OK, after my last post I had thought I would stay away from this conversation for a while, as it was making me unduly angry and sarcastic.
Now I have changed my mind. Over and over through this post, we see one individual calling out others for using their views as the community’s. This narrative is being used to reinforce the concepts of lack of social consensus and that we are all here crying wolf because we don’t like MPOs.
Not the case.
If we had to apply this reasoning to all successful revolutions, none would have ever happened. It is often the minorities who are dissatisfied with upper echelon decision-making. Does that mean we should ignore all minorities? Or single them out, saying “this is only your opinion”? In the context of Cardano (with its stated principles of inclusion and power to the edges), such an idea is particularly grotesque.
Wrong, again. This is not the opinion of @Terminada alone:
And the above are just quotes from within this post. The pulse of the Community (which we can reach, albeit not in its entirety) has already been felt regarding k (and therefore decentralisation of block production)…in the SPO on-chain poll:
https://adastat.net/polls/96861fe7da8d45ba5db95071ed3889ed1412929f33610636c072a4b5ab550211 796 respondents
And it has already been felt in regards to changes to CF delegation strategy:
x.com 264 respondents
Not to mention the observation that non-operators with very large Twitter followings, also share these views:
Pixelated dog: x.com
Whale: x.com
So yeah, not really just a man’s opinion…
11 Likes
While this may be true the Foundation was funded by the sale of ADA tokens in the ICO. As stewards to the ecosystem they have a responsibility to act in the best interests of the community. From an ethical standpoint at least the Cardano community has certain expectations with regards to the Foundation’s actions and responsibilities even if ADA holders and SPOs for that matter don’t have any direct ownership or control over it. There is the governance model of course which gives ADA holders some degree of say as well. All in all the saying that the CF can do whatever they want with their ADA is somewhat risky given their responsiblities and expectations from the community.
2 Likes
Me too, me too!
Okay, it’s all of you, not just one person, granted. I’d still maintain that it’s not “the community”.
https://twitter.com/conraddit/status/1712853496905535775
Oh, and, in particular, you cited @Quantumplation, although his point is much more nuanced than your fundamental, almost hostile disagreement:
Well, as @adatainment made clear many times in this thread and also edited in the original post:
The results were not that unambiguous:
And I still find @Michael.Liesenfelt’s argumentation in CIP-50 | Pledge Leverage-Based Staking Rewards quite convincing:
In fact so convincing that I would remove k completely and just go with the L (maximum leverage) in that CIP. In particular because it doesn’t set an arbitrary saturation that can be easily circumvented by multi-pools (if need be by disguised multi-pools), but an individual saturation by pledge that is the same if the pledge is distributed over multiple pools or kept in one. “k-effective” and MAV/Nakamoto Coefficient can then still be measured to see how good we do.
Moreover, if “the community” is that fundamentally against MPOs, why are almost 75% of the ADA delegated to multi-pools?
https://cexplorer.io/groups
Do “we” (or you?) have to “educate” them because they are clearly “wrong”?
To me, large parts of the opposition to these (rather small) policy changes are disgruntled SPOs who see even less hope to win the lottery of getting CF delegation to maybe somehow get into the sustainability zone. But letting random small pools “ascend” by luck is not a good use of those delegations. (In fact, drawing them totally randomly with operating a pool as only prerequisite would be a huge risk factor for sybil attacks.)
It should have been clear for everyone doing their research before starting a pool that it is hard to get enough stake delegated to operate it profitably. That even the original research paper that @Terminada loves to cite (and that I do not disagree with in that point) basically says that at least 50% of the pools that we currently have should have long given up and rather delegated to another pool.
Framing support for random small pools as the (only) way to “support decentralisation” and everything else as “against decentralisation” seems rather disingenuous to me.
There are some good reasons to deem a couple of hundred pools/pool operators enough decentralisation: we have to finance them by rewards and the subsidies from inflation/reserve will shrink rather fast, so we can only finance a limited number. And a peer-to-peer network does not scale indefinitely. At some point, there are too many nodes to efficiently propagate blocks and transactions.
So, it does not make sense to just delegate to small pools with a scattergun approach just because they are pools.
3 Likes
No one is suggesting a “scattergun” approach to delegation just because the applicants are small pools.
Before these changes, CF was already requiring applicants to be builders and contributors to apply (with the single pool clausule, now removed). The successful applicants were shortlisted, and from those 45 pools were picked (through a randomizer).
So, this could remain the same. I, and others, are questioning the removal of the single pool clausule from the selection criteria.
I, personally, also question the time extension and the size increase.
Here we are discussing the change in delegation strategy. Right? And what kind of message that sends to the Cardano Community at large. In my opinion not a good one.
Regarding your comment about education: I have gotten the distinct impression that education is one of the core focus areas for CF
So I guess it’s not really up to me, you or any specific individual to educate anyone. Rather, with the guidance of CF, we should be acting as one to further blockchain education.
2 Likes
I feel like I am screaming into the void, but I am going to have another go.
I get that using the staking mechanism as a way of supporting a particular team is a cool idea. Just like ISPOs (initial stake pool offerings), right? It seems like it is not really costing anything since the rewards generated are “free” money. Neat isn’t it. OK, Cool.
Well one of the problems is that this is not really free money, and another problem is that by CF limiting themselves to using this strategy they are conflating two objectives: One is encouraging decentralisation and the other is supporting tool builders. Unfortunately if CF limits themselves this way, then they will fail.
You will notice that I have not argued for a specific value as the limit of what one person should be able to control of other people’s Ada. I think this is something for the community to decide, and we should vote on it. This figure is what is currently embodied by the K parameter. If the K parameter is too high, such that it necessitates operators to run multiple pools in order to be economically sustainable, then let’s reduce it, and they can amalgamate their pools into one.
If we want to support tool builders, and I think we do, then let’s have CF pay them directly for what they do. Different projects will require different funding depending on complexity etc.
Think about this: Imagine if we all really wanted IOG to do some more complex development in the future and this work was going to take years and a lot of developers. Do we really think it is a good idea that we have CF delegate all their stake for several years to IOG pools, as the way to pay them for this work? Seriously, this is just asinine thinking.
5 Likes
I am so curious how will this turn out in the months to come:)
Popcorn level I mean:)
Have a great week Stef!
În lun., 16 oct. 2023 la 18:15, [RABIT] - Stef Montanari via Cardano Forum <notifications@cardano.discoursemail.com> a scris:
1 Like
Me too.
But you are conflating two things here. The topic is only: CF has a large bag of ADA that should be staked somehow. How? Not: What else could the CF do or not do?
So, are you saying the decision to use this delegation – done anyway – as an appreciation of contributions to the community – by the way not restricted to tool building – was wrong all the time? It’s not new.
And how should a non-conflated “encouraging decentralisation” look like?
Should they – in line with the (not really validated) RSS research – delegate to the pools with the highest pledges and lowest costs and margins according to the non-myopic ranking algorithm?
Or should they – contrary to the game theory of the RSS paper – try to help a random lucky few of the hundreds of low-pledged pools ascend? Totally random or with some preconditions – not running on evil AWS, somehow proving to adhere to the best practices, taking a test on Linux and Cardano system administration?
How should they vet if the alleged single pools really are single pools? Require complete KYC and an oath that the applicants do not secretly operate more pools? Does only economic ownership of the pool count or is operating on behalf of others just as bad? Only if the operation is on the same infrastructure – potentially leading to reduced resilience (but not that unambiguous: ten pools running on the same professionally maintained infrastructure might also be more resilient than ten pools running independently, but set up in amateur hour) – or also if it is the same person with admin privileges – still leading to the theoretical possibility of perhaps using that power for some kind of attack? How many single pools are still single if we take the most restrictive decisions here?
If this leads to so much bad blood, maybe the modest proposal is that they should just – again totally in line with the RSS paper’s game theory – fire up some fully pledged private pools and call it a day.
You know very well that a pool does not “control” other peoples’ ADA.
We just saw with minPoolCost how hard it is to get parameter changes through the bureaucracies. And that was for a rather uncontroversial change.
For k, a lot of small SPOs cling to the hopium that raising it to 1000 will somehow work the miracle of making them profitable. So, lowering it honestly to something like 100 or 50 (still more than the k-effective calculated in CIP-50) would probably not have that much support. 
Personally, I don’t care that much. k does not work effectively, anyway. I am still free to not take that arbitrary decision of the powers that be as gospel and delegate to one of the two (if k goes to 1000 maybe more) pools of my favourite wallet app operator, just as the vast majority of community’s ADA decides to go to multi-pools for one reason or the other.
Sure, would be more elegant to have a more realistic k (or none at all) and an RSS that really makes pledge count, but the former depends on bureaucratic and in the Voltaire future demo-/plutocratic decisions – all not exactly known for being the wisest – and the latter on a larger change of the protocol and node implementation – can take ages.
And I still don’t see the problem if the CF uses the same freedom in deciding which contributors to delegate to. They have made very clear that they won’t delegate to the large pool groups (and only a delegation to the top 50% of groups would really lead to more centralisation). Not requiring them to decide on the minute details of what exactly should constitute a “single pool” (see above) and then having to play CSI Stake Pool Operator to ascertain that their applicants fulfil them seems totally sensible to me.
Again: Not the topic here. The delegations are not meant to be the main source of funding. They are just an appreciation and the CF has to decide who to appreciate.
We have Catalyst – and in the future probably other funding schemes from the treasury – for meaningfully funding developments.
And maybe, the CF can additionally do something in that direction. Maybe not. Don’t know Swiss foundation law and the bylaws of CF. In Germany, foundations have to preserve their capital and are only allowed to spend from the profits. Quite possible that the CF doesn’t have that much to spend. But: Different topic.
2 Likes
I picked up some talks regarding minimal technical requirements for pools/ best practises and we want to be open on these requirements here on the forum.
We currently require that pools have the following setup so that they can get delegation:
- At least two relays registered on chain. Separate IP not just different port numbers. You can check this through dbsync or for example https://cardanoscan.io or https://adastat.net has a nice interface for that.
- The relays should be running an up-to-date version of cardano-node. This can be verified with
cardano-cli ping’s query command.
In the future we are thinking about (these are considerations that are not yet implemented) requiring:
- at least one relay runs with p2p enabled. This can also be verified with
cardano-cli ping.
1 Like