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

[demo]

@brenzi

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.

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.

@brenzi

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.

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.

[brenzi]

@demo

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.

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

[brenzi]

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

Go to js/apps to fetch chain state:

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)

[brenzi]

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

[demo]

@brenzi

@demo

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.

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 people 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.

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?

[brenzi]

@demo

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?

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

[demo]

@brenzi

@demo

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?

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. 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

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.

[demo]

@demo

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.

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.

[brenzi]

@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?

[demo]

Thats great!!!

I will try to incorporate the code in the “get info” button of the numerical proposal.

I think I have to setup an encointer node in apogee.dynu.net, in order to run the cli.
Let me see about it. It seems that the cli is written in rust. I will ask the masternode owner who owns apogee.dynu.net. I believe he will agree to install a code written in rust in apogee, because rust is considered a relative safe language. Unless of course I can install rust without root priviledges, in that case I can do it myself.

But in general , the less I will install in apogee, the better it is. So If you have a solution where I can run the encointer CLI by installing the minimum required, or even better by installing nothing, that will be great. I also remember you told me that there is a cli client written in python. Do I remember correctly?

I will inform here about the progress.

[demo]

I installed rust in apogee (without root priviledges)

Then I tried to compile substrate-api-client.

rustup show
git clone https://github.com/scs/substrate-api-client.git
cd substrate-api-client/
cargo run -p ac-examples --example get_storage

Look at the logs below

21:52 demo<0>apogee 0 $ cargo run -p ac-examples --example get_storage
info: syncing channel updates for 'nightly-2023-05-22-x86_64-unknown-linux-gnu'
info: latest update on 2023-05-22, rust version 1.71.0-nightly (9d871b061 2023-05-21)                                              
info: downloading component 'cargo'
info: downloading component 'clippy'

bla
bla 
bla

Compiling kitchensink-runtime v3.0.0-dev (https://github.com/paritytech/subst                                                       rate.git?branch=master#55bb6298)
Building [=======================> ] 685/688: kitchensink-runtime(build)
Compiling ac-examples v0.4.0 (/home/demo/encointer/rust/substrate-api-client/                                                       examples)
Finished dev [unoptimized + debuginfo] target(s) in 18m 12s
Running `target/debug/examples/get_storage`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Client(I                                                       o(Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }))', e                                                       xamples/examples/get_storage.rs:43:54
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
620K ~/encointer/rust/substrate-api-client
22:11 demo<0>apogee 101 $

[demo]

At the end of the logs, what is this?

Finished dev [unoptimized + debuginfo] target(s) in 18m 12s
Running target/debug/examples/get_storage
thread ‘main’ panicked at ‘called Result::unwrap() on an Err value: Client(I o(Os { code: 111, kind: ConnectionRefused, message: “Connection refused” }))’, e xamples/examples/get_storage.rs:43:54
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
620K ~/encointer/rust/substrate-api-client

1. Is there an error in the code here?
2. Do I have to run rust as root in order for the client to connect? Does this error occur because I cannot sudo?
3. Does the error occur because I dont run a node in apogee in the port 9944?

I have to run cargo with another example because the initial command …

cargo run -p ac-examples --example get_storage

… obviously fails in apogee.

I tried the below, and the same above error occurred

620K ~/encointer/rust/substrate-api-client
00:55 demo<0>apogee 101 $ cargo run -p ac-examples --example print_metadata
Compiling ac-examples v0.4.0 (/home/demo/encointer/rust/substrate-api-client/examples)
Finished dev [unoptimized + debuginfo] target(s) in 14.09s
Running target/debug/examples/print_metadata
thread ‘main’ panicked at ‘called Result::unwrap() on an Err value: Client(Io(Os { code: 111, kind: ConnectionRefused, message: “Connection refused” }))’, examples/examples/print_metadata.rs:29:54
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
620K ~/encointer/rust/substrate-api-client
00:55 demo<0>apogee 101 $

[demo]

I will install encointer CLI now. Can I install it without installing ALL the above library?

I would like a CLI with the minimum disc space possible (apogee has limited disk resources), so maybe not all the substrate-api-client library is required.

I now try to compile encointer_node

rustup show
git clone https://github.com/encointer/encointer-node
cd encointer-node/
cd client
encointer-node/client> cargo build --release

More space is required while doing the above. I am afraid I will tottaly run out of disk space…

After doing a necessary “cargo clean” in the substrate-api-client directory I compiled before, I am now in the following situation

152K ~/encointer/rust/encointer-node/client
02:05 demo<0>apogee 0 $ ../target/release/encointer-client-notee transfer //Alice 5GziKpBELV7fuYNy7quQfWGgVARn8onchS86azuPQkFj9nEZ 10000
thread 'main' panicked at 'node URL is incorrect: Client(Io(Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }))', client/src/main.rs:1814:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
152K ~/encointer/rust/encointer-node/client
02:07 demo<0>apogee 101 $

152K ~/encointer/rust/encointer-node/client
02:08 demo<0>apogee 0 $ ../target/release/encointer-client-notee -u wss://kusama.api.encointer.org -p 443 list-reputables -v
thread 'main' panicked at 'internal error: entered unreachable code: Bad help structure (doesn't match with path)', /home/demo/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-nested-0.4.0/src/lib.rs:343:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
152K ~/encointer/rust/encointer-node/client

