CIP-???? | Pledge-Based Saturation Limit Under a Closed System

[jycappucino]

Dear Community,

It is a pleasure to have this chance to contribute to the Cardano ecosystem, and I am glad that this chance is open for everyone even to contributors like I am who is not a developer by profession. I do have a terminal degree in the physical sciences, so I can understand quite a bit of mathematics (this CIP is somewhat mathematics-oriented). I must reveal that I am using a pseudonym as I am still not sure at this point what I am getting into. Here, I proposed a CIP that will hopefully address the steadily increasing stake centralization in the Cardano ecosystem.

[rphair]

Thanks @jycappucino - can you first please move the file in your branch so it's in a subdirectory beginning with CIP, as all the other merged & unmerged CIPs are laid out? Our current standard is to name your proposal as README.md inside a CIP prefixed subdirectory, so the CIP text shows up when you view that subdirectory.

[rphair]

I can't hope to assess the maths on technical merit (though I can say the equations are beautifully typeset). If & when this is accepted as a proposal maybe it can be submitted to the protocol's scientific designers. In the meantime these suggestions are to get this into a standard form so it can be properly considered in the CIP review process.

[rphair]

Responding here to jycappucino@7aefda3 ... it looks like all the issues in my last review are addressed.

@jycappucino maybe you would attend the CIP meeting to introduce your proposal and hopefully have a few minutes to talk about it with other CIP editors who've been working at a finer level with the Cardano protocol: https://www.crowdcast.io/cips-biweekly

[jycappucino]

Responding here to jycappucino@7aefda3 ... it looks like all the issues in my last review are addressed.

@jycappucino maybe you would attend the CIP meeting to introduce your proposal and hopefully have a few minutes to talk about it with other CIP editors who've been working at a finer level with the Cardano protocol: https://www.crowdcast.io/cips-biweekly

Hi @rphair,

I will attempt to present my proposal if not at the next meeting, hopefully on the next one. It will give me some time to think about how to present it very clearly (I may need plenty of illustrations for this). It will also give the devs on here a chance to comment and provide suggestions that may further improve this CIP and make it more mature before the presentation. Thanks a lot for your review on this CIP!

[rphair]

In today's meeting (https://www.crowdcast.io/e/cip-editors-meeting-41 - minutes normally released in a few days here: https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings) we reconfirmed the consensus that the CIP editing team itself doesn't have the expertise to judge submissions on mathematical or scientific merit.

I also confirmed that in these cases it's welcome for the CIP author to attend the meeting and help us editors understand the idea in general enough terms that we can confirm the CIP is well documented: generally our role ends there. So in case where expert opinion is not readily available, a CIP could be merged before any pending scientific review rather than after. 😎

[jycappucino]

In today's meeting (https://www.crowdcast.io/e/cip-editors-meeting-41 - minutes normally released in a few days here: https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings) we reconfirmed the consensus that the CIP editing team itself doesn't have the expertise to judge submissions on mathematical or scientific merit.

I also mentioned that in these cases it's helpful for the CIP author to attend the meeting and help us editors understand the idea in general enough terms that we can confirm the CIP is well documented: generally our role ends there. So in case where expert opinion is not readily available, a CIP could be merged before any pending scientific review rather than after. Therefore I think it would still be a good idea to attend the meeting once you feel you're ready 😎

Hi @rphair,

Thanks for the update! I have been diverted from preparing for the presentation of this CIP to studying Haskell instead (and maybe Plutus later on). So, I've been slacking, but I do plan on presenting this CIP in a not-so-distant future. 😎

[hodlonaut]

SundaeSwap ISPO didn't involve 198 saturated pools, it was more like 98 near-saturated. It's not quite true that there is no barrier to entry to set up a pool - you need to pay 500 Ada registration fee, and there are obvious infrastructure costs (especially if you are following recommendations, 3 servers - 1 block producer, 2 relays).

[jycappucino]

SundaeSwap ISPO didn't involve 198 saturated pools, it was more like 98 near-saturated. It's not quite true that there is no barrier to entry to set up a pool - you need to pay 500 Ada registration fee, and there are obvious infrastructure costs (especially if you are following recommendations, 3 servers - 1 block producer, 2 relays).

