Jump to content

fedde

Administrators
  • Content Count

    673
  • Joined

  • Last visited

  • Days Won

    70

Reputation Activity

  1. Upvote
    fedde reacted to Mark Friedenbach in New release: v0.8.6.2-5   
    Yup, pushed the code for the next release: v0.9.5.0-6. Everything seems good on my end.. just wanted to pull the release notes together for an official announcement. It's usable if you want to upgrade though. In fact, I'd highly recommend it as it comes with significant security updates.
    I've updated the download links on the main website for the gitian-built binaries. Also in the good news: macOS builds are back.
  2. Upvote
    fedde got a reaction from Fabrizio in Changing the proof of work algorithm   
    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. 
  3. Upvote
    fedde got a reaction from Fabrizio in Working DNS Seeder   
    Ok, the dnsseed.sicanet.net has been running the past years, still working good ?
  4. Upvote
    fedde got a reaction from Skaro in Changing the proof of work algorithm   
    This is interesting as most gear has lifetime about 1-2 years so if it can be done over a time period I think it would be positive. 
    As pool runner i assume we can run two pools, one for each algorithm? 
  5. Upvote
    fedde got a reaction from Skaro in Changing the proof of work algorithm   
    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. 
  6. Upvote
    fedde got a reaction from Arcurus in [FreiExchange] - News and Updates   
    I spoke with the Manna coin guys a while ago, will check back on the contact to see if we can get it listed.
  7. Like
    fedde got a reaction from Arcurus in [FreiExchange] - News and Updates   
    MANNA added 
    https://freiexchange.com/market/MANNA/BTC
     
  8. Like
    fedde got a reaction from Bicknellski in MANNA?   
    Manna is added
  9. Like
    fedde got a reaction from Bicknellski in [FreiExchange] - News and Updates   
    MANNA added 
    https://freiexchange.com/market/MANNA/BTC
     
  10. Like
    fedde got a reaction from Bicknellski in [FreiExchange] - News and Updates   
    I spoke with the Manna coin guys a while ago, will check back on the contact to see if we can get it listed.
  11. Like
    fedde got a reaction from Rik8119 in [FreiExchange] - News and Updates   
    I spoke with the Manna coin guys a while ago, will check back on the contact to see if we can get it listed.
  12. Upvote
    fedde reacted to Rik8119 in [FreiExchange] - News and Updates   
    Hi everybody,
    i made a small app where you can check the prices of the different coins.
    Sourcecode is not online yet. But i will post as soon as possible.
    Rik
     
    FXchecker[1].apk
  13. Upvote
    fedde reacted to Bicknellski in Making freicoind faster and safer with fewer dependencies (simpler demurrage calculations)   
    Thanks for the update and info. 
     
  14. Upvote
    fedde reacted to Mark Friedenbach in Making freicoind faster and safer with fewer dependencies (simpler demurrage calculations)   
    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.
  15. Upvote
    fedde reacted to Arcurus in Making freicoind faster and safer with fewer dependencies (simpler demurrage calculations)   
    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?
     
  16. Upvote
    fedde reacted to Mark Friedenbach in Making freicoind faster and safer with fewer dependencies (simpler demurrage calculations)   
    > 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.
  17. Upvote
    fedde got a reaction from Arcurus in Development update   
    Merry xmas to you and your family Mark! It's been a exciting year and with this update it looks like it can be even more fun  
    Take care and looking forward on some updates, let me know when some testing is needed.
    And of course, a happy new year!
  18. Upvote
    fedde got a reaction from Skaro in Development update   
    Merry xmas to you and your family Mark! It's been a exciting year and with this update it looks like it can be even more fun  
    Take care and looking forward on some updates, let me know when some testing is needed.
    And of course, a happy new year!
  19. Upvote
    fedde reacted to Rik8119 in Merry Xmas   
    Hi, to you and everybody else also merry christmas.
    For anyone who want an additional UBI in #Solidar please follow us on twitter www.twitter/WINC_ev for the chance to win 10 Solidar tomorrow. ;-)
    Greetings Rik
  20. Like
    fedde got a reaction from Rik8119 in Merry Xmas   
    Wish you all a merry xmas and like the other year, lets make 2018 the freicoin year  

  21. Upvote
    fedde got a reaction from Bicknellski in [FreiExchange] - News and Updates   
    Hi all
    We have added ANC/BTC to the trading - Welcome
    New coins can request to be added on https://freiexchange.com/pages/coin_request 
    Api has been updated with abit more info on each trade pair.
    We continue development to extend the exchange with more functionality over the next few weeks. More of this later.
  22. Like
    fedde got a reaction from Rik8119 in [FreiExchange] - News and Updates   
    Hi all
    We have added ANC/BTC to the trading - Welcome
    New coins can request to be added on https://freiexchange.com/pages/coin_request 
    Api has been updated with abit more info on each trade pair.
    We continue development to extend the exchange with more functionality over the next few weeks. More of this later.
  23. Like
    fedde got a reaction from Bicknellski in Website Updates   
    Forum updated and moved to new server. 
  24. Upvote
    fedde reacted to Bicknellski in Big Picture Montessori School Project - Precious Plastic Workspace   
    We would love to use WNC input on this. I will be taking some time with students probably until March 2018 to plan this out. I'm looking at getting a small box truck to hold all the equipment so this could be a rolling Precious Plastic workspace so we can go to other communities and schools to do recycling.
    http://olx.co.id/iklan/toyota-truk-engkel-dyna-box-115-st-besi-4-roda-th-2004-murah-bagus-IDrPJ6h.html#6309a49e34
     
  25. Upvote
    fedde got a reaction from Rik8119 in FireRoosterCoin has taken the FRC shortcode.   
    Hi All
    How should we deal with that another coin has taken the FRC shortcode?
    https://bitcointalk.org/index.php?topic=1764555.0
    It's a premined coin, launced in january 2017. Only listed at cryptopia exchange and is currently making alot of graphs and stats that belong to Freicoin to been taken over by this coin  due to the same shortcode.
    When looking trough their thread on bitcointalk, the coin is dead, probarly due to developer has gotten his cash out from the premine.
    Looking at the graphs at cryptopia, it's been preatty dead there too for a while.
    A good example on how they make use of freicoin's history of exchanges : 
    https://cryptocoincharts.info/coins/show/frc
    Even this after i spoke with people on cryptocoincharts.info about updating with freiexchange/coinmarketcap data so that data is correct, but they favor a scam coin over a established old coin. 
    @Mark Friedenbach
×
×
  • Create New...