-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delegated Output Claim Management #7
Delegated Output Claim Management #7
Conversation
Joskye here. Just want to say that I'm fully supportive of this proposal as it creates the right balance between making the reclaim process straightforward whilst minimizing any potential costs of privacy. I hope the community is supportive and vote accordingly. |
I fully support this! |
Want to say I too support this proposal. I was not a fan of the original idea of needing to push individual proposals, this looks a best method to fix the outputs. Thank you. |
I fully support your proposal fellas. Team and selected community members handling the claim is a much better and much more private solution to the problem. I do have a few questions though: A. There is no mention of what will happen with the submitted data. Will it be deleted after some outputs are whitelisted? If yes what timeline are we looking at ? B. What kind of access will people/organizations other than Tecnovert will have to the data. Are you planning to share that data with Bittrex ? Are there any NDAs planned to be signed for the claims managing team? C. The proposal is very specific defining the task of the aforementioned team to be to process manually the claims. Is it safe to assume that if this proposal is approved that does not mean that the claim management team gets to decide if they will use a low pass filter and its threshold ? |
Supported! |
Will support it! |
The output data will be securely kept for a period of time as that helps match and validate outputs from late claims. We're probably looking at a period of around 1 year or so to keep that data, after which point we'll delete everything entirely. That'll be properly communicated before we delete the data so that late claimers do get the forward notice to submit their claims before that time. Though, once a claim is validated, its associated data will be anonymized as to not provide a link between the data and which user provided it.
Tecnovert and myself (Cryptoguard) will have access to that data in order to work through the process. The data will then be anonymized before being sent to the community group for claim outcome verification. We won't be sharing that data with other team/community members or any third-party.
The proposal is only about electing a management team for the process. It doesn't specify the process at which the claims will be processed and what techniques will be used. We'll be communicating that shortly, although for the moment we do plan on using a low-pass filter but with reduced threshold (compared to what was initially proposed). We are still receiving output data from people which is helping to gain a better understanding of the exploit and make the best decision in that regard. |
Thank you for the detailed reply. |
Summary
This proposal is to implement a streamlined and more efficient way to process manual output claims and reactivate temporarily disabled anon and blind balances.
Rationale
On the 25th of February, the Particl team implemented an emergency hardfork to halt an ongoing vulnerability exploit that allowed an attacker to create PART coins fraudulently. To prevent the attacker from moving exploited coins after the hardfork, all anon and blind outputs have been temporarily disabled until the upcoming hardfork.
To re-enable these outputs, the team came up with a strategy involving a low-pass filter and a manual claim process. To learn more about it, please follow this link.
Initially, the team proposed that any user with disabled outputs that can’t go through the low-pass filter would have to individually put up a claim on the CSS for their outputs to be re-enabled. This would preserve a good level of decentralization and ensure the team does not have an ultimate say over what outputs can be re-enabled or not, but it also introduces its fair share of inconveniences.
Following that announcement, the community firmly asked for a more streamlined, simple, efficient, and sure fire method to reactivate outputs, one that would not ultimately be dependent upon the assumed participation and goodwill of stakers. The community asked for the Particl team to be more involved in that process due to the trust relationship between the two parties (community and team).
As a response to this request, the team opted to adopt a middle-ground approach. This approach, namely the election of a group of claim managers through a CCS vote by the community, is what’s being proposed here.
How the Process Will Work
If this proposal is approved, a group of people from the Particl team will receive and process claims on behalf of users and determine whether the outputs can be verified through its tracer script and blockchain evidence or not.
Then, the team will submit the proof to a second group composed of trusted community members who’ll then validate the claim’s authenticity independently. This additional layer of checks and balances is required to inject more confidence into the process and reassure the community that no output gets reactivated without sufficient authenticity proof.
If one of the participating community members spots odd claims being reactivated, their task is to inform the community of their skepticism. If there’s any contested set of outputs, it will need to be pushed as an independent CCS proposal.
Any output validated by both the team and the community group will then be included in a whitelist and re-enabled as soon as the upcoming hardfork occurs.
Note
Any user facing a rejected claim can, on their own, prepare a CCS proposal and plead their case to the community. In that sense, this proposal does not seek to give full authority of the claim process to the Particl team but rather ease and facilitate the process for the vast majority of users by reducing their burden.
How to Submit a Claim
To submit a claim, follow these steps carefully.
After you submit your claim, the team will receive it and try to validate it. The team will then submit the evidence of the authenticity of your outputs to the community group tasked to verify the team’s findings. Once that process is complete, you’ll then receive an email confirming whether it’s been approved or not.
If your claim is rejected, you will still be able to plead your case directly to the community by creating a CCS proposal. In that proposal, you may have to provide additional information to convince the community that your claim is valid. What information is provided (i.e., transaction history, proof of purchase, etc.) is up to you.
Note 1
If your outputs can’t be verified using the tracer script developed for that specific purpose, you may receive an email asking for additional information. What other additional data may be required will be determined on a case-by-case basis.
Note 2
If you have already submitted your outputs by email, you currently don’t need to do anything. The team will verify your claim and reach back to you if any additional information is required.
Key Points
The benefits of this proposal are many:
You wouldn’t have to publicly provide personal, financial, or blockchain information (better privacy).
You wouldn’t have to worry about whether or not stakers will validate your claims even if you can fully prove your outputs’ authenticity.
You wouldn’t have to spend valuable time creating a proposal and convincing the community of the authenticity of your claim.
Delegating the output verification process to a smaller and more streamlined group of managers will ensure a faster resolution and return to normal, after which the project will be able to move forward.
Timeframe
This proposal will be opened up for discussion for the next few days, after which it will move to the voting phase. How long it will remain in that phase mostly depends on the volume of comments and discussion.
There will be a set deadline for you to submit your outputs. Failure to submit outputs within that deadline will result in your outputs not being included in the next hardfork. You will still be able to submit outputs after this time, but if they get validated, they will be re-enabled whenever Particl does another hardfork.
The deadline for submitting your outputs will depend on a few factors (i.e., the volume of submitted claims) but will be clearly announced a few days or weeks before. We recommend that you submit your claim as soon as you can and don’t wait too long for it.
Parties Involved
From the Particl team
Community Group for Proof Verification
Note
The management and validation of claims is provided as an entirely independent initiative. It is not related to any official Particl Foundation or team contribution but is done voluntarily by individual people.
AMA/FAQ
If you have any questions regarding this proposal, the process of claiming disabled outputs, the vulnerability itself, or the solutions put in place to move forward, please visit the AMA/FAQ post currently stickied on Particl’s sub-Reddit and post it there. A member of the Particl team will be answering your questions which will double the thread as an FAQ resource for other people with similar questions.