Thank you for you answer. I will reply to your reasonable points soon.
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.
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
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.
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
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)
1 Like
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:
- reputable proves their reputation to the oracle and specifies their DASH account
- 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)
- 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)
- DASH delegates vote on the amount of dividend D to be paid out
- 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
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?
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
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.
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.
@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
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.
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 $
At the end of the logs, what is this?
Finished dev [unoptimized + debuginfo] target(s) in 18m 12s
Runningtarget/debug/examples/get_storage
thread ‘main’ panicked at ‘calledResult::unwrap()on anErrvalue: Client(I o(Os { code: 111, kind: ConnectionRefused, message: “Connection refused” }))’, e xamples/examples/get_storage.rs:43:54
note: run withRUST_BACKTRACE=1environment variable to display a backtrace
620K ~/encointer/rust/substrate-api-client
- Is there an error in the code here?
- Do I have to run rust as root in order for the client to connect? Does this error occur because I cannot sudo?
- 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
Runningtarget/debug/examples/print_metadata
thread ‘main’ panicked at ‘calledResult::unwrap()on anErrvalue: Client(Io(Os { code: 111, kind: ConnectionRefused, message: “Connection refused” }))’, examples/examples/print_metadata.rs:29:54
note: run withRUST_BACKTRACE=1environment variable to display a backtrace
620K ~/encointer/rust/substrate-api-client
00:55 demo<0>apogee 101 $
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
- 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?
- In which node do I have to connect for the above cli command to work?
- 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.
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
1 Like
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.
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?