New release: v0.8.6.2-5

[Mark Friedenbach 92]

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/

[Skaro 129]

Installed it!

And we no longer have the .exe 64 bit not working problems!

[Arcurus 331]

Just one question, wasnt the old Freicoin client version 8.6.2 already? 

[Mark Friedenbach 92]

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.

[Arcurus 331]

ah, in this case better name v0.8.6.0-2

by the way, do you plan to switch to the new bitcoin version?

[Mark Friedenbach 92]

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.

[Arcurus 331]

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”

[Mark Friedenbach 92]

Ah, I see, and I understand your point now. Alternatively though, since nearly every single release is going to be "vBitcoin.0-Freicoin" does it make sense to drop the ".0" except when it is used (nonzero)?

[Arcurus 331]

as said, it could look confusing what the newest version is, if someone oversees the -

[Mark Friedenbach 92]

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.

[Mark Friedenbach 92]

Given the recent rise in hash rate, the soft-fork seems very likely to activate today.

[Mark Friedenbach 92]

Soft-fork activated on block 225687, no issues reported.

[Mark Friedenbach 92]

Edited first post in this topic to note the release of v0.8.6.2-5.

[Skaro 129]

I see a lot of action going on the GitHub site! wow. cool. Thank you for your efforts.

[Mark Friedenbach 92]

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.

[Skaro 129]

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.

 

[Mark Friedenbach 92]

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.

[Skaro 129]

Okay. looks like my work just became obsolete. Mixed feelings. On the positive side, I like progress, and I got away with the bounty!

[Mark Friedenbach 92]

Well it looks like some work needs to be done to separate fee from demurrage in ABE explorer. But Freicoin integration should be much easier now.

[Skaro 129]

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')

[Mark Friedenbach 92]

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.

[Skaro 129]

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.

[Skaro 129]

So I fixed the transactions page on ABE this morning. It still has to be pushed though.