Fabrizio

Sidechains and merge mining have their own intractable problems, and in particular they do not mix together very well (merge mining makes the sidechain problems worse, and vice versa). If freicoin were to be sidechain to another chain, it would have to either (1) be a separate proof of work, or (2) have all full nodes of both chains validate each other, an idea more commonly known as extension blocks. Setting freicoin up as a separately mined chain with a different proof of work (and therefore different hardware distribution) prepares for the first possibility while not excluding the second. But in reality I expect that freicoin will remain different from bitcoin and other coins, and not an active sidechain, except perhaps via strong federations or higher level protocols using cross-chain payment channels.
There is at least one person I know who has made a recent ASIC purchase for freicoin mining, and I would hate to invalidate that investment. But the transition period also serves the purpose of having incentive for securing the sha256 portion of the network for some time to come, which helps protect other full nodes. In fact, current full nodes will be able to sync indefinitely into the future, even after the transition is complete, as the difficulty will have transitioned back down to diff-1, and all cuckoo cycle blocks will require a follow-up diff-1 sha256 block in order for the cuckoo cycle miners to actually collect their payment -- the trick which makes the soft-fork deployment possible.

I would like to gather community opinion regarding a possible change to freicoin's mining algorithm. Right now we use the same proof of work algorithm as bitcoin, non-merged mined double-SHA256. I have for some time been an advocate of switching to a newer proof of work algorithm that has better protections against mining industry centralization, and which avoids price- and difficulty-based swings in hash rate between bitcoin and freicoin.
However it has until now been thought that changing the proof of work for a chain is necessarily a hard-fork change, which I would be hesitant to support for a variety of reasons. But it turns out that's not the case! I recently invented a mechanism for phasing in a proof-of-work change as a soft-fork, with a transition between the two over months or more likely years that gives safety for the old clients during the transition, and is not too complex of a change either. So we now have the capability to change proof of work, to something slightly more ASIC resistant with better decentralization effects and less competition with bitcoin. Without getting lost in the weeds, I am specifically considering the Cuckoo Cycle proof of work, which you can read more about here:
https://github.com/tromp/cuckoo
Is this something the community could get behind? The parameters of the soft-fork transition would be set such that it would not invalidate any investment people have made into sha256d mining during the lifetime of the miners. I'm thinking 2-3 years for a full transition, during which time the reward does a linear transition from sha256d to cuckoo cycle. And it would probably take six months to implement anyway.

@ Mark Friedenbach      Thank you for your hard work and time spent on Freicoin

Regarding ASIC reistance, it's a goal that in its strongest form is impossible. You cannot have an ASIC-reistant proof of work, and if someone is trying to tell you otherwise that's a good indicator you're dealing with a crank (or they're trying to sell you something). Anything you can do with a general application-agnostic circuit you can do more efficiently in a specialized circuit. This follows straight from information theory.
HOWEVER, there is a weak form of ASIC-resistance which is interesting to note. With double-SHA256, GPUs are 100-1,000x more efficient than CPUs, FPGAs are 100-1,000x more efficient than GPUs, and ASICs are an additional 10-100x more efficient. Double-SHA256 ccould hardly be more ASCI-friendly. So the weak form of ASIC-resistance is an algorithm which, when implemented in specialized hardware, has the smallest possible advantage when when compared against consumer hardware like vector CPUs or GPUs. With Cuckoo Cycle, for example, the advantage gained by ASICs over GPUs is only an (estimated) 2-4x. Compare that with the more than thousand-fold improvement double-SHA256 sees.
Why does this matter? Because in the event of an attack on the network, a disadvantage of 2-4x can be overcome by a wide decentralized base of users, perhaps motivated by investors favoring the decentralized chain over the centralized one (e.g. look to the price difference between BTC and BCH). The decentralized chain can withstand an attack by retreating to a popular base of GPU miners. With double-SHA256 however this isn't possible. If non-ASIC bitcoin users wanted to revolt against the ASIC industry, they would find that even if everyone mined they'd only get a block on their chain once a month or so. It would take the better part of a century to see the first hash rate reduction. Even with freicoin's faster difficulty adjustment it would still take years. That's not even close to being a realistic alternative, and therefore any resistance to centralization forces all the problems that come with hard forks.
Weak ASIC resistance doesn't do anything to boost decentralization, in first order analysis. You'll still see creation of ASICs and their adoption within the mining industry. However it does enable fallback options whose very existance prevents the ills of centralization from happening. These are 2nd-order game theoretic effects.
We've discussed both proof of stake and paxos consensus models before. The claims of these systems are analagous to perpetual motion machines. I really have no interest in going that direction, and would spilt ways with freicoin if that's what the community wants.
> Why use a two way proof of work architecture?
It's a necessary fact of being a soft-fork. The old clients need to see progress being made on double-SHA256 blocks. That's the only reason.
> Isn't a double spend more easy in a two way proof of work architecture?
No.
> How can a simple difficulty algorithm look like?
That's a bit isomorphic, but the difficulty algorithm would probably look a lot like the one in Freicoin today. The parameters could probably be better optimized, but ultimately the choice of a linear filter was correct is justified by its performance.

