Arcurus

Moderators
  • Content count

    717
  • Joined

  • Last visited

  • Days Won

    63

Arcurus last won the day on December 13

Arcurus had the most liked content!

About Arcurus

  • Rank
    Guru

Profile Information

  • Gender
    Not Telling
  • Location
    Planet Earth
  • Interests
    Common Good Economy

Recent Profile Visitors

1725 profile views
  1. Creating Envirocoin

    Layer two: Enforcement of Block reward distribution (Not used coins can be used in the next blocks, but at max 10 coins): 10% to proof of work (Hard) 10% to master nodes / network operators (Hard) 80% distribution to projects according to the vote of the Enviro Nation members. (Hard) (for example: 20% to all projects, 20% to provide liquidity, 20% universal income, at least 20% to investments) (Hard once proofed) One member one vote, organized like a cooperative (Hard) If less funds are available then allocated through projects, funds are distributed according to member count that voted for / against the project.(Hard) Each member must have X coins as security. (Hard once proofed) Other coin holders can pledge if they have excess coins. (Hard once proofed) Groups (Hard once proofed): Members / projects / masternodes are organized in groups of 100, 10.000, 1.000.000, 100.000.000 Groups can be voted similar to members. By default members that do not vote, vote relative to the member group vote. Voting (Hard once proofed) Votes are obsolete after one year. Each member has per category outlined below 10 positive votes and 5 negative votes. To each project, member, etc can at least 2 votes be assigned. Voting on members: (Hard once proofed) Max 10 new members / member groups can be added per month (top voted) Max 10 new members / member groups can be excluded per month (top voted) New members need 10% more positive votes then negative over a one month time period. Members can be excludes if 10% more negative votes then positive over a one month time period. Voting on protocol changes: (Hard once proofed) Max 10 protocol changes can be done per month (top voted) Protocol changes need 10% more positive votes then negative over a one month time period (urgent fixes must be voted on in the next possible voting period) Protocol changes can be undone if 10% more negative votes then positive votes over a one month time period. Rules of the protocol can be set as hard similar like a normal protocol vote, but with a extended voting period of one year. (some rules are considered as hard from the beginning, tagged as hard. Rules tagged as hard once proofed, intends that the rule should become a hard rule once if is implemented and tested well. This rules must not be implemented from the beginning, but It expresses the will of the community to go into this direction and implement it unless changed in a hard vote) The voting period of rules that are considered as hard is extended to one year. Voting on projects: (Hard once proofed) Max 10 new projects / project groups can be added per month (top voted) Max 10 new projects / project groups can be excluded per month (top voted) Voting on Projects that apply for funds, are voted similar to members. A lifetime, year, month limit can be applied to projects. (limit of 0 is equal to removing the project). Voting on master nodes: (Hard once proofed) Voting on master nodes is done similar to voting on members. Max 10 new master nodes / master node groups can be added per month (top voted) Max 10 new master nodes / master node groupscan be excluded per month (top voted) By default number of masternodes is limited to 1000, this number can be voted on like protocol changes Masternode distribution should be done world wide according to number of participants (for example limited by continent) If the master node limit is reached, old masternodes can be replaced after a one year time period by a new masternode that has more votes (positives - negative) Optional Voting on sentries: (Hard once proofed) Sentries should be people that showed through past activities that they are devoted to the well being of all. Sentries are meant to be the ethical guards and can come also from external people that do good, while master nodes are the technical / infrastructure guard. same like masternodes, but limited to 21 Sentry distribution should be done world wide according to number of participants (for example limited by continent) Sentries have by default 10% of the total voting power. With a 50% majority, sentries can require a second voting period (veto)
  2. Creating Envirocoin

    the concept one coin one piece of land sounds interesting, but needs much more thoughts to be implemented right. One way would be to make it similar to how steem dollar functions. In short you have two currencies, one is volatile, second one is pegged to an asset or currency and backed by the first one. This would give people the choice how much risk they want to take. To voting, currently my tendency is more to go towards one human one vote like cooperatives function normally. To have a vote you must have some amount of coins, similar to how cooperatives function. If you dont have this amount yourself, other people could pledge for you. In short: Envirocoin / Environation Layer one: Layer one Bitcoin technology with 2 minutes block time (block reward halfing every 9 months, nearly similar to pregnancy :)) (hard) Starting bock reward: 10 coins (hard) Max number of coins 21 Million (alternative multiply by thousand so its more user friendly) (super hard) Faster difficulty adjustment / layer two techniques to stabilize block time (see below) (hard once proofed) optional: use of two different proof of work algs (one like bitcoin, one unique) (hard once proofed)
  3. Creating Envirocoin

    to proof of stake: peer coin proof of stake was one of the first, but now there are much better pos systems out there ( i did not look into it if they changed it) next is very fascinating, because it was the first pure proof of stake system, but up to now it never got widely used. iota is still proof of work, tangles like in iota could be implemented on block level if needed, or in a second layer. Ethereum for example has soon proof of stake and is likely also moving towards ¨partial¨ blockchains (each node takes care of one part of the block chain). Very promising is also dash concept: proof of work combined with proof of stake. The concepts seems to be very solid and very easy to understand compared to mostly all other pos systems out there and now they have also tons of developers to develop it even further. Very promising is also steems / bitshares delegated proof of stake. As summary, currently i would tent to have a combination between dash proof of stake added with delegated proof of stake. This would allow near instant transaction verification like dash and steem has it. Layer one proof of work. Layer two delegated proof of stake (implemented as soft fork)
  4. Solidar Economics

    to Solidar economics: Why not make it that way: Give 2 coins basic income per person that registers Give up to another 8 coins. 1 coin for each x (100) coins the person has. This way you have a incentive to hold some Solidar, if you hold too much still the demurrage eats it up, therefore you could lend them out to others so that they get their full universal dividend.
  5. New logos for Solidar

    ...or just make a Freicoin classic fork and use the bird logo combined with the roman leaves: personally i like the bird....
  6. Hi Acurus,

    have you seen that you can earn an unconditional income in Solidar if you join our facebook bot m.me/solidar.winc?

    1. Show previous comments  6 more
    2. Rik8119

      Rik8119

      e52f9a788sa is your unique account ID you can get your id by sending "account". The id that is returned is needed by others to send you Solidar. If you wanna withdraw you type "withdraw address amount".

      You can also name your own account by sending "myname acurus" f.e. THen others can send you Solidar by typing "@arcurus amount".

    3. Arcurus
    4. Rik8119
  7. New logos for Solidar

    Agree with @FreedomCare. First logo is too simple, second logo is far too complicated, too many tings mixed up... I would do it similar to the Freicoin Alliance logo
  8. How we could use demurrage fees as transaction fees and what benefits this would bring: Theoretically it would be possible to use the demurrage fee as transaction fee. This could look like this: In an given block a part* of the block-reward is assigned to transactions as additional paid fee*** according to how much demurrage they pay (similar to coin age the transaction destroys). This could be implemented as soft fork. This would help also to reduce that transactions get stuck because of not paying enough fees. As benefit this would also increase temporally the block reward and therefore attract more mining power** if more transactions need to be confirmed, and lower the reward if less transactions need to be confirmed. This would therefore increase the blocktime on days where lot of transactions need to be confirmed and reduce on days when less transactions need to be confirmed. As side effect this would increased the capacity in case of need and reduce in case of not need, and therefore balance out the transaction fees (more easy to calculate). * the more Freicoin is used the higher this percentage could be * in practice the exact in this way assigned block reward should be averaged over a longer time period like 2 weeks * it would be good to use the log(demurrage) instead of demurrage for this distribution, this would benefit users that transact regularly. ** only if in competition for mining power with other coins *** it could be good practice to distribute the fees over the next X lets say 10 blocks, so that an individual miner has not much benefit in creating more transactions to get more fees then other miners.
  9. Freicoin Resources

    @Skaro currently in Freicoin the demurrage fee is not used as transaction fee. Therefore yes users would have to pay more transaction fees if in the future Freicoin is widely used and the block limit stays similar to Bitcoin Core. Theoretically it would be possible to use the demurrage fee as transaction fee. This could look like this: In an given block a part* of the block-reward is assigned to transactions as additional paid fee*** according to how much demurrage they pay (similar to coin age the transaction destroys). This could be implemented as soft fork. This could also help to reduce that transactions get stuck because of not paying enough fees As benefit this would also increase temporally the block reward and therefore attract more mining power** if more transactions need to be confirmed, and lower the reward if less transactions need to be confirmed. This would therefore increase the blocktime on days where lot of transactions need to be confirmed and reduce on days when less transactions need to be confirmed. As side effect this would increased the capacity in case of need and reduce in case of not need, and therefore balance out the transaction fees (more easy to calculate). * the more Freicoin is used the higher this percentage could be * in practice the exact in this way assigned block reward should be averaged over a longer time period like 2 weeks * it would be good to use the log(demurrage) instead of demurrage for this distribution, this would benefit users that transact regularly. ** only if in competition for mining power with other coins *** it could be good practice to distribute the fees over the next X lets say 10 blocks, so that an individual miner has not much benefit in creating more transactions to get more fees then other miners. More to that we can discuss here:
  10. +1 what can we do to help you? Where to find more information about this project?
  11. The end of the foundation

    @Skaro if i find some time i will sell some dash to you on Freiexchange to @Mark Friedenbach so with normal transactions freirepublic could function? can you outline more in detail why not also with confidential transactions? if the balances are still known it should function or? for every coin hold you give per time period x one republicoin to vote. the votes could still be mixed using confidential transactions. a federation like in dash could enforce in layer two that miners do not block the vote. if the federation fails still the fallback is layer one mining. the federation could be purely implemented as softfork and enforce that a certain amount of the block reward is used according to the vote of the federation.
  12. The end of the foundation

    i would be very happy, if you can take the time to outline why freirepublic (i dont call it a coin for clarity) cannot function? Up to now i described two different solutions. One i posted here in the forum, the second one is simple like dash does it. it would be great to have your technical feedback to that. but for sure in another topic. to foundation. im fine with destroying the funds. removing the inflaton with a soft fork would be great. so option 4 and 1.
  13. The end of the foundation

    @jtimon just for clarification i was not talking about developers, i was talking about foundation members. participating voluntarily as developer is a different responsibility than being in charge of 80% of the funds distribution. My suggested softfork would simply reduce the foundation risk to 100 K coins at a time. and yes it will not solve the decentralisation problem. This leads back to the original question. would there be some members that are willing to do the job of distribution until a decentralized alg is implemented and would the community agree to that?
  14. The end of the foundation

    back to your original question, my preference is in this order: option 2X) add as block reward and add a softfork as discribed above - it would be in away like the current foundation except, that the risk is limited to 100K Freicoins and it can be removed / replaced easily with another soft fork. also i suggest to have a separation between developers and key holders as maaku wanted it to have in the beginning. option 3) do promised 100% matching then give equally to investors after a known time period option 4) do promised 100% matching then do destroy the coins and reduce the supply, but reduce to a rounded supply like 21 Million option 1) do promised 100% matching then destroy the coins option 2) do promised 100% matching then give out as mining reward --> i don't like at all
  15. The end of the foundation

    i wish you and maaku would take part in a more detailed discussion about pos. I dont think that it's flawed, to be clear im talking about a POS POW combination not pure POS. to be more clear, im not talking about a peer coin like POS. im talking about a dash like layer two POS POW combination. yes i also think the peer coin POS implementation is flawed, but up to now i dont see a big flaw that cannot be solved in the layer two dash like POS. please take part in the discussion here: what is the alternative? proof of work as it is now means that each year 5% from that > 80% is just burned for electricity, the rest goes mostly to one who have a monopoly on mining equipment... on top of that up to now we have no good way to implement republicoin / freirepublic / any alternative coin distribution with pure pow >Isn't that what the foundation is currently supposed to do? yes the foundation was supposed to distribute the coins as agreed. Sadly it didnt. That does not meant that the idea was bad it just meant that the execution of the idea was bad. also with my proposal the amount of risk would be limited to 100.000 Freicoin and not 80 Million Freicoins. Having 80 Million hanging in limbo is like having a deathtricker in you hand. Also my proposal can be implemented as a softfork which can be easy replaced later. > the community also didn't developed any other distribution program. i see here also a clear difference of perception. in software development normally you design what you want to have, then you review the design, then you implement it, because changes in the implementation are very costly compared to changes in the design. Therefore just saying yes you can implement something, maybe we will use it maybe not, is not very encouraging especially most are not developers that can implement it at all and are dependent on the core devs, or at least on the one who is holding the key to the foundation funds.