1. Does the above error occured because I had to clean the cargo of the substrate-api-client library because I run out of disc space?
2. In which node do I have to connect for the above cli command to work?
3. Do I have to setup a local encointer node in order to test the cli? how?

any ideas?
Forgive me for my questions, but It is the first time in my life I mess with rust.

[brenzi]

this is not the right thread for rust support. may I ask you to take that to our element chat? https://matrix.to/#/#encointer:matrix.org
(and please use gist or the like for long logs, hard to follow the discussion otherwiese)

For a start, please take our binary release: Release 1.4.1 · encointer/encointer-node · GitHub
download encointer-client-notee binary (14MB ok?) which is know to run on ubuntu 22.04

then, follow our tutorial Basic CLI usage - The Encointer Book

and finally run list-reputables:

> nctr-k list-reputables

[demo]

Ok, I succesfully compiled the encointer node.
I just needed to clear the cargo cache and recompile.

152K ~/encointer/rust/encointer-node/client
11:48 demo<0>apogee 0 $ ../target/release/encointer-client-notee -u wss://kusama.api.encointer.org -p 443 list-reputables -v
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

Thanks for the help, I have the cli now, so I can continue my work for the “get info” button.

[demo]

Ok…The problem of “get info” button has been routed to a solution.

The next thing we have not thoroughly discuss yet is how the encointer members create a dash address in order to claim their dash dividend.

If we want the Dash masternodes to vote in favor of the Encointer Basic Income, we have to convince them that the encointer reputables are also active members of the dash community.

(and of course we have to advertise encointer community to the dash community, so that the dash masternodes will participate to encointer meetings, they will receive the dividend they voted for, and thus they will be convinced that their vote is not in vain).

For example, this encointer member:
Subscan | Encointer Account Detail: 5FbSE4RZC2yF2iJSr7JMUvpZTKAVgfkwUacCKGDYpPbrx2gW

Will he cryptographically sign a Dash address with his encointer address?

Any idea on how we can implement this?

[demo]

@demo

Will he cryptographically sign a Dash address with his encointer address?

Any idea on how we can implement this?

I think I should start investigating GitHub - encointer/encointer-wallet-flutter: Encointer mobile wallet flutter implementation and propose a solution there.

Of course a generic solution must be implemented there, a solution that will be able to support in the future more cryptos that may want to offer a UBI to the encointer members.

The Dash community hopefully will be the first that will start fixing their initial time-space asymmetry in their money distribution. But lets also hope that other governed universal cryptos (like polkadot, decreed or any other coin that can be governed) will follow that road and will accept to partially fix their own time-space assymetry problem too, by voting the numbers on how drastic this fix will be.

The only way for a coin to be accepted in the future, is to respect the future generations and have a plan on how these future generations will also be able to participate to a fair money distribution. Otherwise the future generations will create their own coin, and the old coins that were based in this injustice will be ignored and perish.

call to all new dash members. Do not accept the old guard confiscate all coins | Dash Forum

[demo]

As the main page where all masternodes will be redirected in order to vote the numbers, I propose to be this → https://tinyurl.com/encointerUBI
(unless you prefer https://bit.ly or even the altenative possibility someone to buy a domain name)

If you have any suggestions on how this central encointer UBI page (its goal is to facilitate the masternodes to vote the numbers) can be improved and become more attractive, please leave a comment here.

[demo]

Below the text that is written in the Dash proposal https://tinyurl.com/encointerUBI. If you have suggestions or improvements, you are welcome. The proposal is not online yet.

Every cryptocurrency, after having a burst due to early adopters, it slowly declines because the new generations have no incentives to join it. The basic income is a smart method to fix the injustices of the coin emission curve and to incentivize late adopters to join a cryptocurrency and thus keep the coin alive. But in order to give a basic income a strong proof of personhood is required. The Encointer community implements a unique proof of personhood mechanism that combines strong identification and anonymity. In this proposal the masternodes invite the Encointer community to join the Dash community. The Encointer communities are mainly local communities and are using local cryptocurrencies, but they also need a universal currency for their international exchanges. By offering them a basic income paid in Dash in their Dash addresses (all Encointer members are required to open Dash addresses in order to get their Dash basic income) we make the Encointer members also Dash members and we incentivize them to use the Dash crypto as their medium of their international exchanges. Dash becomes that way an early adopter as the universal coin that will be used by the Encointer community. Any Dash member is free to participate to any Encointer meeting and thus examine their procedures. We strongly recommend the masternodes to participate at least once in any local Encointer meeting, in order to receive their basic income and find out that their vote is not in vain.

This proposal will remain in the budget for 24 months, asking for a basic income every month. Depending on the masternodes’ participation in this numerical vote, a monthly yes/no proposal may be added at the next budget cycle, asking for the average of all the numerical votes of the previous month to be paid as basic income. You can change your numerical vote at any time during these 24 months, in order for it to better adapt to the growth of the Encointer community.

How many Dash would you like to be offered the next month as Basic Income for the entire Encointer community ? (a vote from 0 Dash to 242 Dash)
The (decimal) number I would like to vote is:

[brenzi]

I’ll reach out to our product team, how the UX shall work to obtain a DASH wallet with minimal friction and without being specific to DASH.