Protecting a member's anonymity while allowing them to build up reputation

[Ben]

As I’ve been working on the specific implementation details of how our prospective users will be able to submit custodial or motion proposals, I’ve come across a series of “interesting” considerations.

To try to figure out if we have all the tools we need, I made a list of the starting point requirements that occurred to me while researching the topic:

1. A community member should be able to be as anonymous as they would like to be.
2. A member will need to call on existing reputation within the Nu community to assuage any doubts that the community has about the validity of a proposed motion or custodial grant request.
3. A proposed motion or custodial grant request needs to be structured in such a way that other community members (specifically holders of NSR with the ability to vote) will be able to confirm that the member who submitted them is who they say they are.
4. Previous proposals – whether they were passed or did not pass – should be capable of being connected to future proposals. This will allow the member who is bringing the motion or grant proposal to the table to leverage their previously gained reputation to inform the community’s ability to make a decision.
5. There should be some “cost” associated with developing a public identity to prevent users from abusing the process. This cost does not need to be financial, but should be something that is difficult to reproduce or spoof.

I do not expect that this list is inclusive, so I’m very interested in hearing from the rest of the team. If you have items that you believe should be on the list, or disagree with anything I presented above, let’s discuss them.

There is likely a technical solution that is out there that we should consider. This may be the implementation of a pre-existing solution, or it may require stand-alone development to either integrate directly into the Nu protocol, or to work as a separate tool (similar to how we use BitMessage outside of our other communication channels).

[desrever]

There should be some “cost” associated with developing a public identity to prevent users from abusing the process. This cost does not need to be financial, but should be something that is difficult to reproduce or spoof.

Let’s see what has been done similarly in other contexts :
TX fees also avoid having the blockchain flooded with useless transactions. Similarly, on IOC DDNS system, you need to pay a fee to register a username<—>address alias.

We would probably benefit if also submitting a custodian proposal had a cost. Think about a bad guy who will keep NSR holders distracted by submitting several useless but very long and complex proposals.

I’m not saying that a fee is the best solution, but for sure is deterrent.

[Ben]

I/OCoin’s DDNS is certainly an interesting system, and I would be interested in running a trial on their block chain to see how it works. If it appears to be a solution that could be repurposed, we could then investigate the level of effort required to adapt it to work within the Nu protocol, of to integration components of it into the protocol and then into an extension that can be placed on sites like discuss.nubits.com (and other Nu-related web properties).

Note: The following is stream-of-consciousness and likely has a bunch of “gotchas” that would make it challenging to implement, but I felt it was enough of an idea to stimulate discussion… read at your own risk.

Regarding a fee for proposals, is there any value in discussing a protocol update that would introducing a “burn” address that a prospective custodian can send NSR to? Once the required amount of nushares are sent to the address, a response is provided that only can be “unlocked” by the NBT address that the custodian has indicated will be the one used to deposit granted nubits into if the proposal successfully passes the shareholder vote.

This “unlock key” can then be included in the body of the proposal, and prospective voters can use their Nu client to check the validity of the key to prove that the proper amount of nushares have been burned, and that the corresponding NBT address is, in fact, accessible to the person or organization introducing the proposal.

If a person or organization cannot afford to fund this “unlock,” because they do not have enough nushares to accomplish it, I could envision a situation where someone else could introduce the proposal on their behalf (by paying the fee and using one of their NBT addresses to generate the unlock key). The ability to ask someone to act as a “guarantor” for a proposal will undoubtedly introduce a number of benefits and determents to the system, so I expect that if it was an idea that the shareholders are interested in researching more, I suggest we set up a separate panel to study the possible outcomes.

[Cybnate]

Risked reading it. I think I see what you are trying to achieve but I have not enough information about the current NBT issuing process to assess all the benefits. So I will need to find this out first.

Gut feel says it put some assurances in place which are not there.

[desrever]

I see a lot of value of having such protocol change.

introducing a “burn” address

However, I would love to see NSR dropped to some cause/bounty/fund rather than burned.

a response is provided that only can be “unlocked” by the NBT address that the custodian has indicated will be the one used to deposit granted nubits into if the proposal successfully passes the shareholder vote.

which kind of response? I don’t get it, how can a tx have a response ? in the form of a “change”?

This “unlock key” can then be included in the body of the proposal, and prospective voters can use their Nu client to check the validity of the key to prove that the proper amount of nushares have been burned, and that the corresponding NBT address is, in fact, accessible to the person or organization introducing the proposal.

Good thinking, we can elaborate more here but the concept is "Prove to the rest of the world that
a) the alleged prospect custodian has access to the public NBT address of the future grant
b) he/she is not a spammer* as he/she is willing to invest/burn some money to have other shareholders reading his proposal . (*well, or a spammer with money to loose or interests to defend)

suggest we set up a separate panel to study the possible outcomes.

I’m interested. When you say panel, what do you mean exactly?

[Ben]

