An attempt to establish a similar system to Dash cryptocurrency in 2017

Encointer Global
#4

The proposal will ask a portion of the Dash Budget (4592 Dash per month) to be given to the Encointer community.

How much this amount will be, I suggest it be a voting issue, masternodes should be allowed to vote the numbers on that.

The proposal fee is currently set to 1 Dash per proposal. If we dont ask a fixed portion from the budget and we allow the masternodes to vote the numbers about the basic income that will be offered to the Encointer community, we will need at least 3 proposals + 1 proposal for the confirmation of the voted number (total 4 dash).

1 Like
#5

Also another difference between the Encointer’s system and the Dash’s proposed system, is that the basic income does not refer to a local coin (or to a local circular economy), but rather to a global coin. It refers to a global coin that is already active in the market and has value, it refers to a global coin whose owners decided to fix the initial space-time asymmetry error.

The idea behind is based on Duniter’s space-time asymmetry concept.

Read here or here or here or here or here, for more information.

Beware, in case you decide to transform Encointer’s mission and ask to the polkadot-kusama coin to fix their own space-time assymmetry error. You may end up banned , like me in dash.

So you have better ask other coins to fix their space-time assymetry error by funding Encointer community (you may ask it from the Dash treasury as I proposed you, the Dash community has a 7 years preaching history and may be more receptive to the idea of fixing their space-time asymmetry).

Encointer’s survival currently tightly depends on polkadot-kusama council who may reject and cease encointer community, in case you start talking to them about space-time asymmetry issues.

#6

Thank you for reaching out to our forum. You have posted a lot of content which I still need to wrap my head around. Let me just answer selectively - for now - to just what caught my immediate attention:

  1. It seems like your motivations are aligned with ours. Dash does work differently than Polkadot but in terms of inequality (in the present and inter-generational) they face the same challenges. Encointer aims to provide an answer which works fundamentally different than existing cryptocurrencies and has redistribution built in to approach equal opportunity
  2. You ask if DASH could supply a sybil-resilient dividend to humans participating in Encointer communities. Short answer: absolutely! We are currently working on:
1 Like
#7

Thank you for your answer!

Exactly that. I think we share a similar vision.

Thats great!

Dash crypto bridged to your faucet is a really great idea!
I can help you implement that, because I have some knowledge of the dash technology.

On the other hand I suspect that the Dash community (if they decide to embrace the Encointer community and give a basic income to you), they will give more dividend in case the Encointer community members hold Dash wallet addresses (in parallel to the polkadot-kusama wallet addresses).

This could be implemented by allowing every Encointer member to sign (by using his/her kusama-polkadot address) a unique dash wallet address that will be used as their dash proof of personhood.

Thats great! This seems similar to what I said above ( to sign the Dash addresses by using your kusama-polkadot addresses)

ils croient,
ils voient,
ils boivent.

#8

So the plan is

  1. You provide a list of dash addresses, signed by the kusama-polkadot adresses of the Encointer members
  2. I cast a never ending BASE3 proposal in the dash budget system. Look here Vote The Numbers - BASE3 (mnowatch.org)
  3. At the end of every dash budget cycle, we check whether we have enough participation in our numerical voting.
  4. If we have enough participation, and if a number appears votable according to the decision method we choose (majority, most voted option, median, mean), then in the next budget cycle we cast a “yes or no for the decided number of the previous cycle?” proposal.
  5. If the yes/no proposal passes, we distribute the basic income to the dash addresses of the Encointer members.

What do you think? Ideas? Suggestions?

#9

I think on the technical side, there’s a very clear way forward with a few design choices yet to be made.

Before we go there, I’d like to establish what the goal of this partnership is for each stakeholder. Let me sketch my view on it:

Stakeholders

  • DASH ecosystem: aims to reduce early-adopter bonus by (re)distribution of DASH to provably unique humans. This promotes inclusivity and may onboard an entirely new audience
  • Encointer network of local communities: may benefit from additional incentives to start/join/grow communities
  • individual member of an Encointer community: Benefits financially from the DASH dividend - on top of the income issued to them in local community currency.
  • Kusama & Polkadot ecosystem: lending it’s security to the Encointer network (Common-good Parachain): may benefit from collaboration with the DASH ecosystem

