Arcurus

Hi, nice to see movement around here.
I could write a long text to cover all the things that are discussed here, but as @Skaro said we all have a life and not only FRC, so i will write a short summary of my priorities:
Short term (before anything else):
Reintroduce tithe ratio to have funds for social purpose.
Short term:
Introduce a distribution mechanism for the funds (most likely a citizen dividend)
 
If those two points are filled we have achieved a lot. Centralization is a problem for bitcoin because its decentralized structure makes is slow and needs a high consents in the community for changes, that to a huge extend could be blocked by miners. That makes it slow but also resistant to attacks.
When you have a centralized organization it could change fast but is not as resilient. The thing is to find a golden way because some centralization is needed for social projects.
So in my eyes it could make sense to implement another mining method. A mix of POS/POW seems to be the most convenient way (there are examples and it doesn't give too much value to POS as POS is still viewed critical by many devs).
One thing should be very clear: If i'll be part of the development team or not, even the change to POS/POW could take a year development/discussion procedure, so we should be very clear of what we actually need.
@Arcurus I do not understand how a 2. lvl layer for mining works, so i have to look into it as well..
Rik

I'm so glad fedde managed to set up this smart and simple exchange, absolute professional. Without it this would be unthinkable..

10/10 nodes on version 3

Merry Christmas 

"Can we agree, that we want to have other coin distributions then mining"
YES! Everybody here did agree to having methods of coin distribution other than JUST mining.
 

looks like some 1000% in less than one month. But still very low volume. I really hope that we bring the coin distribution to run

yes. I m all in for a combination of proof of stake and proof of member in the long run. 
proof of stake = one coin one vote
proof of member = one active verified member = one vote
With both in place there would be a balance between people who invested their resources and people that invest their life.

" If a fully p2p issuance mechanism alternative to mining is found, a mechanism (for example, proof-of-stake voting) could be established to determine how much goes to security (miners) and how much to the alternative."

I agree with that Rik.

Update 10/9-2017
New design added Minor bugfixes Chapta addon Forgotten password reset Minor improvements Working on some more changes the next few weeks. Any bugs, please report on [email protected] so i can add to the worklist.

Yes we would need a hardfork to provide a sustainable budget. I'm all for it since years.

Yes we would need a hardfork to provide a sustainable budget. I'm all for it since years.

Hi Rik,
yes we don't need donation matching, we could distribute the coins directly to people. The donation matching was just a workaround with the current issuing. I don't think airdrops are a good solution, they don't solve any problem in a sustainable way.  
I would prefer to give people a steady amount of coins per time period. This would encourage long term use of the coin and long term fair money distribution. 
 

the current plan is to use the infrastructure from Freiexchange to give out coins directly to people. Fedde has already all the code for verifying phone per sms.
He just needs some time to clean up thinks. He then wants to talk to maaku to get direct coins for the giveaway. If it functions, we have more arguments to make it permanent and  use some part of the block reward.

of course i was just thinking that an airdrop has a huge pr effect and to sustain an ongoing payment we definitely need the hard fork to distribute mining rewards to the foundation funds..

Mainly we need to improve the following:
- Secure the blockchain
- bring the coin issuing / foundation to run or replace it
once the coin issuing is functioning, we could give incentives for using freicoin
How could Freicoin 2.0 lesson learned look like:
- use merge mining or alternative mining alg that only freicoin has
- switch to a combination of proof of work and proof of stake
POW + POS example:
- in each block 8 stakeholders are chosen, the more stake the more likely they are chosen
- foundation coins are not considered as stakeholders
- addresses with less than 1 coin are not considered as stakeholders (to remove dust in the unspent spet that is relevant for consens)
- not moved coins for one month are not considered as stakeholders if they didn't sign at least one stake transaction in the last month  
- each chosen stakeholder can create a so called ¨stake¨ transaction
- each stake transaction must refer one block and can only be included in the next block after this refered block
- the block which includes a stake transaction needs -10% difficulty for each included stake transaction
- each included proof of stake transaction gets 10% of the fees + 10% of the coinbase coins
 
If we would have this in place, how could the coin issuing look like?
- each stake transaction can assign up to 10% of the demurraged coins to so called ¨white listed addresses¨ 
- as long as there are non distributed foundation coins, each stake transaction can assign additional up to 10 times the value of the demurraged coins from the unspent foundation coins to the to so called ¨white listed addresses¨
with this in place and a demurrage of 5% per year, foundation coins could be at best issued in 2 years
- white listed addresses are enforced by a softfork through miners / stakeholders / nodes
for example the same like voting for bitcoin softforks: new addresses need 2/3 approval and are valid for one year or at max X coins. Addresses can be removed by setting x to 0  
 
 

Enough is enough! ECB is stealing our name: they made ¨freecoin¨
https://bravenewcoin.com/news/eu-parliament-states-virtual-currencies-cannot-be-anonymous/

Thx to fedde we have now: https://freiexchange.com/login

looks quite good, only few addresses have some less than 0,1% difference

Hi all,
here is a draft, how the current blocksize could be increased though using a soft fork similar to segwit. Please outline my errors if you find some.
All the good,
Arcurus
 
Introducing extended blocks:
- like with segwit an extended block is used to have extra space
- these extended block is referenced from the normal block
- transactions can be either stored in normal block or the extended block
- the old block plus the extended block is not allowed to be bigger then the new extended block size
- so called extended transactions that can be stored in the extended block, must mark their output to be spent by all according to the logic of the old nodes
- enforced through a soft fork only transactions are allowed to be placed in the normal block that are not conflicting transactions in the extended block
- once activated updated nodes will not propagate conflicting blocks and transactions
 
With this in place old nodes would only process transactions up to the 1 MB block limit. Updated nodes could use the extended block on top of that to process extended transactions. If the fee is high enough, extended transactions can also be included in the normal block.
 
Implementation:
- the output of transactions once included in the extended block could only be spent again though using the extended block. With time this will naturally dry out the normal block (if not manifested, see below)
- since transactions in the extended block can be spent by all according to the old nodes, a so called manifestation transaction could be used if needed to manifest what was happening in the extended block
- to be valid according to the old nodes these manifestation transactions would naturally need to include at least the initial transactions, which marks the output to be spent by all according to the old block logic
 
Introducing a Multi tier block chain:
The same way as outlined in Extended Blocks we could use a multi tier block chain architecture.
 
More to that you can find here:
 

UPDATE:
old nodes that are not aware of an higher existing tier can just continue to validate transactions as they always did. Updated nodes, that are aware of an higher tier, but do not have enough resources to be a full node on a higher tier, could if they want take part in the active enforcement of higher tear transactions in the following way:
- they could download the full or a part of the current balances (unspent set) from higher tier nodes and block transactions / blocks that are not valid according to that
- if they dont have the current balances they could ask higher tier nodes if the transaction is valid and block if not
 
What is the trust model for that?
At worst it would have the same trust model as now, because also now miners have the power to block transactions as long as a majority of the mining power agrees.
Further the following could be done to increase the security:
- lower tier nodes could verify, that the balance set is referenced from an block in the longest chain and therefore has at least the majority of the miners behind it
- lower tier nodes could partially proof the validity of the balances and could denounce nodes that provide invalid data 
- lower tier nodes could ask different higher tier nodes they trust if they agree on the current balances or validity of an higher tier transaction

why is grantcoin fiat money? Yes grantcoin will lead to rising prices, but not necessarily this gives advantages to big corporations. As long as the newly created money is given directly to the people, the people have the most benefit and cannot be dried out like in the current interest / debt based system or in an gold like system which will ultimately again lead to a interest / debt based system, because it accumulates with time.

Here a draft that includes also a dividend (basic income) to all members (I like the distribution, because it has the golden distribution rule 1 / 5):
 
POW + POS + POM (proof of member) example:
Transaction fees plus demurrage coins plus not yet distributed coins are distributed the following way:
20% goes to proof of work block creators at max (this number is not set in stone and could be reduced if the blockchain is successfully secured with other methods).
20% goes to stake voters
20% goes to member voters
20% is assigned to projects according to the stake votes
20% is assigned to projects according to the member votes
 
Introducing proof of member:
- in each block 8 member groups  from a so called ¨members group list¨ are chosen through using the proof of work hash
 
Introducing Member Transactions:
- member transactions are handled similar to stake transactions (see above post)
- each stake or member transaction must link to one block and can only be included in the next block after the linked block
- for each included stake or member transaction the difficulty target of this block is reduced by 5% 
Example: If a block includes all possible 16 stake / member transactions the difficulty of this block is reduced by 16 * 5% = 80% 
- each stake or member transaction gets  2.5% of the coins to distribute in this block (in total max 20% for all stake transactions and 20% for all member transactions)
- each stake or member transaction can assign up to 2.5% of the coins to distribute to a project address (therefore in total max 40% of the issued coins) 
 
Introducing Member groups:
- member groups have a member count that indicates how many members this group has
- a single member is simply a member group with the count 1
Example: a member group with a member count of 10 has 10 times the chance to be chosen for creating an member transaction then a single member has
 
Introducing Member Group List:
- each stake or member transaction can vote for a member groups 
- each stake or member transaction can vote against a member group
- an member group becomes added to the member list if it has at least 16 positive votes and at least 2/3 positive votes 
- an member group becomes removed from the member list if it has at least 2/3 negative votes 
- optional: after one year a member group must be again approved or the member count is halved (rounded down)
- optional: for each added member the average payout* per member for one month must be paid as fee
Example: average payout for one month = 20% of the demurrage of this month / member count

I can do some testing. My computer skills are not so great as to be able to build a wallet without a dummy's guide, but Im willling to learn and put in the time.

looks quite good, only few addresses have some less than 0,1% difference