Hi @hodlonaut,

I stand corrected with what I said about Sundaeswap. I should have been more diligent before doing a sweeping claim - I had edited the details about Sundaeswap. I do, however, would like to argue that saturating a significant number of pools appears to be achievable with very lucrative ISPOs. With 68M saturation limit, it only takes about 177 pools to claim 51% of the current 23B ADA staked.

With regards to the barrier to entry - it was in reference to my own CIP and not necessarily with the current protocol, i.e., that under this CIP, all one needs to decide is if to pledge or not to pledge. Of course, the infrastructure cost is a given - can't run a pool without an infrastructure.

[KtorZ]

Here's a quick (AI-generated) summary of the forum's conversation:

---

The conversation is about a proposed solution to stake centralization, which would penalize over-pledged pools in order to encourage a more even distribution of stakes. @7.4d4 raises concerns that this could incentivize pool operators to split their pools into multiple smaller pools in order to avoid the penalties, which would ultimately be ineffective and costly. @jcamp responds that the proposal would not make it cheaper for operators to run multiple pools, as the increased number of pools would lower the optimal pledge and saturation limit.

---

[KtorZ]

This is a nice idea, and something we could ask more often of relatively technical CIPs.

[rphair]

dear @jycappucino thanks for your recent rounds of work on this. This is not a detailed review & I just wanted to get these preliminaries out of the way, to help with the editing discussion & workflow:

1. Your use of the term "close system" is consistent in the title & document, although what you describe is only ever called a closed system in English. If you can find a common counterexample please let me know & I will stand corrected. Otherwise, could you please change it to "closed system" in the titles & everywhere in the text?

2. The term "Ouroboros Julius" implies a relationship of invention that doesn't exist, so it's likely to be misleading. Your work here is significant and well-documented enough that it doesn't require a "brand" like the marketing terms chosen by IOG. To avoid distraction & false implication to the reader, this term should be dropped from the PR title and the title in the document header.

3. It will help us navigate to your document if you could rename the extremely long directory (too long even to appear anywhere in GitHub content without truncation) in your branch from

Ouroboros Julius: Using Pledge as a Bidding Parameter to Determine Saturation Limit Under a Close System

