How Local Digital Currencies Are Created and Governed by Their Communities

Table of Links

Abstract and I. Motivation

II. Local Currencies

III. Unique Pop Ceremonies

IV. Monetary Policy

V. Purchasing-Power Adjusted Transaction Fees

VI. Architecture

VII. Trusted Execution Environment Security

VIII. Encointer Association

IX. Known Limitations

X. Conclusion and References

II. LOCAL CURRENCIES

Encointer is no single currency. It manages an unpermissioned set of many local currencies. Every geographically bound community can have their own local currency.

\ A. Bootstrapping a Local Currency

\

\ Then the initiators need to perform a trusted setup ceremony with 3-12 participants. An Encointer local currency should only be trusted if it was bootstrapped with a public trusted setup ceremony. In the best case you find locally renowned people to participate in the first ceremony. For the trusted setup it is recommended that public keys used for the ceremony are made public by their owners.

\ The currency’s identifyer Ck is the group public key of all registered trusted setup participants.

\ B. Urban Scalability

\

\

III. UNIQUE POP CEREMONIES

\

\ \ The registration data is transferred and stored confidentially to mitigate linkability across ceremonies.

\ B. Assignment

\ \

\ \ 1) Computational Complexity: Rules 1, 2 and 3 form an np-hard optimization problem. Therefore, the assignment has to be performed off-chain.

\ C. Meetup Procedure

\ \

\ \ D. Witnessing Phase

\ \

\ \ E. Validation

\ \

\ \ F. Reward

\ All participants who passed the validation above are issued an amount of RC as a universal basic income. RC can be defined and adjusted per local currency by means of on-chain governance.

\ G. Unique Proof-of-Personhood

\ Attending one meetup supplies the individual with a simple proof-of-personhood (PoP). However, it doesn’t prove that one individual maintains exactly one PoP over time. The more subsequent ceremonies an individual attends, the more trustworthy is his/her Unique-PoP (UPoP) claim with respect to uniqueness.

\ H. Threat Model

\ The Encointer UPoP protocol needs to defend against two categories of adversaries:

\ • those who try to get more than one reward per ceremony (sybil attack)

\ • those who try to sabotage the Encointer ecosystem even if this comes at a cost.

\ Both categories will collude among themselves to achieve their goal.

\ Hypothesis 1: The Encointer UPoP Protocol is secure if a majority of participants with reputation for each ceremony and each meetup is honest and successfully registers their nonempty attested claims to the blockchain in time.

\ Above hypothesis as not formally proved here. We expect to get probabilistic security with regard to the following attacks:

\ 1) Illegit Videoconference: People may try to meet virtually instead of physically. Mitigated subject to Hypothesis 1

\ 2) Surrogates: An adversary might pay other people to attend ceremonies on behalf of identities controlled by the adversary. The effect is similar to people renting out their identity. This attack is out of scope as it doesn’t affect issuance.

\ 3) Oversigning / Social Engineering: Attendees might talk others into signing more than one pseudonym per person. Bribery could happen too. Mitigated by rules 7 and 9 subject to Hypothesis 1

\ 4) Systematic No-Show: a meeting might become invalid if too many participants don’t show up (deliberately). Mitigated subject to Hypothesis 1

\ 5) Flooding: An adversary could register large numbers of fake participants who will never show up. This could prevent legit persons to participate. Mitigated by rule 3.

\ 6) Threats to Personal Safety: As ceremony members need to meet in person, all risks involved with human encounters apply. These risks are reduced by randomizing participants and by the minimal group size of 3 persons. Participants are advised to choose public places for ceremonies. Threats by non-participants who want to hurt the Encointer ecosystem by attacking participants are mitigated if group s keeps their exact meeting point private.

\

:::info Author:

(1) Alain Brenzikofer ([e-mail]).

:::

---

:::info This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license.

:::

\