Arcurus

My work on Solidar website is finished. I created a new logo, I updated the graphics, I updated all the contents, adapting ones from the Freicoin site and forum. Now the website is also ready to be multilingual, but before translating it in italian, I wish to be sure that all the contents are correct. Please review them and let me know. 

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.    
 

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

IMHO the question is who decides what to support. I think this could be done best and most transparent by local governments. The idea that lives in my mind is to split the payment 50/50 between UBI for people and "UBI for communities" (Amount of people define the payout amount). This way the acceptance of the currency can be maximized. We are competing with the USD directly, so we need all the support we can get.
@Bicknellski, there is a very easy way to reduce energy consumption for mining to a sustainable level: Reduce profitability by splitting mining reward like it was with Freidoin and is still with Solidar. Other things that could be done is POS or a mix. Or some alternative like circles or circarda are trying. Although the most convenient  i heard of is the split payment. Problem here: its not decentralized. But there are many ideas - like identifying people decentralized. Although it will took some time for one of these alternatives to prove itself, we will adopt as soon as there is a well-tried solution.

nice. 
Maybe it would be good to list by default only outgoing foundation transactions.

I spoke with the Manna coin guys a while ago, will check back on the contact to see if we can get it listed.

MANNA added 
https://freiexchange.com/market/MANNA/BTC
 

Update: Release v0.8.6.2-5 has been posted to the freicoin website. This is a maintenance-only release that has no new features. Rather, it only takes the final step of stripping out the dependency on GNU MP and MPFR entirely, such that they are no longer needed even as build-time requirements.
Notes for v0.8.6.1-4: There’s been a new release posted to the official freicoin website: v0.8.6.1-4. This release introduces the new integer-math-only demurrage calculation code as a soft-fork change to the consensus rules — the approximations in the integer math can make the result differ from the previous multi-precision floating point implementation by as much as 1 kria per input, although this error is biased in the direction that makes it soft-fork compatible with the old code. It does mean however that after activation any non-upgraded wallet code creating zero-fee transactions under the old rules is likely to create an invalid transaction. So upgrading (or paying fee) is mandatory!
This new release includes activation logic to switch over to this new integer math code path in the consensus rules once there is supermajority support by the miners, OR at block height 229376, which is about 6 weeks away. Please be sure to upgrade by then!
You can download official freicoin binaries and source code here:
http://freico.in/download/

yes, i agree, that in an system with price inflation people have to argue for higher salaries to get more or less the same while a stable currency or a demurrage based currency prices may stay more stable, therefore employees don't need to argue to get inflation increase of their salary.
To the other part, lower wages must not lead necessarily to less productivity, or higher prices, most likely its the other way round, lower wages would lead to more employment, because less cost and lower prices, because less money too spend (not counting the money inflation itself).
What an UBI would change is that more people would have access to money, therefore the money would not that much accumulate in certain regions / people, therefore salaries are expected to be more even in regions / city / land and globally (also it would even out between poor and rich communities).
I think in the end the UBI should not be financed completely from the demurrage or money inflation, instead it should be financed from the rent on property (stocks) as described above (see former post).
To the UBI itself, i dont know if it is good to give all the money out for nothing. I think we must make experiments what is the best way to give out the money. For sure people must have a guaranteed access to money, so that they can take part in the economy if they wish so.
Different possibilities to distribute the money could be for example:
1. Direct without any conditions
2. Require to do certain work
3. Give as bonus for buying products (see freipay project)
4. give as bonus for certain investments / credits (see freiinvest project).
 
Because its the easiest way i think its good to start with 1. and then slowly add / test other methods.
 
To demurrage or inflation:
Currently i think the best money system would be with neither demurrage or price inflation. Just take a stable currency as described in the post above.
In the beginning if the economy of this currency grows there is to be expected lot of money which must be generated to guarantee price stability.
Part of this money could be used to buy stocks / coins / property and then rent it out (for example on the blockchain itself).
This rent is then used to guarantee that all people have a fair access to money.
In case of price inflation, the rent could be used to buy back the currency and therefore stabilize the prices.
 
 