Side Effects

While the Encointer association (which I represent here) has no way to prevent anyone form granting DASH dividends to members of Encointer communities, we have to consider the possible undesired impact of such a dividend should we be actively involved. Above, you suggest 4592 DASH for all Encointer community members. This today is more market value (~200k$) than the current market cap of all Encointer communities combined (~40k$). This means we would create a significant incentive to join or create communities where the local community currency is just a byproduct and may get no attention at all (no real value from acceptance points will be backing the currency).

This - by itself is no show stopper as it still contributes to some of our goals, i.e. the basic income/dividend.

One caveat may be that existing communities have no incentive to support new communities (or inviting new members within their own community) because they would have to share the dividend. Such a counterincentive could cripple the Encointer network as a whole. This could be prevented if we could define a per-capita dividend to be distributed instead of a fixed amount.

But more importantly, we need to be very careful about the security assumptions of our sybil-resilience mechanism: We assume the majority of a community to be honest. This assumption is realistic if the pains of cheating are felt and observed within the community itself: A community currency which can be cheated will just lose its value and disappear because the stakeholders can themselves observe the cheating happening and no one will accept that currency for payment. However, with the main driver being a community-external incentive, I’m concerned about this assumption because the giving party (DASH network) can’t really observe the honesty of all receiving communities and their members.

IMO, the proposed setup conflicts with Elinor Ostrom’s rules for managing the commons, specifically these rules:

4. Commons must be monitored. Once rules have been set, communities need a way of checking that people are keeping them. Commons don’t run on good will, but on accountability.
5. Sanctions for those who abuse the commons should be graduated. Ostrom observed that the commons that worked best didn’t just ban people who broke the rules. That tended to create resentment. Instead, they had systems of warnings and fines, as well as informal reputational consequences in the community.

1 Like
#10

Alternative approach: Community Treasuries

Instead of distributing a stash of DASH to all members of Encointer communities, we could consider to back community currencies with a DASH reserve.

Encointer features democracy, therefore a community could jointly hold a treasury with foreign assets (i.e. DASH) and the community could democratically decide how to use the treasury funds. In practise, this could serve as a security for acceptance points who may in the beginning accumulate CC and take a lot of risk.

In Zurich, for example, acceptance points have jointly founded an association that aims to further economic cycles and may de-risk individual businesses. Such an association could be a candidate to claim treasury funds.

Caveats

While this approach doesn’t suffer from false incentives for individuals of honest communities, it still incentivizes collusion: Creating fake communities to get DASH

Currently, this risk is minimal because the Encointer association acts as an authority on who may start a new community. But - in the spirit of decentralization - the network has to transition to an unpermissioned web-of-trust. And there, the above is a risk

1 Like
#11

Thank you for you answer. I will reply to your reasonable points soon.

#12

Let me answer to your above quote first, to clear the misunderstanding.

I am not suggesting 4592 Dash for all the Encointer community members. I am suggesting for the Dash masternodes to vote the numbers and decide what the dash basic income for all the encointer community members should be. A number between minimum 0 dash and maximum 4592 dash.

So 4592 dash is the best scenario, there is also the worst case that is 0 dash. And we have all the numbers in between. The decided number, that will be voted every month by the mansternodes, MAY PROBABLY VARIES EVERY MONTH. The monthly decision of the masternodes on how much dash will be given, depends on the number of individuals that participate to the encointer community and on the trust the masternodes have that the encointer community operates according to the specification and does not cheat.

In order to understand how “vote the numbers” works, look at the application I created here, or look here for the outcome of 4 proposals that are assumed to be numerical ones (they are not, but just for the sake of the example).

"Vote the numbers" is not a technology directly supported by the dash core team (although the main developer of Dash is a proponent of it). It is rather an add-on that I created, an add-on that can easily fit not only to Dash but also to any other coin that is governed by yes/no type proposals or referendums. This add-on fits even to the governed coins that have not implement yet any “vote the numbers” solution (like dash), it fits even to the governed coins that their core team strictly refuses to implement a “vote the numbers” solution but their community members strongly desire that.