having an own mining alg sounds good, because in the long run if there are Freicoin specific asics, they would have an incentive to stay helpful to the coin.
It could be even a good idea to have both algs running on the same time, therefore we should think about never fully abandon SHA256.
Having it asics resistant is no need, i think its good to have ascis mining the coin, otherwise again lot of general purpose mining power can switch to mine the coin and also botnets can mine the coin....
To miner centralisation, i think a mining alg change will not solve that long. Centralization will always happen in the industry. If asics are easy to produce for the alg the hope is, that competition will always be big enough that no monopoly happens.
If you ask me, to solve the centralization problem switching mining algs will never help, either you make it genera purpose, in this case the current companies like intel / asus / amd dominate, or you make it special, in this case asic manufactures dominate.
A true solution to the mining centralization problem would be to implement Freimining, in short give subsidies to decentralized community driven miners and or Freicoin related hardware producers
Or change to a combination of proof of work and proof of stake / proof of member / or something like stellar / ripple consensus
this can also be implemented as a soft fork as maaku described above.
 
By the way, if you switch the mining alg it would be good to switch also to a better difficulty alg.
 
Some ideas to that:
 
Why use a two way proof of work architecture?
The main reason why to use a two way architecture is to not be dependent on one mining hardware provider. In case if needed one mining algorithm can be replaced more easily. Another reason is to allow more people to have access to new coins. One alg could for example be an alg that is easy to use with general purpose computers and therefore allow a wide access to new coins. The other alg could be easy for asics, so that special asics are created that have an interest in the health of the coin.
 
Isn't a double spend more easy in a two way proof of work architecture?
In the end transactions are secured through the economic value given as reward o the miners. A two way proof of work architecture doesn't change that. Proof of work in layer 1 is used to make sure that is is economically expensive to undo transactions. A layer  2 can make sure that transactions can be treated as good as irreversible once confirmed in layer two.
Further by default blocks that are mined before the target blocktime is reached can be required to have a higher difficulty or be rejected by the network (see below)
 
How can a simple difficulty algorithm look like?
First of all it is good to clarify the two design goals a difficulty algorithm should fulfill. First it must make sure, that the difficulty adapts if the mining power increases or decreases. Second it must make sure that in the long run the blocks created per time period is ¨fixed¨.
The first goal could be reached through this:
- the difficulty is increased / decreased each block by up to 10% if the last 10 blocks have been in average faster / slower then target block time
 
The second goal could be reached through this:
- if 10 blocks more / less then the expected blocks are created the target block time is set to 0.8 / 1.2 the target blocktime.
 
A third optional goal could be to make fast block creation more difficult:
- a node only propagates a block if the difficulty is higher then: target difficulty * target block time / time since last block. At minimum a block must have still at least the target difficulty. With this a block that is double too fast would need double the difficulty to be propagated in the network. Four times to fast would need four times the difficulty. 
This would also reduce the problem of mining  centralization and therefore give an opportunity to reduce the block-time, because with the above alg miners would have in average  more time to receive the new block. On top of that through making the required difficulty time based this would allow a much more stable blocktime even if using the same mining alg like other coins. In short No more incentives for drastic hash increase or decrease.
 
For example, normally the difficulty does not change relative to the last blocktime. Therefore the difficulty is either that low that the coin is the most profitable to mine and therefore attracts the majority of the mining power or that high that the coin is not the most profitable coin to mine. This leads normally to sudden and drastical hash increase or decrease. A drastic decrease in hashpower is even more fatal, because this normally slows down the difficulty adoption. Economically no miner would have an economic incentive to mine such a coin to bring down the difficulty, which makes the coin dependent on good willing miners that make an economic lost.
In case the above alg is used if the last blocktime is too low and therefore the difficulty too high, miners will mine simple another coin (or stop mining). With time if the last blocktime becomes higher, the difficulty will decrease and therefore the coin becomes lucrative to mine until the next block is found.    
 

Sounds good to me. It similar I have seen on some coins that use Sha and scrypt to solve blocks. 
Will have pool ready for second also. 

