If you believed two years ago that "Monero is a cutting-edge building block of human liberty", then it is so now.

No other cryptocurrency has displaced Monero in that niche (yes, human liberty is a niche, sadly). People flocked to other niches in turn, but liberty is a timeless attraction, which is sure to bring more people in time. I believed Zerocash could top it, but I am not sure now, mostly because they suffer from similar scaling issues as Monero, and because their privacy is optional, and therefore may be treated as prima facie evidence of wrongful intent. So, for the time being, Monero is no less a cutting-edge building block of human liberty as it was then.

Is CK crucial for Monero ? I cannot tell what would have happened if CK had not been here. However, it often takes not much to push past a threshold which makes something self sustaining. Monero is still around, despite all the naysayers. CK is too. Monero certainly helped CK survive and develop. A growing CK will certainly help Monero grow, though at which size this becomes substantial, I do not know.

In the end, as I said on wednesday, as many other things, you can't know whether you will succeed, but you know that if you do not persevere, you will not succeed. I intend to persevere with Monero.

For now, I'll continue working on finishing the RingCT integration and related bits, without defined time constraints.
Once the summer is out, I might go for another similar contract.

simplewallet now skips refresh till the block the wallet was created, so there must be a bug that makes it think it doesn't need to refresh those early blocks. File a bug on https://github.com/monero-project/bitmonero with the exact command line you use (placeholders are ok for addresses etc) and we'll fix soon.

That's a bug. It's supposed to bind to loopback if you don't supply --rpc-bind-ip with another one. I will fix.

Edit: works fine here. Either that server was specifically told to listen inbound, or if you can repro it, file a bug with full command line and OS etc.

I'd misread. This is normal that a newer wallet cache can't be read by older simplewallet. There's new stuff added in that the old code can't understand. It'd be theoretically possible to keep forward compatibility though.

What I'm really interested in is whether newer code can't open an older wallet. That would need fixing.

Do you remember the commit hash you had last saved this wallet cache with ? If so, which ?

Do you have any other error with "MDB_MAP_FULL" before that error, or on a previous run ?

Are you running a 32 bit version ?

I was recently prodded again about a new github feature, which allows people to upload their public key to github, which allows github to check a commit's signature and display a "verified" label near a commit. I didn't really want to upload my key, because this totally defeats the purpose of GPG keys, since you're relying on a third party to check keys for you and tell you that, honest, they checked it for you, and it's fine. This is vulnerable to github being pwned, the contributor's github account being compromised, your connection being MITM'd, etc.

I created a script that checks signatures before building, which if vulnerable to only a subset of the above vulnerabilities. This script is not in the monero tree (since an attacker compromising the tree or github can just replace it for you to run next), and is meant for you to drop in your existing monero tree, and run it from there instead of make. It runs make after checking signatures (and exits without running make if anything fails).

To use it, replace "make" with "./checkmake.sh" (or checkmake.sh if you copy the script to somewhere in your PATH). The first time you use it, you need to add --update-keys, which will copy the public keys from the monero tree to a specialplace. If and when a new key is added to the monero tree, you can run ./checkmake.sh --update-kes again if and when you're satisfied this key is legit. This is not done automatically since an attacker compromising github or a contributor's account could just add a new public key to the tree with a signature matching that one.

To start using this script, save it (and not copy/paste it, to be sure you get the exact data) from https://paste.fedoraproject.org/382787/46654137/raw/, and check its signature from https://paste.fedoraproject.org/383014/58223714/raw/, which should be a good signature from my key which is in the monero tree: gpg --verify checkmake.sh.asc. If you don't have my key already in gpg: gpg --import utils/gpg_keys/moneromooo.asc. Once the signature is checked to be good from that key (4D6CEFC3), you can run it as above. If my key checks out but warns about the key not being trusted, this is fine, it is because you did not tell gpg to trust the key.

You cannot. You start with a set point of health, and the weekly health challenge is here for you to prevent as much fall in that health as you can. What you lose is lost, and cannot be recovered. By doing good in the health challenges, you can decrease the speed at which you lose health, or even stop it altogether as long as you being each health challenge to none, but you can not make it go up again.

There are currently no other downsides to being ailing though, it just is a description of roughly how much health is left in your "life bar".

I agree with DaveyJones. The constant stridency has got old ages ago already.

The Jewelry editor is now live.
Find it at "Master Goldsmith" on the left menu.

Let's see who will win the coronet competition (assuming HM Zechriah chooses not to compete).

Yes. The point is that the account tree is a snapshot of the state of the currency at a given point in time, so all transactions that were made in order to get to this snapshot are redundant. From an account tree, you need only the set of blocks since that snapshot in order to reconstruct the history since then.
Now, I don't know how one goes about verifying this account tree truly reflects the real history, so you'll have to wait for Bitfreak! to get around to that.

And yes, Cryptonite is a really nice coin in many ways

Proride, this was a bug, and the 4 logs you pointed out have been reverted.

Sorry about that. The bug is said to be fixed now.

This is the same item for both transactions, a buy and a sell, and both for the same price (2.5mil per coin). This means you'd have had to have both a buy and a sell order at the same price, and that isn't possible at the same time I think. So some kind of bug. I will ask PJ.

To all NPCC contestants: to try and make it fairer for all, I will transfer 3 days' worth (today and the previous two days) of stipend at 12 GMT (so in 4 hours from this post), so that everyone has a chance to start at the same time. Those that don't sleep anyway, but you can only do so much.

I do not care much what it is you are trying to hype this time.
My point is just that you persist in the hawking, and do nothing. If you continue doing this, you will end up frustrated and angry, and without having helped humanity.
A proof allows others to build upon, find flaws, and better what you are working on, so you can in turn find flaws, and better it. This is the whole point of free software. We stand on the shoulders of giants. I invite you to try to do so as well. I think everyone would gain from it.

And, sadly, the margin of this forum is too small to include the proof.

Should you one day find a margin large enough to contain substantial reviewable work in your lengthy tribulations through the Internet, give us a shout.

I can't wait for the pistol contests. I've started training daily, and will enter the three competitions (thanks to HM for lessening the original requirements for half section category).

DIA5, here I come!

I sent that bug to PJ, but he was away for the last few days though. Hopefully it will be fixed soon.

When the Duke of North Face's troops reach the Stonehaven camp, the bulk of the garrison (71 BV, 100% mobility, 4 PIS) will move north with the Duke. The remainder (26 BV, 2 CANN, 4 MKT) will stay, along with the Knights Templar (67 BV) who had come for the short skirmishes with Sweden, and who had never actually gone back to Cryptotown since.

The detachment will then work with the NF and Tavastia troops to find the marauders and chase them back to the east and into HM's waiting trap.

Then, the troops will likely reinforce the Duke's expedition to Louhi's territory, or come back to Stonehaven, depending on how things transpire.