However, I would love to see NSR dropped to some cause/bounty/fund rather than burned.

This would be preferred, if it were possible to enforce. The “benefit” of a burn address is that it is verifiable. If NSR were moved instead to an address that could be subverted (which it always would be, being under control of someone), there is always the spectre of fraud. Here’s a fringe case, but one that I believe is realistic:

• Alice is selected by the community to manage the bounty program.
• “Donated” (aka “burned”) NSR go into one of the addresses held by the bounty program coordinator.
• Bob wants to submit a proposal. For the size of the NBT grant that is going to be requested, the donation cost will be 120,000 NSR.
• Bob and Alice come to an off-line agreement that for 25% of the amount that it will cost for the proposal, Bob will be assurred a bounty that equals the same amount as the NSR that he is donating.
• Bob submits the proposal.
• Alice announces that Bob (directly, or through a proxy, which is the more likely scenario) has been awarded a bounty of 120,000 NSR to solve some problem.
• Bob sends Alice 30,000 NSR.

Now, is it realistic, yes. Is it useful to either of them? Hard to say. The main point being that there are ways around the cost if they are donated. This doesn’t mean that it’s a problem that cannot be solved, ever, just that by taking it out of a binary “destroyed / not destroyed” protocol rule, it complicates things.

which kind of response? I don’t get it, how can a tx have a response ? in the form of a “change”?

I wasn’t sure. In my mind I envisioned some sort of “token” that was generated once I submitted the burned NSR. Perhaps a new form of transaction that requires that the NBT address that I plan on using for the custodial grant deposit address to be included.

 payproposalfee <shares_address> <custodian_deposit_address> <fee_amount>

If the protocol became “smart” this may be even easier, because the amount of NSR could be a variable based on the amount of NBT in the custodial grant proposal. This seems like it could be a low priority consideration; there are a lot of variables that would need to be considered, and the community would need to constantly make sure that the protocol fees were in line with the exchange rate for NSR.

I’m interested. When you say panel, what do you mean exactly?

By “panel” I meant a group of people (or the entire community, if they wanted to participate) could set up a separate topic just to discuss this concept. From there, the technical requirements could be generated, a NEP proposed, bounties assigned, and development can then follow.

[desrever]

If NSR were moved instead to an address that could be subverted

very true. Let s say there is a public NSR address that holds a charitable funds of some kind where people already put their trust (and funds before) . A well known public address, multi signed. a Nu Seans Outpost. No bounties involved.
Would the scenario you depicted change somehow?

[Ben]

Light reading on the subject of using “proof-of-burn” : https://blog.openbazaar.org/why-proof-of-burn/

[desrever]

Very interesting read to keep in mind is this : http://www.reddit.com/r/Bitcoin/comments/2g5qqq/frozencoin_a_concept/

And we happen to already have the tool to make it happen… Parking Nubits!

What if, in order for a proposal to be considered, we ask the prospect custodians to park a certain amount of NBTs ?

1. it will put some buy pressure on NBT,
2. it won’t be felt as burning money
3. it will discourage scams and make it expensive to cheat while allow honest people to do it for free

[Ben]

As I was thinking about this further, I realize that restating the problem gave me additional insight.

At the core this effort should be to develop a way to assign credit worthiness to someone who prefers to be anonymous.

Is there any branch of study in cryptography that has introduced a way of mathematically verifying an account balance matches or exceeds some value, while keeping the value itself completely undiscoverable by the party who initiated the query?

[Cybnate]

I think this is the holy grail assuming centralisation is not acceptable.

Currently it would require a piece of mutually trusted and encrypted code running somewhere in a trusted environment. E.g. decrypting (with shared keys), reading and calculating and responding only with the type of results required without providing all the details. Only the bot knows the details for a short while. Big disadvantage is that this require centralisation…

Hope someone has found some advancements in this space. That would be a breakthrough imo.

[Ben]

Nick Szabo had a lot of thoughts on this very topic back in 1993.

http://cypherpunks.venona.com/date/1993/10/msg00759.html

[desrever]

the more I learn about nick szabo, the more I am convinced .

[Cybnate]

A real visionary, like that other guy building blocks… yes.

[Ben]

Bump for a new possible option: http://blog.onename.io/the-openname-protocol/

[Cybnate]

I couldn’t find attributes where you can actually build reputations with. Say references from trusted others, work done confirmed by others, recommendations from others etc.

[henry]

Great discussion. I would like to see this discussion continues.
May be adding message function into Nu is the first step.

[masterOfDisaster]

I/OCoin’s DDNS is certainly an interesting system

If you find that concept interesting and want to look for an implementation of other DDNS systems, you might want to look at Emercoin, specifically here: http://emercoin.com/DNS_and_Name-Value_Storage
I’ve not looked at I/OCoin, but I know that Emercoin is a Peercoin fork and hence based on PoS; maybe it is easier to lean on Emercoin’s code in case there’s something useful