That's correct. There would be different sets of miners for the two algorithms. Pool services would run different pools for each.
The length of the transition period and the allocation of subsidy between the old miners and the new miners is arbitrary in a sense. There's no technical reason for the choice, just soft factors like making sure that nobody is wronged by the transition and the community split as a result. A straightforward choice is to have a linear transition so that the subsidy given to sha256d miners is slowly stepped down and given to cuckoo cycle miners, over the course of 2-3 years.

Ok, the dnsseed.sicanet.net has been running the past years, still working good ?

@ fedde thank you for your hard work with freicoin over the years.

A little bit of a technical update I want to share. As part of the refactoring and rebasing effort I've worked out a way to eliminate Freicoin's extra dependencies while at the same time achieving a 10x performance boost for the mathematical calculations we use these libraries for. I'm quite excited about this, although for reasons that might be obscure for those without a technical background. If you don't understand this post, that's okay. The TL;DR is that we can make Freicoin faster while further aligning the code base with bitcoin to minimize the maintenance burden.
Freicoin uses the GNU MP and MPFR multi-precision arithmetic libraries for performing cross-platform portable demurrage calculations within consensus code. Calculating demurrage factors involves taking the per-block demurrage rate r = (2-20 - 1)/(2-20) and raising it to the nth power, where n is the relative depth of the output (next block height - output's refheight). The fastest way to do this on workstation or server-class hardware is to use the CPU's floating point unit to perform the exponentiation. Unfortunately there is just absolutely no way that this can be done safely and consistently inside of consensus code. CPU manufacturers do not guarantee the bit-for-bit accuracy of operations compared with other CPUs of the same target architecture, much less with reference values or cross-platform targets. There was at one time a dream of decimal floating point (IEEE 754-2008) which would have had reproducibility as a requirement, but alas that never took off.
The solution we adopted in 2012 was to use GNU MP (a multi-precision exact big integer and rational arithmetic library) and GNU MPFR (a multi-precision software floating-point library with rigidly defined semantics) to implement precise, cross-platform software floating-point demurrage accounting. This has the advantage of getting the job done, but there are some downsides:
Performance. Freicoin suffers from this use of external multi-precision arithmetic libraries. Although optimized for speed GNU MP simply cannot approach the raw performance of directly adding two 64-bit numbers in hardware, and the multi-precision heap allocations add overhead and indirect storage causing latency. MPFR on the other hand is designed for precise, cross-platform behavior in simulations, not frequent high performance calculations. It is also overkill given that we use the library for one single calculation only, for which a generic library like MPFR would not provide support for specialized optimizations. Reliability. Both GNU MP and MPFR use dynamic (heap allocated) memory for their bignum representations. That means that there potentially is allocation or reallocation happening every single time a call is made to GNU MP or MPFR arithmetic functions, and potentially an out of memory exception is generated. Originally this was every single time any kind of arithmetic was done on freicoin values. With the recent input-truncation soft-fork it is already possible to reduce this to just demurrage calculations. However that still means that there is the possibility for abnormal or transient exceptions to occur in code that in bitcoin consists of normal arithmetic operations. This code was not audited for failure modes as a result of this different behavior, and there is added risk of local node instability as a result. Maintenance. Bitcoin has special scripts to make reproducible builds of all of its dependencies. These scripts are custom developed and maintained by a sizable Bitcoin Core development team, and these build scripts are very frequently updated as bitcoin matures. These scripts would have to be modified to include reproducible builds of GNU MP and MPFR, and those changes maintained and re-integrated with each new release of bitcoin. This is a bit of a sore point for me because I originally fell off the wagon of providing regular maintenance updates to Freicoin on release 0.9, in which the build system changed quite drastically due to the switch to autotools. Legal. GNU MP and GNU MPFR are both distributed under the terms of the LGPL. Because official Freicoin binary distributions are statically linked, that meant that they are also GPL programs. Now I'm a strong advocate of libre software, user rights, and the GPL, so on the face of it this was not too concerning to me back in 2012. However the Freicoin software repository says like bitcoin that it is MIT/X11 software licensed, and these sort of viral software licensing traps are difficult to see, so I can see how someone might run into GPL license violations as a result, without intent of doing so. There is a permissively licensed fork / re-implementation of GNU MP that we could use, but not alternative for MPFR. Given that the rebase to bitcoin master (0.16 as of now) would require re-doing the pieces which use GNU MP and MPFR anyway, it seemed like an opportune time to look at replacing these dependencies with something faster, safer, in-house, and permissively licensed. Thanks to input truncation, all the regular accounting can be reverted back to 64-bit integer arithmetic instead of multi-precision rational numbers. The trickier part is the demurrage calculation, which still needs to do an internal real-number precise exponentiation.
To remove the dependency on GNU MPFR I wrote an integer-math-only exponentiation of the freicoin demurrage rate using pre-calculated look-up tables, and through exhaustive testing proved it to be bit-for-bit identical in its results compared with the GNU MPFR version. I then went through and applied as many approximations and reductions of internal precision as I could without generating incorrect results, to get the absolute fastest implementation. Here's some raw numbers:
The first column is the algorithm name. The "mpfr_mul" is the algorithm currently used in freicoin, and "mpfr_div" and "mpfr_small" are variations upon it. The "small" variation reduces internal precision to as low as can be done without errors in exhaustive testing, which would be a cheap one-line change to the existing method. The "apu" algorithm is the new integer-math-only implementation using pre-generated lookup tables for the exponentiation. The "f32"/"f64"/"f80" algorithms use single-precision (float), double precision, and extended precision (long double) floating-point math on the CPU, as a point of comparison for timing. The "div" variations calculate the inverse of the demurrage rate, which is potentially a faster exponentiation to perform albeit at the price of a slow division at the end. There is an "apu_div" method, but it is unfinished so I did not include numbers for it.
The second column gives the average run time per evaluation of the demurrage calculation on my laptop. Neither the "mpfr" nor "apu" methods have constant time performance -- the runtime speed should have some logarithmic dependency on the number of set bits in the integer representation of the relative depth (the exponent in the demurrage calculation)--a point I'll get back to in a minute. For the "mpfr" family this effect is small, but for the "apu" family it is more pronounced and the worst case performance should be about twice what is reported here. But conversely the expected execution time depends on the average age of UTXOs, which would be way less than the exhaustive testing reported here. The hardware accelerated floating point operations should be constant-time on most CPUs. The numbers above were calculated based on an exhaustive test, for which the "average" age of a UTXO is about 1,000 years. Here are more realistic numbers with an average age of 1 year:
Note that mpfr_small and apu_small are 22% and 30% faster, respectfully. (Also note that apu_small is about as fast as performing the exponentiation on actual floating point hardware! That was a nice surprise.)
The final column gives a triplet of numbers reporting (1) the number of errors found in exhaustive testing in which the demurrage was greater; (2) the number of test cases which matched the reference implementation; and (3) the number of errors found in which the demurrage was less than the reference implementation (mpfr_mul). Note the intrinsic errors involved with using hardware floating point, even for "f64" and "f80" which unlike "f32" should have had sufficient internal precision to perform this calculation exactly. Hardware floating-point is not to be trusted.
The clear winning approach is "apu_small", and I will be replacing the GNU GMPR demurrage calculation code with this technique, using an implementation that has been exhaustively tested to be 1:1 identical in results with the multi-precision implementation that is presently in the Freicoin consensus code.
What I did not expect going into this is that this implementation is not just as good as MPFR's general approach, but is in fact nearly 20x more efficient in common use cases! And I am blown away that it is nearly as fast as computing demurrage directly in hardware floating point.
While the difference is unlikely to have profound effects outside of a few special cases (e.g. calling 'getbalance" on a very large wallet), it will nevertheless reduce latency of various transaction processing and UI code, thereby delivering a better user experience. Far more critically it will improve the safety and security of the Freicoin reference implementation while significantly reducing the work that goes into keeping Freicoin up to date with upstream bitcoin. That's exciting to me at least
You can expect a new version of freicoind with these improvements integrated to be out soon, as that is what I am currently working on.

> Is there still a need to have a refheight in the Freicoin transaction if so why?
There's a couple of ways I can answer this question.
First, there is always a need for refheight in Freicoin transactions just by definition: it would be a hard-forking consensus change to remove them. This is the technically correct answer but mention it only for completeness as I assume it's not what you meant.
This doesn't affect the need for reference heights in any fundamental way. Reference heights address a problem that generally applies to demurrage in bitcoin-like block chains: the demurrage rate reduces the inputs of a transaction without affecting the outputs, so if naively evaluated at block height it would introduce a back-door transaction expiry as at some point (which can be calculated) the transaction will have less input than output, resulting in a negative fee and consensus violation if it were then included in a block. There are basically three approaches to fixing this: (1) allow negative fees so long as the block as a whole doesn't have negative fees in aggregate; (2) assign a specific height to a transaction, less than the current block height, and use that for demurrage calculations so it is independent of block height; or (3) forget demurrage in the protocol and have an exponentially inflating currency instead. The first approach didn't work in 2012 as child-pays-for-parent wasn't wasn't well supported, and still isn't to some degree. The third approach we rejected for experimental reasons, although it would have had the nice property of pulling demurrage calculations out of consensus code and block validation logic. The second approach is what we did and what we're stuck with, at least on the present and future soft-fork compatible incarnations of the Freicoin block chain.
Reaching more into an aside, I will say that it was never necessary that Freicoin transactions have an explicit reference height field at all, which is what breaks compatibility with bitcoin tools. The semantics of the reference height are that it is a block number which must be greater than or equal to each of its inputs reference heights, and less than or equal to the current block height. This happens to be a more strict subset of the rules for transaction lock-time! So an extra refheight isn't really necessary and never was--we could have just double-purposed the nLockTime field to be a reference height, making its use mandatory and adding extra constraints and restrictions. But alas we didn't notice this until years after the initial release of Freicoin, and that ship has sailed leaving us stuck with reference heights as an explicit extra field. Oops.
> Is the demurrage calculated on the uxto set, or on the transactions itself?
Reference height of inputs are stored in the UTXO set; demurrage is calculated during transaction validation. In bitcoin there is a check that sum(inputs) >= sum(outputs) in any context where a transaction needs to be validated -- e.g. when adding to your mempool or when encountered in a block. In freicoin we do the exact same thing except in the summation of inputs we adjust each term by the demurrage rate calculated from the difference of the transaction's reference height from its input's reference height.
> If on the transaction itself is then pruning of old transactions possible in Freicoin?
Yes, there has never been any restrictions on pruning old blocks. There just hasn't been an official release that supports this feature, which was added in bitcoin v0.11.0.

@Fabrizio, regarding the parameters for option 2, I too did ask if @jtimon could maybe share some thoughts on that. And thanks for presenting your ideas too--although I wanted to wrap this up. He has so far clarified: 1)funds to go through miners, not POS; 2) one of the reasons we want to end the Foundation is because no alternative method for distribution was developed by us, so we shouldn't pretend that we will developed one now, 3) the goal is to end the Foundation, not to create another one. So option one represents the maximum time to distribute the funds, option 4 thier complete destruction. I think your suggest kinda falls under (2), we haven't got the basic income up and running yet. Don't get me wrong, I like the idea, But it may not materialize.
We could reasonably target having a round figure still of say 30 million. I think people reading Freicoin history will think, "they saw a problem and fixed it while still keeping that character of the coin the same."
anyway keep discussing, but let's aim to get this wrapped up soon.

