[BUG] - Collaborating on pledge to form a stake pool does not require significant trust between the owners #2109
Comments
|
It could be made even stricter by only allowing 1 wallet to pledge.Then all owners would have to pool ADA in a single wallet which would require continued trust, not just trust at time of pledging.
On Thursday, November 19, 2020, 1:05:37 PM PST, Straightpool <notifications@github.com> wrote:
Internal/External
External
Summary
The current implementation of collaborating on pledge via the stake.skey and stake.vkey is in direct violation to the design spec:
https://www.adatainment.com/_downloads/docs/delegation_design_spec.pdf
"That is a conscious design decision: collaborating to form a stake pool should require significant
trust between the owners. Otherwise, everyone could choose to become a co-owner of a stake
pool instead of delegating, which would render the mechanism of pledging stake ineffective."
To collaborate on pledge for the sharing party it is sufficient to securely extract the stake.skey and stake.vkey from a wallet and share these key files with the SPO. The risk for the sharing party is on par with delegating. In the worst case the sharing party is losing out on rewards for a few epochs, the sharing party could then easily just move the funds to another wallet with the payment keys and generate new staking keys. The risk properties of this sharing is thus akin to delegating.
Pledge as a service is thus getting more and more common every day and will get even more common when a0 is raised and/or the CIP-a0 is implemented. It will becomes harder and harder for delegators to differentiate pools with actual skin in the game versus pools which just took a minor risk breaking their pledge promise by accumulating and registering stake.skeys and stake.vkeys of sweet-talked ADA whales.
Steps to reproduce
Steps to reproduce the behavior:
- Sweet talk ADA whale to extract and share staking keys for whale wallet
- Update pledge on pool with the additional stake.skey and stake.vkey from ADA whale
- Benefit from the larger pledge with minimal risk for the sweet-talked whale (losing out on rewards for a few epochs) and low risk for the SPO (breaking pledge for a few epochs / losing out on rewards for a few epochs)
- Be the evil SPO and increase variable fee to 100% so the sweet-talked whale will get no rewards
- Sweet talked whale can just re-delegate by sending the funds to a new wallet with the payment keys and generate new staking skeys to repeat the "pledge delegation" with another not yet evil SPO
- Be not surprised at the flourishing Cardano Pledge as a Service offerings which will make Pledge meaningless if not fixed
Expected behavior
To collaborate on pledge actual trust is required. To register pledge the payment.skeys / hardware wallet confirmation of all owners are required "in parallel".
"In parallel" is the tricky and important part, as sequential signage would allow SPOs with no skin in the game to hand over the signature to each sweet-talked whale. One party must at one time hold all payment.skeys or hardware wallets to set the collaborated pledge. This one party should be able to drain all the wallets doing so, as only this process provides enough assurance of high trust and differs this pledge process from "just delegating".
System info (please complete the following information):
- OS: Ubunto
- Version: 20.04
- Node version: 1.21.1
Screenshots and attachments
- not applicable
Additional context
- none
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Shawn, I love you line of thinking! I agree this would be the easiest and best solution and would kill pledge as a service with little effort. All pledge should be allowed only from one wallet. If people want to collaborate on this they will have to pool their funds together in one wallet. To implement this, stake keys can continue to be used to register the pledge, there can however be only one stake.skey and stake.vkey to register the plege and not multiple. So whoever controls the export of the stake keys can drain the wallet for all co-owners requiring the trust as required by the spec. The tricky part is invalidating all pledges which are currently using multiple staking keys with a little bit of warning for the pools to fix this by either reducing their registered pledge or by actually creating the required trust relationship between their co-owners. To be honest, I was shocked when I talked to other SPOs how they got to their level of pledge, all of the SPOs I talked to used this low-risk method I described. This loophole needs fixing. |
This seems like a very unwise thing for a pool owner to do. It is generally not in your interests to hand over the signing keys to anyone else. But I don't see that it fundamentally changes anything. The unwise pool owner here still has to trust the SPO to give them any rewards. The SPO still has to trust the owner to keep their funds delegated to the pool. The unwise pool owner has handed over the signing key for their stake key but not their funds, so they can still unilaterally move their funds and withdraw their pledge. |
This line seems to suggest a misunderstanding of how rewards for owners (e.g. those who contribute to the pledge) works. The fee is irrelevant here - as an owner, you will receive no rewards unless the pool operator manually pays them to you. So if you decide to be an owner (by handing over the signing keys or otherwise), you have to trust (and verify) that the pool owner will pay out those rewards every epoch. |
|
One comment to add to above comments from the developers. If you give away your stake.skey from your wallet, it's not enough to just redelegate, as anyone that has your skey can reverse your change. You need to move all your funds to a new wallet at that point and stop using the old wallet. Moral of the story, if the key ends in skey it's not okay to give to anyone. Hopefully whales are using hardware wallets where it's impossible to accidentally extract the skeys (well unless you manually utilize the backup phrase for the wallet). Yes I know, firmware updates aren't available yet to sign a tx containing a pool cert, but it's coming in December to do so. Hopefully we'll see an uptick in whales with significant funds forming pledge relationships at that point. In addition, the comment about order of signing. The way the system is designed if you haven't forfeited your skey, you and all other owners (as well as the pool owner with the cold key for the pool) have to sign the raw unsigned tx body that lists all the owners of the pool. You can see an example animation of how this is parsed by hardware wallets and displayed to the end user in this PR: trezor/trezor-firmware#1317. Then someone (either the owner or any other party that obtains all the required signatures) can submit the tx to the blockchain. Potentially in the future, a coordination server can be utilized to collect all the signatures to make the process less manual, but we're not there yet. |
|
Thank you so much for commenting, my reply on the points: It may be unwise but it is happening all over, as sharing pledge with the stake.skey and stake.vkey is VERY easy to do and has no risk for the sweet-talked whale. This script is used to extract the staking keys from any wallet be it Daedalus or a hardware wallet: https://gist.github.com/ilap/3fd57e39520c90f084d25b0ef2b96894 Yes, it was a non-relevant misunderstanding on my part, the sweet-talked whale will need to receive the rewards manually from the SPO doing this. Still the worst that can happen to the sweet-talked whale is that the SPO stops to send out rewards manually (or via a smart contract later in the Goguen area) in the agreed upon height. In this case the sweet-talked whale can simply "re-delegate". I should have put "re-delegate" in quotation marks on my original post. It is clear this takes a little bit more effort than standard re-delegation. The sweet-talked whale will need to send the funds to a completely new wallet and generate new staking keys. Still this takes about 5 minutes, so is not that much trouble and has zero risk. I want to reiterate people do this all over already and this will get much worse when pledge actually matters when the a0-CIP is implemented in any shape or form. I stand by my point that the trust required by the sweet-talked whale is too low. His funds are NEVER at risk! From my point of view the simple implementation idea from Shawn is the way to go, as it avoids the problems of the order of signing. Just allow only one stake.skey and stake.vkey pair for the pledge registration. Reduce n to 1. So, the spec part I quoted: is from my point of view still fundamentally broken. The mechanism of pledging stake is ineffective with the current design! I see no point in this process which requires "significant trust". In the worst case BOTH parties lose about 2 epochs of rewards. This is nothing that requires "significant trust"! "Significant trust" IMHO only happens when the actual funds are at risk which is achieved with the simple implementation change as proposed by Shawn. |
|
I just re-read the spec section. The spec defines the requirement of "significant trust" with: This is all still valid, so my issue apparently is not with the code per se, but with the spec (which the code follows), judging by the practice I see. As I elaborated, due to the risk properties being too similar to delegation itself (exactly what the spec wanted to avoid), I disagree this is enough to require significant trust. Losing at max 2 epochs worth of stake requires miniscule trust at best IMHO. |
|
this behavior is already supported by the protocol without ever sharing any secrets (this is what @disassembler was saying, I'm just making sure that this is clear). A new owner only needs to sign the transaction body containing an updated pool certificate. This does not render the pledge meaningless. |
|
Thanks, Jared, for clearing this up. I understand, collaborating on pledge can be done even easier without passing out stake.skeys to the OP as this collaboration is supported by protocol design. Making this even easier does obviously not lessen my concern, that the required trust for this collaboration is way too low from my point of view. "Meaningless" probably was a too strong word I used; I am sorry for that. "Ineffective" is probably the better word as in the spec: The first instinct I had: It would be nice for delegators to be able to differentiate pools which have skin in the game aka "operator = owner" and pools in which a kind of partnership is in place. This seems to be really hard to prove as it would require to allow and to detect the difference between cryptographic parallel signatures as opposed to sequential signatures with the payment private keys (see https://stackoverflow.com/questions/46234206/signature-pades-sequential-or-parallel) The second instinct I had: It would be nice if the required trust in a pledge partnership was actually "significant" so delegators can have trust in such constructs and the barrier of entry is higher so not every 2nd pool will do this this when pledge matters (rendering the pledge mechanism "ineffective"). |
|
I agree with Straightpool that there is not sufficient risk/trust in the current system.When we see pledge become meaninfful through either CIP7, it's evolutionary alternatives or an increase in a0, we will see the development of a secondary market for "pledge for hire".I think limiting pledge to one wallet creates the ongoing level of risk/trust that is needed.
On Friday, November 20, 2020, 2:26:41 PM PST, Straightpool <notifications@github.com> wrote:
Thanks, Jared, for clearing this up.
I understand, collaborating on pledge can be done even easier without passing out stake.skeys to the OP as this collaboration is supported by protocol design.
Making this even easier does obviously not lessen my concern, that the required trust for this collaboration is way too low from my point of view.
"Meaningless" probably was a too strong word I used; I am sorry for that. "Ineffective" is probably the better word as in the spec: "Otherwise, everyone could choose to become a co-owner of a stake
pool instead of delegating, which would render the mechanism of pledging stake "ineffective".
The first instinct I had: It would be nice for delegators to be able to differentiate pools which have skin in the game aka "operator = owner" and pools in which a kind of partnership is in place.
The second instinct I had: It would be nice if the required trust was actually "significant" so delegators can have trust in such constructs and the barrier of entry is higher so not every 2nd pool does this when pledge matters.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
As much as we agree the pool owners doing so are "unwise" , it is becoming increasingly common (in fact those doing so are not even declared as owners by the SPOs offering PaaS). A very big majority of those with large pledge atm do exhibit this behaviour - and increasingly more small pool operators have started offering such services, making pledging a lot more common than it should be - as it renders the pledge effect useless (or rather puts it in the hands of those who run PaaS). "Running after profits" is far bigger carrot for an average to decent stakeholder than trust atm, and increasing of pledge factor's impact (inevitable soon) will only increase this further. |
|
As someone who does run a stake pool in partnership with a whale, I agree that the process is easy, however, the pledger still depends on the SPO to distribute the rewards which become significant even for 1 epoch if large pledge amounts are at stake. The way I see it is that the main problem possible scams that can emerge from this, especially if the pledger is not very technical. He/she could easily be tricked into a "safe" key extraction process that reveals their payment keys to the SPO. Otherwise, I don't think there is a problem because there is still trust required even after the pledge certificate has been signed. I think there is a major problem with the CIP making pledge more "influential" and setting the "required" pledge to ~500k as I think it will do several bad things:
For example, we have access to 30M ADA for pledging - we can create 30 1M pledge pools to beat any 500k pledge pool. But it's not even just that, but setting the "soft minimum" for the pledge to 500k just means you have to invest that much into running a pool and not many people can do that in general. So I think the linear pledge function is still better (but of course has its problems) because it doesn't make it easy for the rich to take advantage of their pledge capabilities. And I am sorry because I didn't fully read the CIP yet, but this is my current understanding of the proposal - to make the pledge function non-linear for the lower values . |
|
@DamjanOstrelic This issue has no direct relation to the curved pledge CIP, please discuss here and please do fully read the CIP before commmeting on it: https://github.com/cardano-foundation/CIPs/blob/master/CIP7/CIP-ShawnMcMurdo-CurvePledgeBenefit.md The indirect relationship is that any increase in relevance of pledge (linear or curved) will multiply the already seen behavior of "Pledge As a Service". "Running after profits" > "Risk aversion". Risk of such partnerships needs to be increased for the whale to be on an even footing with "running after profits" to not lose the pledge mechanism effectiveness altogether. |
Well it looks like my understanding is correct from glancing at it again, so I will leave my points as they are. But I agree, it's an indirect relationship that does make partnerships more attractive as reaching a certain amount of pledge will become essential for running a pool. But in terms of the risk of partnerships, I'm not sure if there should be more risk. Pledgers depend on the SPO to distribute rewards, SPO depends on the pledger to keep their pledge. I don't think these are low-risk things, and I doubt a pledger would be quick to look for another partner if he got held out from his/her rewards the first time. Are we discussing the possibility of one SPO making multiple partnerships to create a Sybil attack? Will stop commenting now to see how this discussion continues. |
No, I think what's being highlighted is that pledging - the way currently majority of crypto users think - is becoming very common, because they weigh an advertisement of higher reward if they pledge as substantially bigger carrot than quantifying risks associated. The SPOs offering such services do not even deem those delegators as co-owners. Thus, the problem - in my view - is the assumption of common sense being common fails atm, rendering the concept of pledging less effective, as these services are increasing.
|
|
Do we not agree it should make a difference if A) 1 owner wallet is pledging 1M ADA for a total pledge of 1M ADA ? Maybe one elegant way to incentivize desired behavor is this:
|
|
I find the problem of no trusted pledge to be larger than pledge having little value as with the current implementation. If one operator is behind a cloud of whale pledged pools, they can silently gain significant leverage over the network (sybille attack) at little to no cost out of pocket. The concept of pledge is for the SPO to have 'skin in the game'. With the current model delegates are just becoming co-owners and no pledge can be trusted. It seems the focus on leverage is pointed toward pool splitting like the extreme example 1PCT pool group. This is an obvious case of an over leveraged operator. However, little focus is on operators accumulating independent pools using whale delegates. Some groups are obvious, like EDEN and BCSH, but there are many more that do not all fly under a common ticker. This is a problem that cannot be monitored, because there is no identity associated with a stake pool or its pledge. It will only amplify once pledge actually has an influence on rewards. For this reason it is of the utmost importance that this issue is addressed. I think str8 is on the right track by limiting owners to 1 or having a higher number of owners negatively effect rewards. Pools with little to no pledge are penalized with reduced rewards because they have no 'skin in the game'. Pools with whale delegate pledge should receive similar treatment because they also have no 'skin in the game' |
|
Pledge should be limited to 1 wallet. |
|
After thinking more on this topic, limiting owner wallets to just 1 would not cause much disruption. Right now many whale delegate pledge setups are already this way. Whale provides their stake key to setup the pool, but the SPO uses his own reward account. Then SPO pays the pledger as a sort of employee of the pool. Forcing 1 owner would provide no real change except in cases where there are in fact multiple owners. You could force the owner and reward account to match to make the SPO the employee of the pledger, but that won't cover all the bases. In the case of BLOOM's hidden pools, they force payment in advance so the pool can remain 1 owner with matching reward key. Payment stops, pool stops. 0 risk for the SPO. This is the type of setup that is the most dangerous and need to be protected against. Besides forcing a .skey onto the BP node itself I cannot think of a solution to this problem. |
|
Due to the current design requiring from the pledge provider no trust higher than from a regular delegator we will very soon see implementations leveraging this weakness and thus putting the pledge mechanism completely ad absurdum with a simple button click. At least one SPO is working on a pool specific custom wallet with custom high-spec'd backend allowing regular delegators to pledge instead of delegate to their "private" pool(s). Private pools with community participation. Delegates who delegate/pledge via these custom wallets will receive more rewards than regular delegators from the very start as they are part of a private pool as pledge providers & co-owners with more rewards to distribute. The custom backend does automatically modify the pool registration to adapt the pledge and distributes the owner rewards according to the pledge share back to the pledge shareholders. As this behavior is highly incentivized the pool will gain more and more pledge until it saturates in pledge peaking in 15% rewards more than a regular 1% community pool for delegates outclassing any regular community pool not exploiting the current pledge implementation. Pledge does obviously require some kind of locking mechanism to protect the pool. Before smart contracts, in the first iteration, these custom wallets will include multi-signature addresses for locking. Delegators will be asked to give up partial control of their ADA by sending their ADA to pledge to a newly generated multi-signature address introduced by the custom wallet. One part of this signature is in control of the pool asking for pledge, one part is in control of the anonymous community pledger. To unlock the pledged ADA the delegate will need to send the ADA to another wallet address of his own. This outgoing transaction will be automatically co-signed by the custom wallet / backend after waiting for the epoch delay to pass to not break the pledge promise of the pool. Pools can transparently outline their workflow, part of the relevant custom code and provide proof the co-signature is held by multiple redundant trusted parties to ensure pledgers they can access their ADA at all times. When smart contracts arrive, multi-signatures will be replaced by auditable smart contracts for locking, making anonymous community pledge completely trustless. Still believe this is a non-issue? Do we still care about Sybil protection? In my opinion the only fix is to limit pledge to one wallet. We definitely need a solution for this before anything in the realm of CIP 7 for the curved pledge benefit is implemented as this CIP will increase the pledge effect for this exploit even further. |
|
The situation you describe at present doesn't really conjure up the image of "no trust" to me - you have actually transferred your funds to an address that you don't fully control. You have to trust that the other party will not blackmail you over control of the pledge amount - this seems a substantially higher degree of trust than that currently required of pledgers. However, you raise a very valid point that, with the onset of Plutus scripts, it would indeed be possible to replace this with a trustless implementation. It wouldn't entirely be 0-cost (you would lose some liquidity) but this is significantly less "skin in the game" than risking not getting any rewards (on either side). Unfortunately, the solution you propose would have no effect on such an implementation, since the owner pledge could come from a single (script-locked) address. Anyway, thinking about this, suggestions welcome, and thanks for bringing it up! |
Just another point of clarification. Nothing in this scheme has any negative impact on Sybil protection. Indeed to the extent that it means more people pledge more, it benefits Sybil protection. Remember that the Sybil protection ultimately comes from the fact that the same ada can only be pledged to a single pool. |
On further reflection, we don't allow scripts to be owners of pools. So it would not be possible to get trustless pledge-only pools. Note that this is equally true for multi-sig addresses, so your described "custom wallet" situation is also precluded. |
|
@Straightpool We're not convinced there's a problem here, but that may be partly because the details of the hypothetical scheme you're describing is not totally clear. Would you mind having another go and clearly describing the scheme you have in mind. Leave out the consequences, just explain precisely what the scheme is. |
|
I'm not going into technical/cryptographic details, as some experts are much better at this than I am, but just want to express a general thought: The question is whether this is currently already the case, and whether this is also taken into account in the ongoing development of smart contracts? |
|
@dcoutts, sure happy to give the scheme another go, using the new input provided. Thank you for looking at this:
@nc6, Cardano-cli 1.27.0 is really flexible these days allowing arbitrary key combinations to build addresses:
|
|
@Straightpool Does Bob fully control the stake address that is registered to receive the rewards from Bob's pool? |
Do you mean from one owner? There is no notion of "wallet" at the protocol level. Currently we do allow multiple owners, but each owner must be a key credential (ie not a script, multi-sig or plutus). |
If I understand this right it wouldn't even be possible to use multi-sig wallets without smart contracts as source of pledge and none of the described schemes should work at all. right? Question is what exactly we are talking about. the plan of this scheme is to accumulate pledge from different owners (multisig and later one smart contracts) paired to one single simple stake key, hold only by the operator of this scheme. |
|
Thanks for elaborating. It looks like this does present a different trust proposition from that initially envisioned, either partially trustless (with multi-sig) or potentially fully trustless (with Plutus). It also cannot be easily addressed by restricting to one owner, which would in any case have adverse consequences for groups of small stake owners with mutual trust wishing to form a pool. We'll bounce this one to the incentives researchers and see what they say (and update here with the result) |
|
Half a year has passed, any updates to share? Franken Addresses are a way to register additional pledge to a pool without registering a second owner on the blockchain, see https://www.youtube.com/watch?v=KULzovfWn-M&t=3s So not even limiting the number of registered owners to a sensible manner can prevent the exploit, which is IMHO inevitable. I would personally thus reduce a0 to 0 to not incentivize the exploit further and refrain from ever increasing a0 or every SPO will try to exploit this eventually. |
|
I will raise this again right now with incentives researchers. |
|
@Straightpool I was able to meet with the incentive researchers last Thursday and present this issue to them. They agree that the trust model is different in the presence of time locks and Plutus scripts. There is still a sizable cost, however, to participating in the scheme you describe. Alice is required to lock her funds for a given period of time. The act of locking stake to be used as owner stake is certainly an act of trust on the part of the user, though of course the worry is that a slick media campaign could be the cause of many uninformed users placing their trust in a malicious party. To be clear, there is nothing innately malicious about the scheme you described above. People should be encouraged to maximize their profits. I do not think that limiting the set of owners to ten credentials would make any difference. In the scheme you described, only one owner is needed since the user interface can create addresses which use Bob's stake credential. As a part of other ongoing work, we want mechanisms for punishing actual malicious activity. This is our long term strategy to handle this and other issues. I will keep you informed if and when we have any good short term solutions. In the mean time, let's all do our best to inform everyone that their delegation choices really do matter. |
|
I didn't realize that your previous message was edited, so maybe my answer was confusing. It seems we are in agreement that limiting the owners does not help. Is that why you are 😕 with my answer?
I am not convinced of this. This would mean that all users are happy to lock their funds. And I still don't see a clear strategy for distributing the owner rewards without some form of trust (even with a Plutus script). The tricky details involve: 1) when does the stake pool submit the pool parameter changes, which have an epoch delay, 2) when does Alice lock her stake, and for how long, and 3) if the pool's registered reward account (for the owner rewards) is a Plutus script, what are the details of how it works. |
No, this is not why I 😕 your answer. I do highly appreciate you did have a meeting with the incentive researchers and reported back, I am just not happy about the outcome which basically declared this as a non-issue. I learned about Franken Addresses after I proposed to limit owners to 10-20, so I deleted this part, which is no longer a viable technical solution to prevent the looming exploit. I disagree with the following assessments:
Oh people will maximize their profits by time-locking their ADA via audited smart contracts happily. Here, I see a gap between game theory and the current reality. Take a look at https://adapools.org/groups, the largest single entity by far is Binance with currently 62 pools all saturated with their customers ADA. Many of those customers happy to time lock their ADA to gain more rewards than a regular community pool can provide. Binance does not even pledge this ADA yet, they most likely leverage the gains from staking the ADA of customers, who didn't actively sign up to stake, to hand out higher rewards to those who did sign up. The new exploit will in fact increase the pledge. The increased rewards will be used to hand out higher rewards to the delegators who pledged, the rest goes to the SPO as added rewards. A win-win, incentivized on both sides.
Yes, it is tricky. But solvable. There is at least one team I know of actively working on this for months now. They started by launching a community wallet as a means to conduct the pledge exploit when the code is ready to push and grow their pools. |
|
@Straightpool I didn't mean to sound dismissive. I'm not declaring this a non-issue (nor is anyone else at IOG).
This nice thing about your proposal here is that there is no immediate rush to set a0 to zero. Since a0 is a protocol parameter, it can be changed quite swiftly.
I'd love to see the details :) |
|
We will now soon be able to vote to give Catalyst funds to more quickly see the details how this will work, the first project calls this "Stake Vault", currently 50% done: I am sure this will be very successful and many delegators will be happy to lock their ADA "in their own wallets" temporarily to gain more rewards. It is very sad the only idea we still have to "prevent" this from happening is reducing a0 to 0. This is like running a chocolate store which hands out chocolates on a fair basis until one finds an exploit to get more chocolates than any other. The only idea the store has is to remove all chocolates from the store and close shop. |
|
Why not limit pledge to come from a single address? |
See @Straightpool 's post above about "Franken Addresses" |
|
@shawnim - @Straightpool 's 😕 emoji makes me wonder if you meant a payment address or stake address. if the former, then the scheme can probably still be implemented with a plutus script in the payment credential to remove the risk, and if the later, then my comment stands about "Franken Addresses". |
Your statement about "Franken Addresses" most likely still stands, this final "hack" has pretty much destroyed any hope in my mind we will find a fix which can ensure pledge means what it was intended to mean: Skin in the game, Sybil protection. Soon pledge and all game theory about pledge will be fully led ad absurdum and a laughing stock. I don't see how limiting the pledge to come from a single payment address can help. In "Franken Addresses" the ADA is still in control of the payment address, the stake key is just associated with another wallet owned e.g. by the SPO. The Delegator turned Pledger still retains payment key control of his funds with some kind of added time lock logic within his own wallet. HOWEVER, IF it is possible to detect "Franken Addresses" or regularly build mixed addresses or multi-signature addresses constructed with "cardano-cli address build" or by other means when validating and only allowing addresses to be counted for pledge if they have the following two criteria:
This could be a fix! 🥇 So next question, is this detection/validation feasible at maybe pool registration/modification time to keep pledge relevant? |
|
Unless it's feasible to implement something like @Straightpool suggest or there is another solution: It's disappointing that pledge has become meaningless. |
|
Closing this. If this is still relevant please re-open. |
|
As it was not me who closed the issue, I can't reopen it. It is still relevant IMHO with all the discussions and CIPs asking to give pledge more meaning. Additionally, a very similar working implementation of the scheme described here has been shown in production in 2022. It has not been successful / accepted widely enough in the bear market, so this service was retired again for now, but this doesn't mean another attempt in the future will not work or we should stop discussing this. I thus propose to re-open this issue. |
|
It would be interesting to hear from Eternl why exactly they retired the service. I still believe that requiring users to lock their funds is a big dis-incentive. |
|
@JaredCorduan "While the concept was promising, Staking Vault hasn't attracted much attention because ADA holders are used to unlocked staking. The Staking Vault redemption page will be available as long as there is a single locked utxo left to redeem. All rewards will be paid as guaranteed when you locked your funds. We want to say "Thank you!" to all our supporters. Please delegate to TITAN instead." |
|
Seems we will soon see another attempt at this turning delegators to pledgers via smart contracts pretty much trustless. At least it sounds to me like the same idea: "If you have 72M $ADA you earn 30% more $ADA staking rewards than normal #Cardano delegates from pledging. With @atrium_lab's Staking Baskets, we're working on bringing a solution to allow delegates to earn an additional 30%. Bring the $ADA rewards to the people! Stay tuned." |
and others
Internal/External
External
Summary
The current implementation of collaborating on pledge via the stake.skey and stake.vkey is in direct violation to the design spec:
https://www.adatainment.com/_downloads/docs/delegation_design_spec.pdf
"That is a conscious design decision: collaborating to form a stake pool should require significant
trust between the owners. Otherwise, everyone could choose to become a co-owner of a stake
pool instead of delegating, which would render the mechanism of pledging stake ineffective."
To collaborate on pledge for the sharing party it is sufficient to securely extract the stake.skey and stake.vkey from a wallet and share these key files with the SPO. The risk for the sharing party is on par with delegating. In the worst case the sharing party is losing out on rewards for a few epochs, the sharing party could then easily just move the funds to another wallet with the payment keys and generate new staking keys. The risk properties of this sharing is thus akin to delegating.
Pledge as a service is thus getting more and more common every day and will get even more common when a0 is raised and/or the CIP-a0 is implemented. It will becomes harder and harder for delegators to differentiate pools with actual skin in the game versus pools which just took a minor risk breaking their pledge promise by accumulating and registering stake.skeys and stake.vkeys of sweet-talked ADA whales.
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
To collaborate on pledge actual trust is required. To register pledge the payment.skeys / hardware wallet confirmation of all owners are required "in parallel".
"In parallel" is the tricky and important part, as sequential signage would allow SPOs with no skin in the game to hand over the signature to each sweet-talked whale. One party must at one time hold all payment.skeys or hardware wallets to set the collaborated pledge. This one party should be able to drain all the wallets doing so, as only this process provides enough assurance of high trust and differs this pledge process from "just delegating".
System info (please complete the following information):
Screenshots and attachments
Additional context
The text was updated successfully, but these errors were encountered: