On https://github.com/monero-project/bitmonero/commits/master

Assumes facts not in evidence.

And another update:

The in-tree crypto code can now be regenerated from an authoritative source from Dan Bernstein, to ensure no extraneous changes were inserted.

Transaction keys can now optionally be saved to the cache file (which is now also encrypted too). If you enable this (set store-tx-keys 1), you can use the get_tx_key command to recover them afterwards. There is no tooling yet to make use of them, however.

Several changes were made to the new blockchain code to bring it closer to the original code where appropriate, to diminish the risk of unintended fork.

Misc fixes to compilation, to log filename creation, warning fixes, and other misc stuff. Oh, and libunbound was updated to a newer version. Didn't fix the lingering issue with leaking file descriptors though.

120

For those who can get this on Linux, the output of this command might help, executed after you see such a message (assuming bitmonerod doesn't die just after the error):

ls -l /proc/`pidof bitmonerod`/fd

Back up now. Sorry about that, my ISP hiccuped and the dynamic DNS update did not trigger automatically this time.

Thanks, merged, signed, and pushed.

Addresses generated earlier are still totally valid of course, and can be restored with simplewallet.

Two points of interest:

- a moving min reward like this might cause delayed transactions to be spuriously rejected, if the min fee increases just after the tx is broadcasted. Maybe some kind of slack is warranted. However, if some slack is allowed, it is expected that some people will pay fees taking the slack into account, nnullifying the slack.

- some people might decide to "bet" on decreasing fees, and delay transactions till they can be sent with a lower fee. This might have knock on effects on the blockchain utilization: both in instantaneous decreased use, and burst use when the fees goes down.

I am honored by the trust His Majesty affords me, and will be glad to accept this nomination to the City Council, at gold holders' pleasure. I do not have such a thorough knowledge of all the city's rules as do other councillors, but will try my best to help the council steward the city's future.

Yes, I had to, as the balance on what I assume is your address was too large to get in a single tx when done by the pool itself, so I transferred manually in smaller chunks over a couple hours as coins unlocked. Hopefully without mistake

Always happens when I don't look for a bit...
Should fix itself again as consolidated coins unlock.

As for a guide for pools, there's a comprehensive guide in the pool software's documentation itself.

I updated aeonpool.mooo.com a bit:
- min payment bumped from half an aeon to one aeon - keep smaller outputs in check
- 0.5% donation fee to the dev address is back

The late night conversation at the King's jubilee party had been fuelled by wine and excellent cognac. Naturally, the subject veered from cognac to noble spirits in general, and ended up settling down on rum. Among the laughs and tall stories, a few revellers mounted a daring plan to launch an expedition across the seas in search of a famed source of most excellent rum.
 
Born in a family of fishermen and cattle owners, Mooo had spent years both at sea and in the countryside, and was familiar with sailing. He knew exactly where to find the kind of ship that the Duke of North Face and the Earl of White Cross were talking about. A merchant company near Mooo's native town operated a few of those hulking beasts, renting them out to merchants for both regular and one off trips. As it turned out, several of them had been waiting at dock for some time, and the proprietor was glad to find a customer at last.

As the ship's crew started to prepare the ship for another voyage, Mooo hurried back to Cryptotown with the news of the cheap availability of the merchantman.

Thanks for the kind words

To answer a few points that were made above:

I committed to a low enough number of hours that I felt comfortable with. It's difficult to be confident I won't burn out in two years, for instance (the original request was looking for a full time coder for two years). When that committed time has been spent working on monero, I will know whether I can commit to more. Pretty likely, but I want to be conservative here.

I was surprised to see none of the current core team people step up on that offer. However, someone (can't recall who) had mentioned maybe nobody wanted to be the guinea pig for this. Maybe one of more of them will in the future. Since there's no infinite supply of monero, they'd take precedence if they wanted to have a go at it.

While predicting the future is difficult at best, I expect that when those committed hours are spent, I will continue hacking on monero in my spare time anyway, just not as much.

I had a large chunk of free time recently, and I could devote a large part of the last few days to Monero. I'd originally picked a guideline of 10 hours a week on average as something I felt was doable, but it looks like I'll be done before the six months guideline.

No, you're not the only one.

mrkavaski too

Mooo wonders how many MO1600C coins he still has. The lock on the chest containing most of these is stuck, preventing him from checking, but he's pretty sure there are a few left, so he wraps one of the few coins not in the chest and heads to the royal castle to enter it in the coming raffle.

Mooo donates a MO1600C (p.o.) to the raffle.

Quick overview of recent changes to master since last time:

Payment IDs can now be encrypted. Those are now 64 bit on the blockchain. Integrated addresses are changed to use these (so integrated addresses generated before that change are now invalid, in case someone tried those from git). Full size plaintext payment IDs are still possible.

Input selection now uses the triangular distribution (prefering newer outpts). Previously this was only used for the old blockchain format.

A couple fixes to possible behavioral differences between old blockchain and new blockchain, which could have caused an inadvertent fork on corner cases.

A new rescan_spent simplewallet command, which queries the daemon for the wallet's outputs spent status. This is intended to fix the need to rescan the blockchain when a tx does not go through after being accepted by the daemon. Note that this command leaks info about which outputs you own to the daemon, so it is not to be used if you connect to a third party daemon.

And the usual set of random smaller fixes and tweaks.

This whole VNL copyright copyright infringement and obfuscation is very interesting. I'd thought this was a very interesting coin, even if the zero confirmation whitepaper I'd ready seemed to not include any technical details, but I'd chalked that down on not having read the initial whitepaper, and assumed the tech details were implied to be there.

So thanks for the word of warning, Traumschiff, smooth, erok. Doesn't mean it's necessarily all bad, but it certainly casts this in another light.

Reminder and warning to miners:

Please do NOT mine on my pool with an exchange address. In order to know a payment is from you, exchanges need a payment id, and my pool does not support custom payment ids on payouts, so the coins will get to the exchange without being tagged as being for you.

If you want to mine, please mine to your own wallet, where a payment id is not needed.

Additionally, there is another pool at http://52.8.47.33:8080/ when mine approaches 50% (as it is now).

And it is now rising again, and close to 50%.
Some may want to consider solo mining, or pool mining on http://52.8.47.33:8080/  - not all of you though .