'ay, fair points Bick. I'd like to see/hear more detailed visions of the future from both as well. Here on the forums or on the Freicoin website that is.. both have voiced some of their ideologies on some other mediums while discussing other topics, so they are out there for anyone who has been following their work  

I hope this isnt seen as stalling, but I'd like to see some discussion/opinions on the option 2 still though. Especially from jtimon, since it was his preferred choice. So @jtimon did you have some kind of schedule or scheme thought for this based on some ideals?

Thoughts for others: 100mil cap could be easier to psychologically accept for some people than the number that would be set after the fork. "Why is the supply this random number" -> research -> "Ohh, they changed it afterwards based on small number of votes" -> decrease in confidence.

A well planned schedule could also allow us to attract miners and users. If the rest of the coins would be made available for mining on certain date (for example 1.1.2018) and would be mined by end of 2018/2019/whatever, there could be time to get some of the Alliance mining and/or basic income projects up&running. This would in some aspects be kind of replacing Foundation with Alliance.. though the Alliance is holding some funds received from the foundation matching, so would also be a way to distribute them as well and ~correct the Foundations.. "mistakes" too.

A plan moving forward please. Seems we have agreed to some things. And again somethings like POS vs POW have already been discussed before Arc and I would defer to what Mark and Jorge have said on this issue we don't need POS. As for freimarkets colored coins etc... what are the developers willing to do? I think 1 and 4 seem agreeable to most. Let's see that done and maybe we can see a more concrete plan moving forward. If everything now is going to be run through the forum and discussed great. But what is the agenda? What do we need etc. The foundation question seems mostly solved. Someone write it up and lets vote and then move forward.
 
