Decentralize project registration & Beacon deletion responsibilities

[grctest]

RTM is being overwhelmed with support requests regarding beacon deletion issues; I understand that there are substantial beacon fixes in the recent/upcoming client releases, but how could we go about relying on the network rather than trusted third parties?

Vote on trusted CPIDs (witnesses/delegates/represenatives) to provide the project registration/maintenance responsibility?

Thoughts?

[iFoggz]

interesting. cpid issues are always an issue however in a dream would there would be no beacon issues :p Would be nice if a user could send there own beacon deletion themselves however that's dangerous in a sense as you'd have to hope that it is in fact there own beacon (leaves room for exploiting.)

I would lean towards a few things:

1) A second person or rather a consensus of respected user(s)s (1 or more) whom could potentially be given the responsibility to take these tasks as they come. 2) A change where a consensus of vote between known high balance trusted users can vote to vouch for the beacon removal after a checklist of circumstances be completed (verifying the transaction for deletion came from the grc address associated to the cpid, etc.)

The beacon fixes have been vast and solve a lot of problems however people with issues in the past have issues.

I know there is possibly another beacon issue i suspect but not confirmed just yet.

We can always have a vote.

[jring-o]

This is more relying on the network then specific to beacons:

Decentralization can contain centralization within it so long as those given power are under constant threat of having that power revoked. I like the idea of having a set number of "admins" or "witnesses" or whatever so long as there is a list of people lined up to be admin behind them and the barrier to being replaced as an admin is minimal. Also, the opportunity to administrate should not be reserved to "whales."

Let's say the community creates x admins. They have earned the respect and votes of the community by adhering to a set of principals -- currently unwritten -- agreed upon by the community and by going beyond the minimum. With the x, we also have 10x potential admins ready to take their place should they

A. Dishonor the power they have been given. or B. Resign

And the ability to at least freeze the actions of an admin requires a minimal vote: say 25%. When an admin is frozen, one from the list of potentials takes their spot until further action is decided upon. Freeze protocols could potentially also be written into the network.

[tomasbrod]

I think that a two level delegate scheme should be used for Administration tasks. Currently there is a Master Project key and restricted operations require message to be signed by this key.

With 2LDS, holder of the master key, signs public key of delegate, and this permission is then published as message on the blockchain. Similarly he can also revoke such permission. Delegates than use their own key to perform the administrative tasks.

Delegates could be voted in, but the granting and revoking permission by results of a poll can, for simplicity reasons, stay manual.

[TheCharlatan]

What is the benefit of having these delegates instead of controlling beacon deletion oneself? If a beacon registration would always take two transactions, it would just lay dormant if you chose to delete one key, until you have added another key back again.

[tomasbrod]

I am talking about the Administrative tasks, like deleting beacon, adding project, @TheCharlatan, not actually sending the beacon! Also user requested beacon deletion already takes two (or three?) transactions.

[jamescowens]

This is closed by #1695.