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?
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?
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
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)
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).
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.
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.
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:
I am ready to post the proposal , my plan is to post it in 6 days from now, after the end of the current Dash budget cycle. Look at it:
I think it will be better to first code a quick and dirty solution for Dash integration into the Encointer wallet, because Dash is currently the only coin you have a (tiny?) hope that it may offer to the Encointer community a basic income. And then you have plenty of time to code a generic solution.
If your child is hungry, what do you do? Do you solve the world’s hunger, or do you search a quick and dirty solution in order to feed your child?
If I post the proposal without for you to have implement a Dash intergration into the Encointer wallets, the proposal has more chances to fail. The proposal will also fail if there is no excitement in both the Encointer and the Dash communities, and the excitement for every formed community seems to first burst, then diminishes and then it may stabilizes. If we are still in the excitement period, the diminishment period is about to come, so we may have to hurry.
Buddha said: “The trouble is, you think you have time.”
the most quick-and dirty I can think of which will still provides nice UX is this:
I think we can do this reasonably soon, but certainly not within 6 days. I’ll revert with a timing.
If it needs to be 6 days, we can just write a tutorial, how people create a dash wallet and sign a message with a cli client. That will not yield more than a dozen people, but would be very quick
I will post the proposal in 6 days and we will see the reaction of the masternodes.
If it is negative, then you do nothing in your Encointer wallet.
If it is positive, then until the end of the budget cycle (a month), preferably after 14 July, you have to present to the masternodes a beta version of the Dash intergration into the Encointer wallet.
This is because most of the masternodes tend to vote at the end of the cycle, so after I post my proposal we have about a month to convince them.
I think this is the best we can do, and it will save time and resources of the encointer community, in case the masternodes finally reject the basic income proposal tottaly.
In order for a yes/no Dash proposal to pass, we must have 10% of the masternodes to agree with it. If there are also disagreements, we need the agreements - disagreements to be 10%. In our case, because it is a numerical vote, we count the zero votes and we compare them to the votes that are not zero. That way we have an image on whether the upcoming yes/no proposal has chances to pass.