Mark Friedenbach

New release: v0.8.6.2-5

Recommended Posts

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/

Share this post


Link to post
Share on other sites

The version numbering scheme changes and I let that go unremarked; my apologies. We had a “v0.8.6-2” release (note the dash). This is a “-4” release. The dash number is / will be an always increasing freicoin build number, and the first three dotted version numbers are the bitcoin release it is based on. Under exceptional circumstances (like now) there will be multiple freicoin releases per bitcoin release. In these cases an additional dotted version number will be added.

Share this post


Link to post
Share on other sites

Well both are necessary--it's important to indicate whether it is the 1st, 2nd, 3rd, etc. released based off the specified bitcoin release. It is also important to indicate the sequential ordering of freicoin releases, which the old numbering scheme lacked. You can look to the last number, which will always be increasing, as the freicoin build number.

Yes, these recent releases are very much a part of the effort to switch to newer bitcoin versions. The reason for these truncation soft-forks are to minimize the size of the freicoin patch against bitcoin and the required dependencies, in order to make it easier to rebase the code against more recent bitcoin versions. Since 0.8 the bitcoin source code has changed considerably between major releases making the rebasing otherwise a quite time consuming effort.

Share this post


Link to post
Share on other sites

yes i understand the numbering now, just for clarity i would suggest to write: “v0.8.6.0-2” instead of  “v0.8.6-2” in this case v0.8.6.1-4  would not look lower if you oversee the - then “v0.8.6.0-2”

Share this post


Link to post
Share on other sites

I've noticed from my logs that people have upgraded. I don't see any blocks being mined with the soft-fork version bit being set. If anyone is running their own mining that doesn't pass through the block template's version number (many don't), be sure to set the nVersion to 0x30000000 / 805306368. Or if it is version bits aware, that is the same as signaling bit #28.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites


Some transactions are not paying demurrage, or there is something wrong with the explorer.

Compare:
http://freicoin.info/address/1Lp6jnNLMjEgHuuEeVgMumN49wZ9RXvvKH
http://freicoin.info/address/1HHkYNxJHwLUTw2kV4EqfP1ivtmUxvWMPi


Notice the reference height is the same in the second one. Did something change in the block structure regarding this?

I''m the one that implemented demurrage in ABE. I haven't seen this before.

 

Share this post


Link to post
Share on other sites

I didn't realize demurrage was implemented inside of ABE. The RPCs report transaction values and demurrage a little bit more intelligently. Part of why I haven't made a new topic yet is I need to update the release notes to explain better how they work now. What it was doing before really didn't make any sense -- when looking at historical data it would show the transaction 'value' as the present adjusted value, and demurrage wasn't reported or worse it was part of the fee, etc.

Now if you are using a certain wallet RPCs (getbalance with no arguments, listunspent) it will show the present value, as this is what is available for spend. But otherwise it shows the value at the refheight of the transaction, and specifies what that refheight is. For inputs/spends, it reports BOTH fee and demurrage separately.

So if you call 'gettransaction txid' is will tell you the sum of the outputs (no adjustment to present value), the specified ref height, and both the value in, fee, and demurrage components of the input separately. If you call 'getbalance' it will tell you the currently spendable amount as of the height of the next block. But if you call 'getbalance account' (including 'getbalance *') it will tell you the total received without adjusting for demurrage. This actually makes accounts useful, but probably isn't relevant to the explorer.

So you probably don't need to do the demurrage calculation yourself, and should just fix the explorer to use the values output by Freicoin now. It sounds like you were fixing it yourself before, and Freicoin should be reporting it in a useful form now.

Share this post


Link to post
Share on other sites

But wait. In the above examples, there were 9 transactions in one block. 8 didn't calculate demurrage but the 9th did, in the exlorer. In more recent blocks, the demurrage calculated okay. 

How could they be different?

.Also, I thought ABE read the .DAT files directly. I thought that meant it wasn't using an RPC (I have limited knowledge on this poin\t)

(If you are looking at ABE, the 'blocks'' and 'account' views are correct, but I never fixed the 'transactions' view')

Share this post


Link to post
Share on other sites

Look at the reference heights--they're the same. There's no demurrage if the reference height of the tx is the same as its inputs. Someone probably manually created these transactions.

I'm not sure how ABE works to be honest. Just noticed that when you click on a transaction, the "Fee" field includes the demurrage. Maybe this is a long-standing bug in ABE I just didn't know about.

Share this post


Link to post
Share on other sites

Yes, when you click on 'transaction', that view is wrong. I know how to fix it, I just never got around to it. I simply didn't realize it needed adjustment the first time around.

The public key summary and the block view were what I modified.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now