The basic idea is, if you allow someone to vote a yes or a no, this person can also vote all the numbers, at the cost of many proposals. Because yes/no is similar to 0/1 (or 1/0 depending on the defined semantics), so we can use the binary numerical system.

In dash the masternodes are allowed to vote yes/no/abstain, so we have a base3 number voting system. Dash masternodes can also be allowed to vote by using the base4 voting system, you can look at the relevant app I created here. The explanation of the theory about “voting the numbers” is here.

I never write complete articles, I prefer to talk to forums. So if you want a summary of a similar to mine idea (a close variation), you can also read the article of PIETRO SPERONI.
Let the DAO decide “how much” – Pietro Speroni di Fenizio, PhD

I think “vote the numbers” has been clarified, so soon I will answer to your rest points.

Scaling Encointer fast and globally through staked social vouches
Scaling Encointer fast and globally through staked social vouches
#13

You may also follow (and participate to) the parallel discussion that occurs here.

#14

OK, got that. Still it isn’t a per-capita amount but a variable-amount payment which may happen repeatedly over time and should be distributed evenly to all verified humans of Encointer communities at the time of distribution, right? So much of the argument above still holds IMO.

But let me also state: At our current state, we would welcome such experiments and it can’t hurt to have additional incentives to participate in Encointer communities while we still have some limited control over the onboarding. We discussed it internally and we tend to support such an initiative.

1 Like
#15

You never know the way the Dash masternodes vote.

But I am afraid the masternodes may not agree to give a Basic income to the encointer community in case the encointer community decides not to reveal the number of the individuals that participate in their meetings.

On the other hand, if the encointer community decides to reveal the number of their participants (and their wallets, preferably dash wallet because this may increase the dash basic income the masternodes are willing to offer), then it is very possible that the vote casted by each masternode will highly depend on the number of persons that participate to the encointer community.

So, indirectly through the masternodes vote, the given amount will actually become a per-capita amount.

Thats great! Lets do the experiment.

I also want the encointer community to grow and succeed.

I was always waiting for such a community to appear, and I am very glad that I discovered you.

#16

The number of attested persons per community is public information: See our explorer. Click on one of the communities and check the “number of reputables” number. However, we need to talk about how this number comes to be: It is the number of accounts who have been attested at at least one of the last 5 cycles. This number won’t be safe to use for distribution of DASH: A single attendance should only qualify for a single payout, otherwise you can sybil-attack with 1+4 sybils (the attacker could attend 5 times in a row, but with different accounts). The way we propose to do it is by tracking which proof of attendance has been used already to claim DASH. And that’s how our personhood oracle works. Morever, this oracle improves privacy as there is no linkability between the encointer account with reputation and the dash account receiving the dividend. Users enjoy k-anonymity with k being the number of beneficiaries per payout run (with the same reputation rating, to be precise).

Therefore, I think we should not just sign dash accounts with the encointer account. IMO, the oracle mentioned is a superior solution because of privacy and it also solves tracking of “burned” reputation, thereby improving sybil-resilience

1 Like
#17

Here’s how you can fetch the number of attested persons per community and per cycle:

Go to js/apps to fetch chain state:

image
image1827×797 129 KB

this will give you a list of all accounts with a proof of attendance at the respective cycle index and the specified community (VerifiedLinked and VerifiedUnlinked are equally valid. The difference is an internal thing)

1 Like
#18

Still, this will only give you the maximum number of human attendances H which might apply for a DASH dividend. I don’t think it makes sense to distribute the dividend to all accounts as they may just lay around unused forever. I’d favor an active act of claiming DASH by the users. Such a claim could look like this:

  1. reputable proves their reputation to the oracle and specifies their DASH account
  2. oracle signs a certificate about that DASH account saying “has attended X/5 recent cycles and hasn’t used these attendances to claim DASH before”, signed by the oracle’s remote attested key (proving it’s a genuine TEE, executing the expected service)
  3. DASH dividend system (DDS) counts the number of certified attendances N (payout should be by attendance, not by human) and presents this number to their voters (it may be interesting to show them the total number of reputables H too)
  4. DASH delegates vote on the amount of dividend D to be paid out
  5. DDS pays out D/N for each attendance to the respective claiming DASH accounts