Note: Fab. Well I have said my piece and it needed to be voiced. As for attendance and the community? Really? A lot of those past options and plans were debated within a larger community and assumed that would be acted on. If we want to keep discussing things already discussed and posted then in reality it is a waste of time and it is a delaying tactic at best. I am not asking for anything other than following up on what the devs want to do with their established plans and they were discussed at length in the past I don't see how things have change demonstrably since 2014 or 2015. I am not asking for the devs to make this their job and put in 40 hours a week and cut everyone out of the process. I just want them to engage with us in a reasonable way so we can expect some sort of progress. Have a look at the old forum you will see what I mean on that. It would be worthwhile for those two to put their vision on paper and get us the community to sell that with our input. But you can't keep limping along with no one leading this thing. Someone needs to step up and moving things forward.
 
 

I would've liked to see the Foundation continue. At the current moment in time though, I understand the wish to end it since there is no tested-to-work tech for the fair distribution (self-sovereign/decentralized ID, WOT, voting systems).. as well as the inability of our small community to launch the many centralized experiments we've discussed/planned/outlined to attract wider user base  

Option 3 I dislike, since there are a bunch of coins in lost privkeys (and possibly in questionable entities possession; case Cryptsy) -> Drags out the "full supply" of coins available for circulation.

I'd prefer option 4, but option 2 could be as acceptable  Option 1... I wouldnt like to see inflation added, but it wouldnt drive me away from Freicoin neither.

