Cardano-node: [BUG] - Collaborating on pledge to form a stake pool does not require significant trust between the owners

[Straightpool]

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:

1. Sweet talk ADA whale to extract and share staking keys for whale wallet
2. Update pledge on pool with the additional stake.skey and stake.vkey from ADA whale
3. 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)
4. Be the evil SPO and increase variable fee to 100% so the sweet-talked whale will get no rewards
5. 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
6. 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

[shawnim]

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 <[email protected]> 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.

[Straightpool]

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.

[dcoutts]

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.

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.

[nc6]

• Be the evil SPO and increase variable fee to 100% so the sweet-talked whale will get no rewards

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.

[disassembler]

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: https://github.com/trezor/trezor-firmware/pull/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.

[Straightpool]

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:
"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."

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.

[Straightpool]

I just re-read the spec section. The spec defines the requirement of "significant trust" with:
"Allowing the operator to shut down the pool, kick other owners off, or fail to distribute rewards
raises the threshold of necessary trust that owners of the pool must have in the operator."

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.

[JaredCorduan]

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.

[Straightpool]

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. 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").

[shawnim]

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 <[email protected]> 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.

[rdlrt]

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.

[DamjanOstrelic]

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:

1) essentially take small pool owners out of the competition as they cannot accumulate 500k ADA and that will greatly impact their rewards
2) make it easy for the rich to control competition by splitting their pledge into 500k/1M/2M bags. Assuming that the CIP proposal allows some pool with a 500k pledge to ask for some margin, it is easy to beat that pool in the rankings using the same margin and a slightly higher pledge.

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 .

[Straightpool]

@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.

[DamjanOstrelic]

@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.

[rdlrt]

Are we discussing the possibility of one SPO making multiple partnerships to create a Sybil attack?

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.