Hi Rik,
to inflation vs demurrage and the above article.
What is currently happening / not happening  in the system like wage increases cannot be compared to a system which distributes the newly generated money directly to the people.
I'm not so much talking about basic income, im talking about fair access to money.
Currently the newly generated fiat money accumulates with few people  because it is generated by giving out loans and by directly buying stocks and properties.
But simply giving out new loans does not increase the need for new products, because the money goes only to few, therefore does not increase product prices or product demand (except stocks and property prices), therefore does not increase salaries.
It even reduces the product prices, because currently there is low interest on loans, therefore the cost of a product which comes from interest costs (currently around about 1/3), reduces, therefore we don't see much rising prices even with the money supply drastically increased.
This is the current system, another system would be if the newly generated money goes directly to the people.
In this case the purchasing power of the people will increase, therefore the prices will increase or more products will be asked for, therefore companies will be required to hire more people (except the automation is too much influencing already) therefore the wages will increase.
This would be totally another system compared to the system described above.
Yes in this system there will be an inflation in the long run, but if the interest is near the inflation plus a certain risk for not getting the credit back, then this system could function for eternity, because money would not accumulate that much (not considering other tendencies that lead to money accumulation like property / stock income, thats another story that must be solved in a fair system).
The question is now, what is the benefit from a demurrage, vs inflation, vs fully price stable currency.
 
Demurrage would in the long run keep the product prices more stable, while an inflation based currency will increase the name value of the products slowly according to the inflation.
Therefore demurrage based money would be a slightly better unit of account, but this accounting effect could also be easily calculated in if you do accounting.
Using paper money in an demurrage based system could be tricky.
Another difference of demurrage money would be that salaries would not be by default inflated, therefore employees would not need to bargain to increase their wages each year to have the same after inflation.
Inflation based money would once in a while have to get rid of some zeros, while demurrage based money could have the need to add some zeros if the production grows.
 
I think the most fair system would be if the inflation is equal to the production / economy growth, in this case there would not be an price inflation at all.
Newly generated money should go directly to the people so that they have fair access to money and directly as zero interest loans to small / medium enterprises, and to buy properties (see below).
In case of an price increase the money from the loan payback could be used to reduce the money supply and therefore guarantee a stable money / unit of account with aimed 0% inflation or deflation.
 
In this system, money itself would not accumulate through interest. Of course accumulation of money / property through stocks and properties must be still fixed to have a fair system.
This could be implemented gradually through using newly generated money for buying up property and stocks. This property and stocks can then be rented out for X% with X guaranteeing that all people have fair access to property.
 
All other taxes, except for environmental / guiding taxes like on chemicals, drugs, advertisements, harming products could be abolished step by step.
The system itself would be self balancing, so no need for inheritance taxes or income taxes.
Thats it, hope not too long

By the way Bick, we have allready a Manna forum since long time here, the name is just outdated
(Manna was formerly Grantcoin)
 

i guess manna will reach this year already 100.000  people if they manage to scale up to the demand.
Only thing i worry about is, that they have a similar problem like  we have with with the Freicoin Foundation.
Currently their Foundation holds a big part of the available manna (true market cap must be so 100 million already).
Also the current manna wallets are on a centralized server. both could be hacked....
Of course with one exchange currently its easy to make the hack undone, but would destroy some trust...
 
 

Fedde said he wants to add Manna...
I like manna very very much. Currently They are the leading basic income currency.
I hope that Fedde will add Manna soon, i think Manna is very promising, except we finally manage to start our basic income project
Manna currently has only one exchange, if we add Manna now we could make freiexchange to the most liquid manna exchange!
 
All the good,
Martin
P.s.: Im in contact with some of them, and they seem to be very nice and welcoming!
Disclaimer, im for sure invested currently in Manna
 

Hi Rik,
to inflation vs demurrage and the above article.
What is currently happening / not happening  in the system like wage increases cannot be compared to a system which distributes the newly generated money directly to the people.
I'm not so much talking about basic income, im talking about fair access to money.
Currently the newly generated fiat money accumulates with few people  because it is generated by giving out loans and by directly buying stocks and properties.
But simply giving out new loans does not increase the need for new products, because the money goes only to few, therefore does not increase product prices or product demand (except stocks and property prices), therefore does not increase salaries.
It even reduces the product prices, because currently there is low interest on loans, therefore the cost of a product which comes from interest costs (currently around about 1/3), reduces, therefore we don't see much rising prices even with the money supply drastically increased.
This is the current system, another system would be if the newly generated money goes directly to the people.
In this case the purchasing power of the people will increase, therefore the prices will increase or more products will be asked for, therefore companies will be required to hire more people (except the automation is too much influencing already) therefore the wages will increase.
This would be totally another system compared to the system described above.
Yes in this system there will be an inflation in the long run, but if the interest is near the inflation plus a certain risk for not getting the credit back, then this system could function for eternity, because money would not accumulate that much (not considering other tendencies that lead to money accumulation like property / stock income, thats another story that must be solved in a fair system).
The question is now, what is the benefit from a demurrage, vs inflation, vs fully price stable currency.
 