Edit: Short off-topic comment @ Arc and Bick: I totally see both of yer points and comments and theres validity to them.. especially with that theres not been that much communication with the devs during the past years with the couple of channels we tried (Forum/IRC/Mumble/Blab etc.), but there wasnt too much attendance from the community neither  To make this short; the Bitcoin development team has done some mindblowing codewizardry during these years that will benefit Freicoin too once the client gets updated  Theres also the things from Blockstream projects that Jorge mentioned above that are really neat and should help with the experiments we've discussed before. So dont be too harsh with Jtimon and Maaku, I think we've (the world) benefited more with them working on those projects ^^ (pfft.. not that short.. I'll try to trickytrick with smaller font :D)

I would've liked to see the Foundation continue. At the current moment in time though, I understand the wish to end it since there is no tested-to-work tech for the fair distribution (self-sovereign/decentralized ID, WOT, voting systems).. as well as the inability of our small community to launch the many centralized experiments we've discussed/planned/outlined to attract wider user base  

Option 3 I dislike, since there are a bunch of coins in lost privkeys (and possibly in questionable entities possession; case Cryptsy) -> Drags out the "full supply" of coins available for circulation.

I'd prefer option 4, but option 2 could be as acceptable  Option 1... I wouldnt like to see inflation added, but it wouldnt drive me away from Freicoin neither.

Edit: Short off-topic comment @ Arc and Bick: I totally see both of yer points and comments and theres validity to them.. especially with that theres not been that much communication with the devs during the past years with the couple of channels we tried (Forum/IRC/Mumble/Blab etc.), but there wasnt too much attendance from the community neither  To make this short; the Bitcoin development team has done some mindblowing codewizardry during these years that will benefit Freicoin too once the client gets updated  Theres also the things from Blockstream projects that Jorge mentioned above that are really neat and should help with the experiments we've discussed before. So dont be too harsh with Jtimon and Maaku, I think we've (the world) benefited more with them working on those projects ^^ (pfft.. not that short.. I'll try to trickytrick with smaller font :D)

It might be tangential to this discussion, however it is not tangential to this community in that if you promise to deliver changes on what we are voting on then fail to follow up on developing the coin further why should we invest time? You and Mark have not really been setting development goals and updating the coin over the past two years. I think it is also important to note that giving up on the idea of foundation (Mark and Jorge's idea) is just one more signal that you want to divest yourself of responsibility to this tiny community. That might not be the intention but it sure is what some people think. Let me be really frank here. It would be best that you come up with a plan with goals and then tell the community what this road map is and begin doing it.
I agree with what you are proposing and I agree with your assessment about what FRC should be and I think option 1 is the right move as is option 4 as well, so please make that happen asap or at least cap debate here and move on already it is bogged down at this point. POS vs. POW is not a relevant debate and way way way off topic really. As for anything else well I want to see a clear outline with at least something that can be measured. I think the community here has done what it can given that we have seen promises for updates and changes to the coin before and nothing substantive has happened. Passing some of the blame to the community is fair but to be honest without developers pushing changes and improving the coin what do you expect a community to do? We basically have no users because the coin is not promoted by those who developed it. If you don't have the time or want to let it die then tell us now or make a real effort to plan a revival of the coin.

Sorry but the real issue here is that we lack a community of sufficient size to really to do much of anything to progress the coin it would entirely rest on the developers shoulders to provide the stimulus to engage a much larger community.  Without any direction and lack of updates this coin has failed to attract a larger community. You two need to have a greater vision or plan ala Vitalik Buterin. He was willing to step up and put in time and draw more developers to his way of thinking because of his vision. Freicoin has a greater potential to be disruptive compared to Ethereum given core economics of Freicoin. Do you guys want to push that or just keep debating here in this obscure corner of the cryptocoin world with people who are not necessarily your peers? To me that is a waste of time given the debates on these issues were already conducted 3 or 4 years ago.
Rather than debating 3 or 4 people on things, what you really need is a real cabal of developers to move FRC forward not us laymen see Vitaly Buterin again as the gold standard for drawing people in with an idea out of nothing with zero base. Where have those people gone you had originally supporting development? They left for a number of reasons but I suspect there was little or no interest remaining as there was no active development. No challenges. No vision. No plan. Don't make the same mistake.

This is not a community large enough to be a relevant sounding board for you two  to develop the coin into something that is targeting a user base of millions of people. You need to bring in a larger team of people with ideas for growth that will draw a real user base. Until you need to involve more people in decision making from a wider community of coin users it be better to make a plan, invest time into carrying that plan out and when the millions of users do come on board you can work like Ethereum or Bitcoin Core etc. and talk to the community about options. I value that you are trying to fix mistakes and work with this community but your time is limited and should be focused on developing the coin not debating the very core concept of the coin or the foundation. It is great you want to engage with us but really. Set your vision and make it happen then we can debate the validity of your choices or offer up suggestions to make the coin easier to use.

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. 
 
 

My intention is not to "abandon the coin and let it die" but that doesn't mean maaku, me or any other voluntary should be bullied for using (or not) their time as a voluntary however they want. 
Please, @Arcurus stop telling other volunteers how they should spend their time. You are free to spend your own time however you want. When things don't happen as fast as you wanted them to happen (or just don't happen at all), don't blame other volunteers for not having done them: blame yourself for not having done more to make them happen.

@Bicknellski volunteers that are developers don't have special obligations or privileges. Here there's no ICO in which users paid developers like in eth: eth and freicoin communities simply cannot be compared in this sense. Please stop talking as if @Mark Friedenbach me or anyone else owed you something just because you are a user. I'm a user too. Just because I learned how to program that doesn't make me your slave or anyone else's.
Please, save your "developers should do X or focus on Y", "the community should focus on X", etc. In my experience that doesn't help build a healthy community of volunteers, it does pretty much the opposite. You will focus on whatever interests you the most and everyone else will do the same.

We can discuss potential future roadmaps in other threads, but this is about putting an end to the foundation.
So back to the topic at hand...
Yes, as said in the opening post, I think the promised 100% matching should be done before putting an end to the foundation.
Regarding the softfork to limit the quantity that the foundation can issue:
1) There's no need to do that at the consensus level if the foundation is still centralized.
2) It doesn't put an end to the centralized foundation.