On UX: This process has to be lean and simple for the reputable user. Therefore I’d suggest we support it in our Encointer Wallet mobile app directly (i.e. using this planned feature), with a recommendation on a super simple DASH mobile app and maybe a companion web-service that helps connecting the two and the oracle

1 Like
#19

I dont fully undestand what you have just said.

Every month the dash masternodes will be asked whether they accept the decided/voted Basic income amount of the previous month to be shared to all the reputables/attested persons of the encointer community. We cant do otherwise, thats the limitations of the dash budget system. When the Dash platform (also called dash evolution) will be released (we are waiting for it 5 years!!!) we may bypass the limitations of the budget, we may also be able to vote the numbers directly without base3 or base4 numerical systems. But unfortunately currently this is all that we have, and we have to live with it.

So the dash basic income will be a single monthly payout, that I assume will be given to the attendees of the latest encointer meeting.

In that case a single attendance qualifies for a single payout, doesnt it?

#20

Encointer cycles happen every 10d and dash payouts are asynchronous every month. The delay of information is not a problem IMO, payouts can happen based on past data. But I suggest to base payouts on attendances as this is the most secure setup, even if it means that one account can possibly attend (and claim) up to 3 times during the period of one month. The factor of 3 will just represent the confidence level in this account’s unique personhood, so it is merited

1 Like
#21

Of coure the more a person attends the encointer meetings, the strongest his proof of personhood is. This is part of the encointer protocol, and it is a correct thing.

But on the other hand, I doubt whether it is a good practice for the encointer community to incentivize persons capable to attend as many meetings as possible. This will mostly attract the unemployed, who will transform the encointer meetings to some kind of paid employement.

I would prefer the unemployed persons to spend their time searching for job or doing something productive for the community, or just enjoy their lives, rather than repeatable attend encointer meetings.

In my similar proposal back in 2017 (read about it in Dash, in Duniter or in Ucoin where it still remains the second most popular thread there!) the concurrent meetings were designed to occur once every 4 years (similar to the elections). And there was no memory of the previous meetings, the new meeting canceled the previous one and all the persons were anonymized again into the ballot box. This was due to the above explained reason, but I now understand your different perspective and point of view.

So you proposed meetings every 10 days, and I proposed meetings every 4 years. Maybe the correct number is somewhere in between. Maybe someday we should ask the encointer community members to vote the numbers about it.

Wie hoch sollte das Gemeinschaftseinkommen sein?
#22

The above of course does not prevent for someone to claim his old voting key, provided he can sign his new voting key with the old one.
And of course the persons who voluntarily sign their new keys with the old ones, are considered by the community as more credible persons.
So in the encointer protocol the credibility of personhood is enforced (the term “credibility” you named it before as “secure setup”), while in my variant the credibility of personhood is voluntary.

#23

@demo our cli PR is ready and will output the following:

Listing the number of attested attendees for each community and ceremony for cycles [39:43]
Community ID: u0qj944rhWE
Cycle ID 39: Total attested attendees: 37 (noshows: 8)
Cycle ID 40: Total attested attendees: 33 (noshows: 9)
Cycle ID 41: Total attested attendees: 34 (noshows: 5)
Cycle ID 42: Total attested attendees: 32 (noshows: 11)
Cycle ID 43: Total attested attendees: 39 (noshows: 7)
Reputables in u0qj944rhWE (unique accounts with at least one attendance) 94
Community ID: dpcmj33LUs9
Cycle ID 39: Total attested attendees: 3 (noshows: 1)
Cycle ID 40: Total attested attendees: 6 (noshows: 0)
Cycle ID 41: Total attested attendees: 5 (noshows: 1)
Cycle ID 42: Total attested attendees: 4 (noshows: 0)
Cycle ID 43: Total attested attendees: 3 (noshows: 0)
Reputables in dpcmj33LUs9 (unique accounts with at least one attendance) 6

Therefore, right now, there are 94+6=100 unique accounts which have attended at least once during the past 5 cycles. My suggestion would be to only reward attendance, not reputation>1. But that’s to be discussed. Therefore, for the last 3 cycles (~1 month), there would be 34+32+39+3+4+5= 117 attendances
We can certainly beautify the output, but basically, these are the numbers you’d need right?

1 Like