As a crowdloan participant I must be able to prove ownership of my polkadot account on a parachain

[lucasvo]

A likely common use-case for the crowdloan module is to promise participants in the crowdloan a reward on the parachain once it's launched. The crowdloan module already exposes the child-trie with account contributions that can be imported into the parachain.

To guarantee that every kind of account will be able to receive their reward on the parachain a user must be able to prove that they own the polkadot account A and would now like to be paid out the reward on the parachain account B. While we could simply request the user uses the same key and verify a signature, this fails in a few cases:

1) the parachain does not wish to support the same set of signature schemes as the relay chain 2) the account is an anonymous proxy or a multisig

For that reason the relaychain should support a method that can send a well defined XCM message to the parachain linking that allows the parachain to verify that the request to be rewarded to account B really was made by account A.

[shawntabrizi]

@lucasvo I dont disagree there are probably ways that the Relay Chain can make it easier for parachains to find the right account to reward someone for their contributions, but this should not be your immediate solution.

It should not be that the relay chain absorbs a bunch of random code and logic to support the payout scenarios for the many different parachains that it supports. Instead, you as the parachain developer and the full flexibility of the runtime can and probably should build such logic on your side.

For example, look at the claims pallet of Polkadot: https://github.com/paritytech/polkadot/blob/master/runtime/common/src/claims.rs

We accept an Ethereum signed message to claim the rewards of the user. You can just as easily as the polkadot contributor to sign a message and then verify that message on your chain.

[h4x3rotab]

I agree with Shawn on validating signature from regular external owned accounts (EOA). However the point of this issue is about signaling the ownership of some contribution (e.g. for claiming the reward token on the parachain side) by the non-EOA accounts (i.e. multisig and proxy).

To me the most straightforward way is to allow any EOA or non-EOA account to send some arbitrary text to a parachain behalf of the that account. Then the parachain itself can decode the received message and decide what to do on its own.

An example could be:

1. A VC fund set up a anonymous proxy, backed by maybe some multisig
2. The fund participated the crowdloan and contribute to parachain candidate A
3. The crowdloan succeeded, and parachain A write a copy of the participators to its storage and waiting for people to claim the native token reward
4. Then, the fund wants to withdraw the reward. However, because the anonymous proxy is only on the relay chain, there's no way to initiate to "claim" transaction from the proxy account.
5. Instead, the fund can send a message like "I want to claim my reward to some ADDR" from the relay chain to the parachain A via HRMP, on behalf of the anonymous proxy.
6. Once parachain A receives the message, it decodes it, and send it to "ADDR" on parachain A.

[lucasvo]

@shawntabrizi Centrifuge uses an anonymous proxy to manage it's DOT treasury. If we use that to participate in a crowdloan we are unable to prove ownership as described in the ticket.

Self-custodying funds as a team in anything but a multisig is very irresponsible. The setup we use is a proxy with two multisigs with different signers and thresholds.

Even worse though: as a project there's nothing we can do to prevent crowdloan participants to not use anonymous proxies. This means if anyone ever does that, there's absolutely no way we could give them the reward. I think quite a few DOT holders will be very unhappy because of this.

[burdges]

I'd expect these (very poorly named) anonymous proxy amounts to just some certificate, yes? You need to figure out if the forward certificate suffices, in which can you can simply ask for it and check it, or if you need a back cert too.

We've like zero back cert currently in polkadot. We've several places in polkadot that require back certs however, which we'll be adding before launching any ETH bridge, but thankfully validators can automatically create back certs for those cases. If back certs become needed in more user facing things like proxies then that'll create some very annoying UX. At least superficially I do not see why a crowd fund commitment requires back certs, so probably all is fine here.

[lucasvo]

@burdges I'm trying to understand what exactly you mean - what is a forward certificate?

[lucasvo]

The anonymous proxy has no certificate (as in currently no way to prove ownership over it) - I think that's the problem. It's just a randomly generated account id that has an "owner" which is some other account. I don't think it's trivial to follow the ownership of the account and verify who ultimately controls this. When you talk about multisigs this gets even more complicated.

[burdges]

A (forward) certificate is a signature by some authorizing key that empowers some authorized key. A backwards certificate is signature by the authorized key that accepts empowerment by the (forward) certificate.

In TLS, we accept our certificates by sending them inside the channel, which includes a long-term key exchange, which makes backwards certificates unnecessary. In substrate's context, we currently lack back certificates by session keys so if you run a validator node which does not get elected then someone could stake your validator under their own controller and earn all the profits themselves. We'll fix this in https://github.com/paritytech/substrate/issues/7398 although abuse looks unlikely.

We should be careful about scenarios that require back certificates because their UX would suck anytime authorized keys are controlled by humans.

Anonymous proxies would presumably require a Merkle proof from the chain state root, but with locks then this could've meaning for longer than 6 seconds.

[xlc]

Duplicates to https://github.com/paritytech/polkadot/issues/2163 Previous work has been shutdown by @gavofyork https://github.com/paritytech/polkadot/pull/2166#discussion_r554145191

[lucasvo]

@xlc I was not aware of this discussion, thanks for pointing it out. One of the two issues should be clsoed though I think given this one has a bit more debate - maybe we'll keep this one open?

[lucasvo]

@xlc upon further reading, I don't think @gavofyork's comment in #2166 is entirely relevant or at least we could find a solution for this that didn't bring this in via a "return_to" address. If I read that comment right - this is about where the crowdloan contribution will be returned to, not where the parachain reward will go.

We don't need to redirect the proceeds on polkadot.

I think we can solve this without building a generic certificate issuing mechanism for anonymous proxies, @burdges but simply by allowing the a single 32 byte field (e.g. a reward payout address or even a merkle root of some fancy data structure) would allow receiving parachains to implement whatever it needs to pay out rewards properly.

[gavofyork]

I'm definitely on-board with creating a relay-chain transaction/dispatchable that allows any account to send an XCM message into a parachain with the messages origin being identifiable as the account on the relay-chain. This is trivial to implement and should address your use case.

[JoshOrndorff]

This was fixed by the add_memo transaction right?

[shawntabrizi]

lets say yes, and if not we can re-open