I'm surprised that people don't like 2 and I'm not sure I understand the reasons, but it seems I'm kind of alone having that as a favorite.
I guess my preferred order is: 2 > 4 > 1 > 3.

@Arcurus POS is surely useful to keep the coins from the exchange what is artificial demand that is created. But Demurrage is to encourage the stakeholder to lend their money for zero interest, POS is doing the opposite.
I know that you want the currency to be some sort of governmental structure (perform lending and distribution -which is a honorable idea) but i don't see that it is doable. And with so many different ideas in the pipe i think it is better to build a bank that is doing the social lending and some charity that supports social organizations (both then are not part of the currency) just to keep the currency simple.
It was also hard for me to internalize that Freicoin is just Bitcoin with demurrage but thats what it is, I offered the community to further develop the coin but there was no consens, only more fresh ideas. So if one wants some redistribution mechanism (Yes, "The community" did develop some other distribution mechanism -UBI) one may want to think about switching to solidar and not being harsh with the devs ;-).
 
Btw @jtimon i still dont see why reducing the mining reward is a soft fork since coins from the high mining fee chain wont be valid on the low mining fee chain.

@jtimon, could you maybe say what you thought would be a good set of parameters for Option 2? I assume this would set the time frame and payment regime for the Foundation funds?
Anyway, option 3 looks bad. One thing there is to learn about the Foundation is that bad optics should be avoided. While the Foundation funds have remained mostly untouched, people had viewed it as a possible scam.  So then we distribute the Foundation funds and the richest people get richer--pure POS. After we multiply all address balances by 5, what then? Where are you going to spend it? Its like you and your friends declaring leaves money then dividing all the leaves in your backyard amoungst each other. At least miners need to pay an electricity bill--that's legitimate economic circulation. (LOL I digress.) Also, we don't want to replace it with another type of Foundation either.
Increasing users and  use for the coin is the end game. With increased use the hash rate fixes itself, money circulates, the value will be more constant etc, and there will be more volunteers and community members! So we want to keep the optics good.
Presently, debating here, we are actually agreeing on important things: 1) the Foundation must end, and 2) that the community is welcome to code and develop things that interests them.  All options 1,2 and 4 are fine. 
 