... to something concise, e.g. (it's safe to use the number 45 which has long been in our Proposals Under Review table):

CIP-0045
CIP-0045?
CIP-PledgeBiddingParameter

In any case while you're looking at that table please also see if you can shorten the CIP title to roughly the same length as the other titles: enough to preserve the unique meaning without being disruptively long or unnecessarily specific. 🙏

[jycappucino]

Hi @rphair,
Yeah, your suggestions make a lot of sense! And I changed the document accordingly. Thanks!

[jycappucino]

Hey @KtorZ and @rphair,

I would like to seek your expert opinion if it's alright...

One weakness I found in the current protocol implementation is that one hardware can actually accommodate as many pools as possible. I've read a comment from a pool operator in the Cardano forum that he added 20 more pools on top of the first pool he created in just one hardware at 0 USD additional cost.

I was not aware of that fact stated above when I formulated this CIP, so this CIP assumed that 1 hardware = 1 pool - which is not true as stated above. To impose the 1 hardware = 1 pool, a potential solution would be to take advantage of the hardware's MAC address(es):

1. A software installed in the pool's hardware designed to collect the PHYSICAL MAC addresses of the hardware (virtual MAC addresses are invalid) may be used.
2. the software generates a single hash for the collected addresses.
3. the hash is then used to authenticate pool identity (maybe as part of KES key/VRF key/metadata/certificate for example). Therefore, one hardware = one hash = one pool.
4. if the operator adds another network interface card to his hardware (hence a new additional MAC address if I am not mistaken), this addition will change the hash of the hardware and therefore will invalidate the pool because this is tantamount to tampering.

Something along that line, but I am not sure if this idea is technically sound as I'm really not an IT nor a developer. Just a low-key contributor. Eager to hear what you think.

Thanks! 🙏

[rphair]

thanks @jycappucino but I don't have any expert opinions on this subject. My opinion as a CIP editor is limited to how well the ideas in any CIP are considered logical, useful, and clearly written enough to be valuable to the community.

In this case the question of running multiple block producing nodes on a single host is outside the scope of this proposal, which addresses the same problem by the very different means of incentives and penalties for the stake delegation game itself.

If you wanted to submit a different CIP over your last comment, I would have to respond that I've seen MAC addresses faked many ways (e.g. at the kernel level, which the Cardano node would be oblivious to) over a long career of implementing and defeating software anti-piracy measures.

And then you would have to justify the hell to pay in trying to integrate hardware validity checks in the Cardano protocol, which would create as many problems for most others' routine cases as it would for your pathological case of pool replication on a single host.

Since this CIP is on the agenda for the upcoming CIP Editors Meeting (# 51, Tuesday 16 August, Discord channel and invite) it will help not to introduce any ideas off the topic of your presented CIP... although the subject of your last comment might be well suited to your forum thread which could help you decide where to go with that idea.

[jycappucino]

If you wanted to submit a different CIP over your last comment, I would have to respond that I've seen MAC addresses faked many ways (e.g. at the kernel level, which the Cardano node would be oblivious to) over a long career of implementing and defeating software anti-piracy measures.

Hi @rphair,

Thank you for your kind response.

My idea is that Cardano need not be concerned about the hardware's set of MAC addresses whether these addresses are fake or authentic. The hardware just has to have the same set of MAC addresses throughout the pools' operation. Otherwise, if one of the addresses is changed or if another address is removed/added (fake or not), the hash (proposed above) for the hardware's set of addresses will change. This will then invalidate the pool because this is tantamount to tampering. The software that I proposed above is installed in the pool's hardware. This software collects all the hardware's MAC addresses and generates a single hash for these addresses.

Given that, at the current implementation, a block-producing hardware can accommodate multiple pools suggests to me that this may be the Achilles' heel to decentralization, i.e., this may be the aspect that has the highest chance of being abused. Imagine 60 pools in one/two/three hardwares vs 60 pools in 60 hardwares - huge difference. My impression is that it is hard to achieve the equality line of the Lorenz curve, mainly because of this weakness.

Just an impression. Maybe a stupid one.

Thanks for your input, @rphair.

[CyberCyclone]

The hardware just has to have the same set of MAC addresses throughout the pools' operation

Just putting it out there that this will block a lot of pool redundancy measures. E.g, my pool has "live migration", in that if the OS detects there's a hardware issue, it moves the software to a new server which would have a different MAC address. Also restoring from a snapshot backup to a new server would also give it a new MAC address. So locking a pool to a MAC address would stop dev-ops from moving across hardware.

[jycappucino]

The hardware just has to have the same set of MAC addresses throughout the pools' operation

Just putting it out there that this will block a lot of pool redundancy measures. E.g, my pool has "live migration", in that if the OS detects there's a hardware issue, it moves the software to a new server which would have a different MAC address. Also restoring from a snapshot backup to a new server would also give it a new MAC address. So locking a pool to a MAC address would stop dev-ops from moving across hardware.

@CyberCyclone, thanks for your input. What about MAC/IP tandem? That there should only be 1 MAC is to 1 IP association. If MAC changes, the network takes the valid IP and records the new MAC associated with the IP. If IP changes, the network takes the MAC and records the new IP. MAC associated with multiple IPs should be invalidated to make it hard to proliferate pools.

Or something along that line...

[CyberCyclone]

What about MAC/IP tandem? That there should only be 1 MAC is to 1 IP association.

There's no way to protect against faking this. E.g, any virtualised OS (which is near 100% all cloud servers) gives their own MAC address. E.g, for my testnet pool, I have them running on 1 machine to reduce energy and hardware costs. The virtualisation gives each container its own MAC and IP address. So even if it was required to record the MAC and IP to each other, it's not going to stop anyone.

There's also legitimate reason to have the MAC and IP address change. E.g, if a user is using Kubernetes to manage their BP and relays, then getting a new MAC and IP is guaranteed to happen when the pod moves.

[jycappucino]

There's no way to protect against faking this. E.g, any virtualised OS (which is near 100% all cloud servers) gives their own MAC address. E.g, for my testnet pool, I have them running on 1 machine to reduce energy and hardware costs. The virtualisation gives each container its own MAC and IP address. So even if it was required to record the MAC and IP to each other, it's not going to stop anyone.

I see, but yeah, although it does not completely solve the problem, 1MAC = 1IP is more limited than 1MAC = multiple IPs.
Additional VMs on a hardware will take up space, limiting the number of VMs; additional virtualized OS on a cloud will incur additional costs. Then there is the idea of increasing the hardware requirement to further limit VM proliferation.

There's also legitimate reason to have the MAC and IP address change. E.g, if a user is using Kubernetes to manage their BP and relays, then getting a new MAC and IP is guaranteed to happen when the pod moves.

Perhaps avoid such a system?
Since the current implementation requires a public IP, what happens when this IP is changed? Whatever is required to prevent/accommodate such a change can probably be implemented in 1MAC=1IP.

In my opinion 1MAC = multiple IPs is a Sybil behavior, and with zero additional cost/penalty at that. This is an elephant in the room - the weakest link - that is not adequately addressed and is very prone to abuse. Without addressing it, any protocol proposed to address decentralization will always carry this weakest link. POW does not have this problem because a miner competes for a block. In POS, pools are assigned blocks that's why multiple pools can share the same resources. Hence, a single actor (1 MAC) can have many identities (many IPs) - that's a Sybil behavior.

[jycappucino]

Just a note on the 1 MAC = 1 IP idea:

A PC with

• 64 cores (highest count to date)
• 256 GB RAM (8 slots, 32 GB per slot)
• 100% CPU core allocation
• 100% memory allocation

can accommodate 20 of 12 GB VMs only (calculated using this website). Therefore, under this CIP, the 1108 adversarial pools that are needed to attack the current state of the network will need 554 of this high-end PC. Further, 1108 VMs on a cloud is computationally expensive.

[KtorZ]

This should be Standards Track as it affects the core protocol.

[KtorZ]

Some extra breathing for this section would be nice:

Suggested change

	With the current saturation limit set at 68 M per pool and with 3119 pools (epoch 321), the current staking mechanism can accommodate a total stake of 212.1 B ADA (68M*3119). This amount of ADA is 543% in excess of the current circulating supply of 33B. Because of this substantial saturation limit, one can set up a few pools and offer lucrative rewards to capture a sizeable amount of stake (_e.g._, Binance APY is 17.7%). This leads to centralization and weakening of the ecosystem against Sybil attack. Staying true to the nature of **Ouroboros**, we describe a mechanism that uses pledge as a stake-bidding parameter under a **closed system**, _i.e._, the ecosystem total saturation limit is always equal to the total ADA in circulation. The proposed mechanism ensures that no single entity can get away with excessive stake without putting up a hefty pledge and expending for computing and related infrastructure. This expense, likewise, confers the ecosystem a very high resistance against Sybil attack. For epoch 321, the cost to conduct a Sybil attack under this CIP is millions in pledge and at least 1108 adversarial pools. We dare say that the cost to conduct a Sybil attack under the current protocol is 0 pledge in ADA and at least 177 adversarial pools **only**. This number of adversarial pools needed to attack the ecosystem under the current protocol does not change even if the total number of pools increases, unless the saturation limit (68 M) is decreased. These pools can be readily saturated using lucrative ISPOs and had been demonstrated during the Sundaeswap ISPO which involved 98 pools that were at or near saturation. We, therefore, posit that this CIP is not only fair to all but also enhances decentralization and better security than the current protocol.
	With the current saturation limit set at 68 M per pool and with 3119 pools (epoch 321), the current staking mechanism can accommodate a total stake of 212.1 B ADA (68M*3119). This amount of ADA is 543% in excess of the current circulating supply of 33B.
	Because of this substantial saturation limit, one can set up a few pools and offer lucrative rewards to capture a sizeable amount of stake (_e.g._, Binance APY is 17.7%). This leads to centralization and weakening of the ecosystem against Sybil attack. Staying true to the nature of **Ouroboros**, we describe a mechanism that uses pledge as a stake-bidding parameter under a **closed system**, _i.e._, the ecosystem total saturation limit is always equal to the total ADA in circulation. The proposed mechanism ensures that no single entity can get away with excessive stake without putting up a hefty pledge and expending for computing and related infrastructure. This expense, likewise, confers the ecosystem a very high resistance against Sybil attack.
	For epoch 321, the cost to conduct a Sybil attack under this CIP is millions in pledge and at least 1108 adversarial pools. We dare say that the cost to conduct a Sybil attack under the current protocol is 0 pledge in ADA and at least 177 adversarial pools **only**. This number of adversarial pools needed to attack the ecosystem under the current protocol does not change even if the total number of pools increases, unless the saturation limit (68 M) is decreased. These pools can be readily saturated using lucrative ISPOs and had been demonstrated during the Sundaeswap ISPO which involved 98 pools that were at or near saturation.
	We, therefore, posit that this CIP is not only fair to all but also enhances decentralization and better security than the current protocol.

[KtorZ]

Small-note: while I can fathom the enthusiasm towards Ouroboros / decentralization, I also feel like this belongs more to the realms of opinions than the realms for design specifications. I'd suggest to stick to the facts / maths and remove more opinionated statements like "TRULY OUROBOROS" here above.

[KtorZ]

Supporting equations or annexes should be hosted alongside the repository. Github allows you to embed image directly or even, since recently, use Github native support for mathematical equation (through MathJax):

---

$$ p_{opt} = \phi \times e ^ { 1 - n (1 + erf (- \frac{100}{k}) } $$

Equation 1.

---

Source:

$$
p_{opt} = \phi \times e ^ { 1 - n (1 + erf (- \frac{100}{k}) }
$$

<p align="center"><code>Equation 1.</code></p>

[KtorZ]

Adopt a vertically-aligned list to ease reading of binding parameters (+ bonus, inline LaTeX notation):

Suggested change

	where **_p<sub>opt</sub>_** is the optimal pledge, **φ** is the amount of ADA in circulation (currently 33B), **_k_** is the total number of pools, and **_n_** is a variable that is determined via consensus to warrant an economically viable optimal pledge (**_p<sub>opt</sub>_**). Therefore, it appears that **_n_** is a variable that the community can vote for adjustment to increase or decrease **_p<sub>opt</sub>_**. In effect, it can be used to control the total number of pools (**_k_**) so that at some value **_n_**, the ecosystem gradually settles to some value **_k_** which the community thinks is the optimal value. It is very important that **_k_** is tightly controlled by **_n_**, and **_k_** should only increase according to some parameters, for example, with increasing user demand. So that even if **_k_** is large, all pools are still minting blocks because of high user demand.
	where:
	- $p_{opt}$ is the optimal pledge;
	- $\phi$ is the amount of ADA in circulation (currently `33B`);
	- $k$ is the total number of pools, and;
	- $n$ is a variable that is determined via consensus to warrant an economically viable optimal pledge ($p_{opt}$).
	Therefore, it appears that $n$ is a variable that the community can vote for adjustment to increase or decrease **p_{opt}**. In effect, it can be used to control the total number of pools ($k$) so that at some value $n$, the ecosystem gradually settles to some value $k$ which the community thinks is the optimal value. It is very important that $k$ is tightly controlled by $n$, and $k$ should only increase according to some parameters, for example, with increasing user demand. So that even if $k$ is large, all pools are still minting blocks because of high user demand.

[KtorZ]

Also, this paragraph mentions that:

It is very important that $k$ is tightly controlled by $n$

Why? Can we link to a portion of the Rationale section addressing this claim?

[KtorZ]

I think those results could be better presented in a table:

$k$	$p_{opt}$
500	774 763
3119*	47 205
$+\infty$	27 440

(*) Current number of pools as per epoch 321.

Alternatively, could show a plot of equation for variable $k$ and various values of $n$.

[KtorZ]

Like for equation 1, it would be nice to see some plots of this equation for a variable $p_a$ and fixed set of parameters.

[KtorZ]

These sections feels more like Observations than Conclusions. Perhaps rename them as such?

[KtorZ]

I was hoping to find a justification to a concern I've got since I read the abstract but didn't: it seems to me that the proposal does not actual make it particularly more difficult for adversarial to conduct a Sybil attack? Indeed, while the proposals tends to increase the number of pools, by defining an optimal pledge and making the saturation more dynamic, it doesn't prevent a pool operator from running many pools. Actually, it seems that the proposal even incentivizes pool owner with large pledge to split their pledge into many pools. This has been a recurring discussion on CIP-0050? which is tricky to address. All-in-all, I fail to see how forcing the system into many more pools necessarily help decentralization, without ensuring that those pools are owned by distinct owners.
In the current scheme, owners are incentivized to keep high pledges in their pools because it generates slightly better rewards and thus, hopefully attract more delegators. I'd be curious to see numbers of the total pledge in the current state of affairs for conducting a Sybil Attack (So, take the first ~21-23 biggest pools and sum-up their pledge). How would that compare to this proposal?

[jycappucino]

Indeed!

As you may have read in my recent comments, I formulated the proposal under the assumption that 1 hardware = 1 pool which I recently found to be not true. This CIP will only prosper when 1 hardware can be limited to just a very few pools - this CIP will not prosper in the current state of affairs.

Further, I noted in my recent comments that the weakest link in the ecosystem appears to be the fact that 1 hardware can proliferate an unlimited number of pools using different IP addresses and without incurring any additional cost. This appears to be the weakest link in the ecosystem, and any attempt to improve decentralization will always carry this weakest link, as you have noted that it is also true for CIP-50.

It may be necessary to address this weakest link first before we attempt to improve decentralization. I will propose that instead of using a public IP address, there may be a need to require to have their IP address associated with only 1 MAC address. Although this will still allow an operator to generate multiple pools via the use of virtual machines, this will severely limit their capability. Here are some calculations I made for 1 MAC = 1 IP:

A PC with

• 64 cores (highest count to date)
• 256 GB RAM (8 slots, 32 GB per slot)
• 100% CPU core allocation
• 100% memory allocation

can accommodate 20 of 12 GB VMs only (calculated using this website). Therefore, under this CIP, the 1108 adversarial pools that are needed to attack the current state of the network will need 56 of this high-end PC. Further, 1108 VMs on a cloud is computationally expensive.

Increasing the requirement from 12 GB RAM to 24, 32, 64, and even 128 GB will further diminish their capability. Further, additional RAM requirements will not necessarily generate significant energy use.

[jycappucino]

Okay. I may have found the answer to your concern (subject to investigation).

1. remove the penalty factor.
2. each pool with excess pledge will have k >1. Say a pool with 3x pledge will be counted as 3 in the counting of k. To keep the premise of a closed system, the optimal saturation limit is still φ/k.
3. Excess pledge will be incentivized with more "luck" for example(?) This way operators will be encouraged to keep their pledges in one pool rather than splitting them.
4. Rewards for delegators will still be fixed at 4.5%, subject to pool performance so they need not flock to a near-saturated pool. If they are delegated to a pool that is nonpeformant, their reward will decline.

[KtorZ]

While related to the current proposal, it seems that this section is a proposal-in-a-proposal. I would strongly suggest to split it from the current CIP in order to separate the discussion and decisions in two streams. Ideally, CIPs should be focused on one idea so that we can keep the discussion relatively efficient.

[jycappucino]

Hi @KtorZ and @rphair,

So, I've been thinking about revising the proposal, but I do not think that I can separate a) delegation re-structuring to b) reward restructuring. The modified proposal would be:

1. delegation structuring: keep optimal saturation limit as circulating supply equally divided by the number of pools (φ/k)" so that small pools can be guaranteed some delegation in order to survive.
2. reward structuring: decouple the delegator reward from the operator reward.

• the delegator reward is fixed at 4.5% subject to pool performance. If pool performance is 100%, the delegators will get their 4.5%. In a way, delegation is now a vote of confidence rather than a wealth-seeking enterprise. In the first place, the wealth-seeking behavior is what makes the ecosystem centralized.
• the operator reward will have a separate equation that's dependent on saturation level, pledge, and performance but that still needs to get formulated. The idea is to make splitting undesirable. For example, a 50M pledge in just one pool will earn 6% reward (so 50M * 0.06), but splitting it into two pools of 25M pledge each will only make it earn 5% (so 2 * 25M * 0.05). Something along that line...

So, in a way the reward re-structuring is based on how you would want the participants to behave: a) you want the pool operators to avoid pool splitting and b) you want the stakers to minimize wealth-seeking behavior. Because they are decoupled, it is now easy to influence their behavior separately.

I am sure this will take a new set of equations very different from CIP-45. My questions are:

1. Will I be able to combine both delegation restructuring and reward restructuring? Splitting them into different CIPs will not make sense.
2. Do I need to make another post in the Cardano Forum and then re-post a new CIP?

[rphair]

Will I be able to combine both delegation restructuring and reward restructuring? Splitting them into different CIPs will not make sense.

@jycappucino the way you've described it, those two ideas # 1 and 2 are distinct and could each be implemented separately: so the logical thing would be to have two separate CIPs (by same reasoning as @KtorZ was offering) even if they appear to have the same goal.

Do I need to make another post in the Cardano Forum and then re-post a new CIP?

The original Forum posting linked in the CIP header will form the basis for whatever follow-up proposal you make, and should be continued for that reason alone (note many long standing threads on the Cardano forum have gone on for 2 years or more).

But more importantly the contributors to that thread have included several people interested in this issue (including the author of CIP-50) and the evolution of your idea would be helped by retaining these people rather than fragmenting your audience.

For you to check: whether Discourse will allow you to edit your title, after so much time has gone by since your OP, if terms like "Pledge as a bidding parameter" no longer apply. If necessary you can get a forum moderator to retitle it for you.

[KtorZ]

This means that delegators wouldn't be incentivized anymore to chose pools that are actually producing blocks. Delegating to an inactive pool would be rewarded in this proposed scheme, which in the long-run may harm the network (as no one would really care changing their delegation to an actually working pool).

[jycappucino]

Delegator reward can be tied to pool performance. If the operator produces all blocks at 100% capacity for each block in an epoch, then the delegators will get their 0.0616% epoch reward (or 4.5% annual reward).

Note: I replied to two of your comments, but I will revise the document per your suggestions reflected in your other comments.

[rphair]

@jycappucino marking "Waiting for Author" based on discussion @ today's CIP meeting # 51 and pending resolution of the items in @KtorZ's review.

[rphair]

p.s. also @jycappucino I wanted to invite you again (as in earlier #229 (comment)) to the Discord discussion currently titled #...cip-0050... but should probably be retitled as a more general discussion of all CIP's relating to stake delegation incentives.

Because of the author alias I can't tell if you've been in that discussion already, but it would help the community discussion of the general issue to have you there & we'll see if we can change the group title to make it more accommodating for other CIP authors & advocates. Your suggestions should be included in discussions of similar proposals while they're currently taking place, e.g. https://blogs.ed.ac.uk/blockchain/2022/07/21/comparison-of-alternative-reward-schemes-for-cardano/

[jycappucino]

Hi @rphair, thanks for the invitation. This CIP is going to fail miserably without the assurance that pool splitting is going to be expensive. I did not know that 1 node can have multiple IPs beforehand when I formulated the CIP as I mentioned to you earlier. So, there is a need for me to revise the equations so that operators would want to keep their pledge in one pool. I have an idea but very premature (the idea clashes with how to keep the system closed).

Also, I have not been in that discord discussion. Will join when I feel that I can properly defend this CIP. Will save myself from any embarrassment for now. Thanks, @rphair!

[jycappucino]

@rphair and @KtorZ,

I found a way to revive this CIP without resorting to hardware deterrence. I have to slightly modify the equations but not much. The optimal pledge will be one million. However, I found a way to accommodate pools with lower pledges, e.g., 100K pledge equals over 1M saturation limit, by using the erf function. Also, it will take over 1B ADA to attack the system regardless of how the attacker slice and dice his pledge.

Everything else is the same. It may take a while for me to revise this CIP as I am undergoing a significant transition. But will do @KtorZ suggestions.

Thanks!

[KtorZ]

Closing this for inactivity. Feel free to re-open once the edits have been addressed.