Demurrage would in the long run keep the product prices more stable, while an inflation based currency will increase the name value of the products slowly according to the inflation.
Therefore demurrage based money would be a slightly better unit of account, but this accounting effect could also be easily calculated in if you do accounting.
Using paper money in an demurrage based system could be tricky.
Another difference of demurrage money would be that salaries would not be by default inflated, therefore employees would not need to bargain to increase their wages each year to have the same after inflation.
Inflation based money would once in a while have to get rid of some zeros, while demurrage based money could have the need to add some zeros if the production grows.
 
I think the most fair system would be if the inflation is equal to the production / economy growth, in this case there would not be an price inflation at all.
Newly generated money should go directly to the people so that they have fair access to money and directly as zero interest loans to small / medium enterprises, and to buy properties (see below).
In case of an price increase the money from the loan payback could be used to reduce the money supply and therefore guarantee a stable money / unit of account with aimed 0% inflation or deflation.
 
In this system, money itself would not accumulate through interest. Of course accumulation of money / property through stocks and properties must be still fixed to have a fair system.
This could be implemented gradually through using newly generated money for buying up property and stocks. This property and stocks can then be rented out for X% with X guaranteeing that all people have fair access to property.
 
All other taxes, except for environmental / guiding taxes like on chemicals, drugs, advertisements, harming products could be abolished step by step.
The system itself would be self balancing, so no need for inheritance taxes or income taxes.
Thats it, hope not too long

https://www.mannabase.com/?ref=gmrvvtenkr

I got some manna did you get some manna. Is Manna on our exchange?

Freirepublic could be really what makes Freicoin different to other coins.
 
I would do it for example like this:
Implement Freirepublic in a second layer like for example dash does it.
 
Second layer could look like this:
A part of the block reward + fees lets say 80% is distributed according to the votes. (can be phased in starting by 20%)
To vote the demurraged coins are used.
You can vote pro and con for a project.
Each month the X top voted projects receive coins relative to the amount of votes (pro-con) they received.
 
Enforcement could look like this:
Demurraged coins can be used to vote pro or con a sentry (masternode).
Top X (pro-con) voted sentries (masternodes). each month are added for at least one year.
Each sentry (masternode). has votes according to pro votes - negative votes.
Max number of votes per sentry (masternode) can be limited.
Sentry (masternode) get Y% of the mining reward (can be phased in starting by 20%)
Consensus is reached over a valid block either like in dash or like in stellar.
 
If layer two fails, fallback is layer one like in dash.
 
 
UPDATE:
one thing i would add: Votes count 100% after one week time period 1/7 after one day. After one year votes are not valid anymore (phased out in one month).
 
UPDATE:
I was thinking about the enforcement. In away we could start without having something like frei / masternodes at start. At worst it behaves like all goes to the miners if miners block votes therefore at worst we are there where we are now. In case of vote blocking through miners. A single tool which tracks vote censoring should be enough to reject blocks from miners that dont include known voting transactions. This could be added as softfork later if needed. 

thx for your work!
I have some questions to the implementation of demurrage in Freicoin:
Is there still a need to have a refheight in the Freicoin transaction if so why?
Is the demurrage calculated on the uxto set, or on the transactions itself?
If on the transaction itself is then pruning of old transactions possible in Freicoin?
 

> 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.

thx for your work!
I have some questions to the implementation of demurrage in Freicoin:
Is there still a need to have a refheight in the Freicoin transaction if so why?
Is the demurrage calculated on the uxto set, or on the transactions itself?
If on the transaction itself is then pruning of old transactions possible in Freicoin?
 

Hellow everyone!
I'd just like to present myself to the community. I still quite new to cryptos, but I'm facinated by them. I'm also very interested on universal income. It was a mind blow for me to mix both into one faierer economic system! By chance I got to Solidar with that, and Solidar brought me to Freicoin as well.
I hope to learn a lot here and hopefully be of some good use =)

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.

some feedback to the new website:
I would focus on the first page on the registration to the universal dividend.
Just look at google, keep it simple and focus on the most important.
What we want is sign ups!
I would also add a counter on the signed up people, thats what we want to increase
I would also describe the basic data, like coins in circulation, coins given out in UD last month, UD per month.

maybe because its far tooo big? Better use some wallet that dont need to download the full chain.

maybe because its far tooo big? Better use some wallet that dont need to download the full chain.

Welcome to the worlds 1st super computer on the blockchain!