Maybe kick the can down the road a bit, if its possible? Move the Foundation coins to a time locked contract, spendable after certain day and/or require softfork? If not moved within certain amount of days/blocks -> destroy/redistribute/whatever.

Theres some neat technologies being built and getting realeases in the not-so-far-distant future, so could be useful to have the foundation coins for some use cases which might come available later. From what I understand, sidechains / drivechains will bring a lot of new possibilities for distribution mechanisms and other logics  

Maybe kick the can down the road a bit, if its possible? Move the Foundation coins to a time locked contract, spendable after certain day and/or require softfork? If not moved within certain amount of days/blocks -> destroy/redistribute/whatever.

Theres some neat technologies being built and getting realeases in the not-so-far-distant future, so could be useful to have the foundation coins for some use cases which might come available later. From what I understand, sidechains / drivechains will bring a lot of new possibilities for distribution mechanisms and other logics  

Maybe kick the can down the road a bit, if its possible? Move the Foundation coins to a time locked contract, spendable after certain day and/or require softfork? If not moved within certain amount of days/blocks -> destroy/redistribute/whatever.

Theres some neat technologies being built and getting realeases in the not-so-far-distant future, so could be useful to have the foundation coins for some use cases which might come available later. From what I understand, sidechains / drivechains will bring a lot of new possibilities for distribution mechanisms and other logics  

When Freicoin was launched, we thought the Freicoin Foundation could be a good way to use "excesive rewards to miners" for good causes and to promote Freicoin adoption. Since then, 3 of the people initially in the foundation have distanced themselves from the project (in part, because of the foundation), we haven't been able to keep up even with the matched donations distribution program, which also hasn't move towards a more decentralized implementation (like republicoin) and no other distribution programs have been implemented.     I haven't been maintaining the website properly and Mark hasn't done the matching often enough. We apologize for that.   Many potential users distrust Freicoin "because of the foundation's 'premine'". Sites are often confused about Freicoin's monetary base of 100 M because of the foundation's funds, and people often belive that Freicoin still has inflation on top of the demurrage (but the inflation was supposed to only last the first 3 years).   The foundation has also been a constant source of friction and conflict within the Freicoin community, often demotivating both users and developers when not causing direct confrontation between each other. It has also taken volunteer resources which could have otherwise gone to actual development and innovation.   At this point, I'm convinced that the Foundation has not only not helped Freicoin but actually has done the opposite.   On top of all that, the ecosystem has been invaded with "Initial Coin Offerings" and other schemes which I personally consider scams. And although I think the foundation is very different and not a scam, I'm no longer sure regulators will be able to tell the difference when the time comes. The last thing I had in mind when proposing Freicoin was going to jail because of the foundation (which actually was a later idea, wasn't there in the initial proposal).   We explained that if the foundation ever misbehaved or got their funds stolen, Users could activate a softfork to destroy those funds. The foundation can also destroy those funds unilaterally, but we want to ask the community what would be the preferred way to close the foundation, since there are several ways to achieve this technically.   Since it was promised to match 100% instead of 10% and some more donations were done with that expectation, we can do one last matching (including going from 10% to 100% retroactively as promised) before destroying the remaining funds.   Here are some other options, please,    1) Simply destroy them by sending them to an OP_RETURN output. This has the disadvantage that there will be inflation again and it will take very long until all the 100 M are issued.   2) Turn them back into mining rewards by creating txs only with fees that are locked in time, so that each block can take one. We can decide at which rate they're given to miners and for how long (until they're gone). With this we can get to the 100 M much faster and has the additional advantage that provides more incentive to mine (which is currently extremly low).   3) Distribute proportionally to the current freicoin holders. This has this has the disadvantage that chosing a given time may look unfair. Is it after the final matching, right after, wait for the donation receivers to spend their coins? This may also cause a price crash, but it's hard to tell.   4) Destroy the remaining funds like in option one, but also do a softfork to reduce the current miner subsidy so that instead of the monetary base growing to 100 M, it just remains to whatever it is now without the remaining foundation funds. This requires a consensus change, may cause a hasrate crash (because the incentive for miners will suddenly much lower) and we lose the round and beauty 100 M figure.   My favourite option is number 2, although it has more parameters to discuss.   If anybody thinks of another option, please, share it.   One more time, we apologize for how the foundation was handled, I wish we had never done it in the first place, but this is where we're at.