Ignore VIRT, it's mostly useless for memory usage indications.

http://serverfault.com/questions/122810/apache-heavy-load-virt-vs-res-memory
http://stackoverflow.com/questions/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

You definitely used the same login key each time, right? If so, then it sounds like the VPN is doing something funny. The only time it would show you a different address is if your seed / keys were modified by poisoned Javascript. I'd be VERY nervous using that VPN.

There's no such thing as pending_timeout, are you thinking of something else?

Transactions fall out of the mempool 24 hours after the local node's receive_time for that tx, the issue is that a handful of these transactions are perpetually stuck because, as you correctly state, you'll receive the transaction again if it's out your mempool and a node rebroadcasts it (there are various conditions under which this can occur).

The larger issue was a bug that allowed valid post-March-fork transactions to enter the mempool in its pre-March-fork state. That has been fixed, and we will put out a point release this week pending one other fix, as discussed in the Monero Dev Meeting this past Sunday.

FYI, cross-posting from: Want to help Monero? We're trying to find a Mozillian that can champion our project to Mozilla.

We know where it is relative to master; the context is that we need to establish what regressions we've introduced to 0MQ (if any).

So "state" refers to "regression state", "buildable state", and "releaseable state".

For this that are interested, here are the logs from the dev meeting. Someone is working on an overview if you don't feel like reading the whole thing.

<fluffypony>  who are we missing 
<fluffypony>  tewinget / othe / warptangent / NoodleDoodle you guys around? 
<warptangent>  ^ 
<fluffypony>  hokay 
<dEBRUYNE>  smooth? 
<fluffypony>  smooth and luigi1111w are around 
<fluffypony>  although luigi1111w is using some other nick 
<fluffypony>  luigi1112 I think 
<luigi1114>  4 
<moneromooo>  mario1114 
<fluffypony>  lol 
<fluffypony>  about a year ago we did this using TeamSpeak 
<fluffypony>  I mean Mumble 
<luigi1114>  for you guys 
<fluffypony>  which was nice, but it isn't as fluid as typing because sometimes you can't hear that someone else is talking 
<binaryFate>  Firechat? Was cool 
<fluffypony>  binaryFate: no we did a couple of actual dev meetings   
<fluffypony>  but it's tough to sustain 
<binaryFate>  Oh ok 
<xmrpromotions>  I think typing is fine too. 
<ArticMine>  This is fine 
<fluffypony>  agreed 
<fluffypony>  plus there are people working on Monero that would prefer not to have to use a voice changer just to participate :-P 
<fluffypony>  ok so there are a few things on the agenda   
<luigi1111>  I'm sick so my voice is already changed 
<warptangent>  the format seems to have been working well for kovri too 
<fluffypony>  the first thing I think we should discuss is the dev branch   
<fluffypony>  we've fallen back into the habit of merging stuff to master 
<moneromooo>  That's because bugs 
<fluffypony>  I know 
<fluffypony>  we're going to have to do a point release to fix the v1/v2 / stuck transactions bugs 
<fluffypony>  are there any bug fixes waiting in the wings, or should we do that next week? 
<moneromooo>  That last commit thing, which I'll have to think about a bit more. 
<moneromooo>  Also, possibly merging the per-tx bits in lmdb. 
<hyc>  which? 
<moneromooo>  tx_{unlocks,heights,outputs} 
<hyc>  ah 
<moneromooo>  And output_{keys,amounts,indices,txs} 
<hyc>  DB format change, I don't think that's a bug-fix 
<moneromooo>  Way more of htose than blocks 
<fluffypony>  maybe we need to consider a more generalised approach to format changes   
<fluffypony>  something like Laravel's migrations 
<fluffypony>  it'll have to be per-DB-format anyway   
<fluffypony>  per-DB-type I mean 
<warptangent>  i've got schema changes i've been using for a couple months, for better use on hdd, but they aren't bug fixes. 
<warptangent>  two sets of bug fixes not yet added though 
<fluffypony>  ok if they're not considered crucial for 0.9.x then we can put them into dev? 
<hyc>  warptangent: since I've been working on the same thing, I guess I should take a look at your stuff 
<warptangent>  1. berkeleydb support for importer - almost ready, some argument usage cleanup 
<moneromooo>  Once I re-merged then 
<hyc>  but I don't consider anything I'm looking at now as bug-fix 
<fluffypony>  (this is how we meeting https://i.imgur.com/OR5ZVoI.jpg) 
<warptangent>  2. finish hf fix for importer - mostly done, pending some cleanup with bdb 
<fluffypony>  hokay 
<hyc>  (I have a wineglass here too, sadly empty) 
<warptangent>  hyc: yes, that would be good. i think i mentioned the tx changes last month to avoid as many subdbs with tx hash keys 
<fluffypony>  also I think the thing that's holding up a general move of effort to dev is that we haven't bundled CZMQ / 0MQ in source, which makes compiling a bit painful 
<fluffypony>  any objections to the bundling? 
<luigi1111>  how much of a pain is it to change formats? 
<hyc>  I haven't even looked at dev. no objection from me 
<fluffypony>  luigi1111w: mostly just requires copying data to a new table and nuking the old one 
<moneromooo>  Hmm. I have a few patches to czmq, to make things build. 
<moneromooo>  Not super sure whether it was me being dumb or not though. 
<fluffypony>  ok well moneromooo, maybe post-bugfix do you want to do the merge from master to dev, and then plonk those patches on? 
<fluffypony>  I'll get it in the source tree the meantime, and cmake-ify all of the things 
<moneromooo>  I'll merge yes. Then you can add zmq to the cmake stuff Then I'll add my patches if they're still needed. 
<moneromooo>  Great, ty 
<fluffypony>  great minds think alike 
<fluffypony>  ok next I'd like us to chat about a style guide 
<fluffypony>  we've been working on one in Kovri that we can possibly use for Monero 
<fluffypony>  https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style 
<hyc>  oh, I do have one outstanding - tweak to BlocchainLMDB::get_estimated_batch_size - change batch_safety_factor to get blockchain_import to succeed on 32bit 
<fluffypony>  not necessary to read the style guide now, just more a general sense of if everyone is comfy with a style guide, and if anyone has any particular preferences   
<smooth>  i have no objection to any reasonable style guide but i do object to re-styling of existing code 
<moneromooo>  Pages and pages of stuff ? :| 
<moneromooo>  I object too, if it's only restyling for the sake of it. 
<fluffypony>  ok so more of a restyle-as-you-go   
<moneromooo>  That massive reindent patch already caused me grief 
<fluffypony>  which is in line with our refactor-as-you-go approach 
<ArticMine>  Apply the style guide to new code 
<smooth>  imo the best policy is keep the style on small chages to existing code and new style on new code 
<smooth>  there is probably a gray area there 
<warptangent>  should we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces. 
<hyc>  agreed 
<fluffypony>  warptangent: that's the one area where we differ from Kovri, I'd lean towards yes 
<moneromooo>  I tend to keep the style of whatever I'm hacking on. And I doubt I'll read all that google style guide thing. I'd prefer we use common sense. 
<warptangent>  moneromooo: style on the current project though, not different styles per file, right? 
<moneromooo>  Whatever code I'm modifying. 
<moneromooo>  It causes the least problems. 
<fluffypony>  moneromooo: don't worry about the Google style guide, the 16 points we've put in for Kovri are more what I was referring to 
<warptangent>  the majority of files are one style in the codebase, with a few that became some kind of hybrid at one point 
<moneromooo>  Oh OK. 
<moneromooo>  With that out of the way... 
<fluffypony>  ok - everyone happy with that as a general starting point? I can dump those points in and then we can take pull requests on it if anyone wants to refine / change things 
<warptangent>  yes, seems good 
<hyc>  I would push harder on "code should go in a .cpp not .h" 
<fluffypony>  hyc: agreed 
<fluffypony>  I'll make it clearer 
<fluffypony>  moneromooo: did you want to raise a point, or were you saying we can move on? 
<hyc>  overall it looks sane to me 
<moneromooo>  I'm good. 
<fluffypony>  ok   
<fluffypony>  next point is also administrative in nature 
<fluffypony>  we'd like to adopt the Collective Code Construction Contract that 0MQ uses, as a guide for project administrators and for contributors 
<fluffypony>  http://rfc.zeromq.org/spec:22 
<fluffypony>  we can discuss it more in future, but the long and the short of it 
<fluffypony>  is that we merge every PR as long as it doesn't break the build 
<fluffypony>  if it does something bad / dangerous we can have a follow up PR to revert 
<fluffypony>  but the aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged 
<fluffypony>  because it's never "perfect" 
<fluffypony>  so merge, create issues on Github where something is lacking (eg. new feature, little or no tests - create issues for tests) 
<moneromooo>  This PR-hell problem's never happened, has it ? 
<fluffypony>  moneromooo: not in Monero yet, but Bitcoin is chock-full of it 
<gingeropolous>  ^ this is for dev branch, right? 
<moneromooo>  I think common sense is again a better thing than going the opposite extreme. 
<fluffypony>  gingeropolous: this is in general 
<warptangent>  i haven't read the zeromq document thoroughly, but does it leave room for the common sense aspect? 
<fluffypony>  moneromooo: the problem is that there are lots of nuanced situations where "common sense" isn't that common :-P 
<smooth>  i dont think there should be an arbitrary merge policy on master, but it is already stated by me that i dont think anything but tagged releases should go on master 
<moneromooo>  Well, if it's nuanced, fine. 
<fluffypony>  warptangent: it does, yes 
<fluffypony>  as explained by Pieter to binaryFate and I last year 
<smooth>  if the concept of only taggest releases on master is no adopted then i would oppose going even further in the other direction 
<smooth>  *tagged 
<fluffypony>  smooth: yes that's a given 
<fluffypony>  master represents a stable, tagged release 
<fluffypony>  we work in dev 
<fluffypony>  anyone that submits a PR to master gets it closed and asked to submit it to dev 
<fluffypony>  anyway what I wanted to say, is that Pieter explained that the reason that you want to merge-all-of-the-things and then revert something bad is that you have a historical record of the bad actor   
<smooth>  there needs to be a place for bug fix releases though 
<binaryFate>  I'm with you fluffypony. 0MQ founder/leader feedback on this approach was extremely valuable. 
<moneromooo>  There's also the potential thing about not being able to use the 0mq version in time for the next 6-month fork. It wasn't exactly usable yet last I hacked on it. 
<binaryFate>  Common sense might work now, long term with a higher market cap we'll face same issues as btc 
<binaryFate>  Where common sense diverges and the code Base ossifies 
<xmrpromotions>  As a non programmer smooths comment seems like the safer approach. Thank you for clarifying the master vs dev branch issue fluffy. http://rfc.zeromq.org/spec:22 sounded scary as applied to PRs sent to master before dev 
<fluffypony>  smooth: it doesn't preclude it 
<fluffypony>  moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine 
<binaryFate>  What's the envisionned time scale for ringct? 
<smooth>  the idea of a historical record is good 
<hyc>  we have similar issues with OpenLDAP - you need 3 branches 
<hyc>  one for dev, one for released code, and one for release bugfixes 
<smooth>  but i would make the case then that 0MQ should be reverted since it is unusable 
<hyc>  particularly when dev and release are far apart 
<smooth>  im not actually proposing this because i know it would be a mess, but making a point for the future 
<hyc>  like now, where dev has 0MQ and release doesn't 
<fluffypony>  smooth: I agree - moneromooo and I will play around with it next week and make a decision   
<moneromooo>  Reverting isn't really possible. 
<fluffypony>  moneromooo: we could drop dev and re-branch 
<moneromooo>  But one could add ringCT to a new branch based on master. 
<fluffypony>  if it came to that, I mean 
<moneromooo>  That'd be a lot of pain. I'd rather not. Much better to hack on master and merge do dev again. 
<fluffypony>  ok 
<smooth>  imo something like zeromq should be developed on a separate branch somewhere, until it is actually usable 
<moneromooo>  s/on master/on a branch based off master/ 
<fluffypony>  smooth: it was usable-ish, we might have regressed some in fiddling   
<moneromooo>  Yes, that. 
<fluffypony>  anyway - let's evaluate and figure out 
<moneromooo>  I think I added all missing RPC so it cn be used, just not by people who want it to work without problem. 
<dnaleor>  **<fluffypony> moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine <= I welcome this. Just wanted to say that imho it's important to have RingCT active in the september/october hard fork. Carry on. i'm watching 
<hyc>  doing all new work in dev is fine, but backporting bugfixes to release will become non-trivial as more features are added to dev 
<fluffypony>  hyc: I guess it depends on the importance of a bug fix 
<moneromooo>  It looks to me like ring CT is going to need a lot of changes to bitmonerod/CN. September looks very close. 
<fluffypony>  we'll see   
<fluffypony>  I don't think we need to create a pressure-cooker for it 
<fluffypony>  ok can I go on? 
<ArticMine>  There are trade offs here. I see problems if dev and master deviate materially 
<xmrpromotions>  it seems like 3 branches as smooth mentioned would be easiest for everyone in long run even if it requires more effort now. 1.dev 3. release and bug fixes 
<fluffypony>  xmrpromotions: otoh we can backport fixes straight into master to allow for immediate testing by affected parties 
<ArticMine>  With bug fixes as a transition from dev to master 
<fluffypony>  again depends on the nature of the bugfix   
<fluffypony>  like warptangent's work on BDB and the importer probably aren't critical enough to go into master 
<warptangent>  the importer works properly when it has the hard fork support though, and that uses the bdb support 
<moneromooo>  If someone wants to rewrite that hard fork code, btw, you're welcome. I don't like it, and I'm not sure how to improve it. 
<ArticMine>  My concern is master deviating materially from a quasi stable dev 
<fluffypony>  ArticMine: something like ringct would have to be done in both master and dev 
<ArticMine>  So a project based on master would need a major rewrite after a tagged release 
<fluffypony>  we did dual-PRs for a while 
<fluffypony>  we can do them again 
<fluffypony>  might be easier than The Grand Merge 
<smooth>  something like ringct should only be in dev imo 
<ArticMine>  Yes anything fundamental has to be done in parallel 
<smooth>  until it gets released of course 
<fluffypony>  I think let's defer further discussion of this till the next meeting 
<luigi1111>  agreed to both 
<fluffypony>  we don't have enough info on the ringct effort or on the state of the dev branch right now anyway 
<binaryFate>  One thing I miss in discussion is what is master purpose? Do we want to encourage users to compile from it? How is master gonna diverge from tag release between them? 
<ArticMine>  I agree and lets carefully review the zeromq rfc in the meantime 
<moneromooo>  I think large things should go to their own branch (ie, ringct). Smaller things can share branches (to dev). Both end up being merged to master when ready. 
<fluffypony>  binaryFate: no matter what we say people clone and build master 
<gingeropolous>  **<- this guy 
<fluffypony>  it doesn't matter how much we encourage building a tagged release 
<fluffypony>  so we made a decision ages ago that master would be stable 
<fluffypony>  so that anyone pulling and building master doesn't get some hacky, broken branch 
<binaryFate>  Ok 
<fluffypony>  moneromooo: I don't know if we want topic branches in the main repo, but perhaps a more generalised "staging" branch, as long as anything going to that is also PRd to dev 
<moneromooo>  It can be in any repo. 
<smooth>  i think not in the main repo is fine 
<moneromooo>  Like I was hacking on tewinget's branch for a while. 
<fluffypony>  yeah that's a good point 
<luigi1111>  +1 
<fluffypony>  as long as that person is around and accepting PRs it's perfect 
<warptangent>  then one big PR to dev when it's ready? 
<moneromooo>  If we go to a dev/master setup, how does dev get merged to master anyway ? 
<warptangent>  that has worked before, yes 
<hyc>  yeah, keep main repo relatively clean 
<luigi1111>  a new feature can get a sort of "lead dev" 
<fluffypony>  moneromooo: when we release we merge from dev to master and tag master 
<luigi1111>  and contributers can hack on his repo 
<moneromooo>  So master becomes a copy of dev at that point ? 
<fluffypony>  yes 
<ArticMine>  Yes but a six month cycle could be too long 
<smooth>  thats a different issue 
<smooth>  how often to have major releases 
<fluffypony>  we can do major releases whenever, as long as we have major fork releases every 6 months 
<smooth>  also are releases time based or feature based 
<luigi1111>  kinda both ? 
<fluffypony>  yeah both 
<hyc>  feature-based is all that makes sense to me 
<ArticMine>  The merge to master may need to be more frequent than major fork releases 
<moneromooo>  feature based, but the rolling hard fork also pulls time based I think. 
<fluffypony>  yes 
<binaryFate>  Those Dev -> Master merges would happen with what kind of tagging? Point fix? Even more frequent? 
<fluffypony>  binaryFate: depends on how stable dev is 
<luigi1111>  so new features thus shouldn't be in dev until they are working properly/ready for release 
<luigi1111>  because of timed releases 
<smooth>  time based means that if you have 6 features in progress and one doesn't work in time, you do the release anyway, without the unfinished feture 
<fluffypony>  smooth, luigi1111: yes, you're both right 
<luigi1111>  it works as long as the half finished feature isn't partially merged 
<luigi1111>  or whatever 
<fluffypony>  the only reason 0MQ got pushed to dev anyway was because oranjuice could no longer work on it, and it was basically done 
<fluffypony>  but I think let's make it the last time that happens 
<fluffypony>  then we avoid complication 
<warptangent>  ok 
<moneromooo>  tbh I'd be tempted to not really care about people building master. If it's said clearly to use a release if you don't know what you're doing, then it's your problem. 
<smooth>  i agree with ArticMine that we can have releases sooner than 6 months 
<gingeropolous>  ah ok. so how the 0MQ happened is not how it will be in future 
<binaryFate>  Agree with moneromooo 
<fluffypony>  ok guys we're running overtime, so let's drop this for now, we can pick it up again later 
<smooth>  i think it is simply unnecessary to merge to master 
<smooth>  er sorry, commit unreleased stuff to master 
<moneromooo>  I think one of the problems with 0mq is that oranjuice kinda left 
<smooth>  any developer can handle getting the latest stuff from someone ele 
<smooth>  *somewhere else 
<moneromooo>  So it jsut had to be merged 
<ArticMine>  Let get back to this question at the next meeting 
<fluffypony>  ok 
<fluffypony>  last two things   
<smooth>  yup 
<fluffypony>  the first is that we have some major efforts coming up, besides ringCT, and things like epee, the 3 (THREE!!!) different logging systems, and a bunch of unused stuff is going to get in the way 
<fluffypony>  I'd like us to decide whether we want to keep hacking around things 
<moneromooo>  Does epee really get in the way ? 
<fluffypony>  or if we want to spend the effort now dumping this stuff for things that are easier 
<hyc>  it makes 32bit builds murder. but if we can abandon 32bit, that problem disappears too 
<moneromooo>  epee does ? 
<hyc>  yeah 
<fluffypony>  moneromooo: yes it does; it made QoS an absolute nightmare to do 
<fluffypony>  and it's still not done properly 
<moneromooo>  We'd have a replace a lot of stuff. 
<ArticMine>  32bit especially on windows is going to be around for a long time 
<dEBRUYNE>  + TAILS 
<moneromooo>  And a lot of somewhat low level stuff. 
<warptangent>  the multiple logging systems situation is strange, but i don't think it's interfered with current work. is there any knowledge on rfree's likelihood of returning? 
<fluffypony>  warptangent: low to impossible at the moment 
<fluffypony>  I mean, we can rip and replace the logging stuff with boost::log 
<fluffypony>  all the console stuff can go ncurses or similar   
<smooth>  id be more in favor of specific items like that, done on feature branch 
<fluffypony>  and the wire protocol can go ZMTP, since we have a 0MQ dep anyway 
<fluffypony>  eventually we'll get to a point where we're no longer reliant on epee 
<moneromooo>  I agree with the bit by bit approach. 
<warptangent>  that sounds manageable 
<fluffypony>  also then we'll actually have usable Doxygen docs 
<smooth>  the thing to bear in mind is this has virtually zero end user benefit, if not actually zero 
<fluffypony>  yes 
<fluffypony>  on the flip side, we can plug the GUI in via 0MQ instead of monero-as-a-library 
<moneromooo>  Well, the benefit is said to be for 32 bit users. 
<fluffypony>  so we have a shortcut of sorts there 
<fluffypony>  (in terms of users clamouring for stuff) 
<fluffypony>  moneromooo: and long-term viability   
<fluffypony>  we've had potential contributors ask for an architectural doc for the code, and get turned off when there isn't one 
<fluffypony>  so there's scope to slowly bring the codebase in line 
<smooth>  i dont believe there is anything about the current code that precludes a GUI. After all, BBR has one with basically the same code. 
<hyc>  huh.. contributors that are turned off so easily ... I wouldn't expect much use out of them if they stayed 
<moneromooo>  I was kinda thinking that too... 
<fluffypony>  I guess, but tbh it does make the project seem significantly less mature 
<fluffypony>  which I guess is fair, it's not even 2 years old 
<gingeropolous>  less hurdles, more good 
<smooth>  it is somewhat hard to come up to speed with the code, i would agree with that 
<fluffypony>  alright 
<fluffypony>  last thing so we can wrap up 
<fluffypony>  I just wanted to deeply thank everyone who has contributed and who continues to contribute to Monero development, whether it is Monero's core, the website, any other peripheral projects 
<fluffypony>  both on behalf of the core team, and on behalf of the community   
<fluffypony>  you all do an amazing job, and we've done a truckload of work in 2014 and 2015 
<fluffypony>  so here's to an amazing 2016 
<gingeropolous>  hear hear! thank you fluffypony for herding the cats so good 
<Bassica>  hear hear! 
<xmrpromotions>  thank you! 
<ArticMine>  Thanks for all the good work 
<fluffypony>  thus concludes the first meeting, next one in two weeks 
<warptangent>  thanks fluffypony 
<luigi1111>  thanks 
<binaryFate>  Thanks to you fluffy (enjoy that wine)! Thanks to all of you, awesome community. 
<dEBRUYNE>  Thanks fluffypony! 
<hyc>  **<glug> thanks all 
<Infinite_Jest>  is there a buffet? 
<fluffypony>  Infinite_Jest: snacks will be served in The Grand Ballroom in 15 mins 
<Infinite_Jest>  ok great but seriously thanks! 
<cardboardoranges>  thanks fluffy

"[XMR] Monero - We Have Ponies and Moos || ZOMG Mandatory ZOMG: v0.9.1"

It's not a mandatory update from 0.9, but it is a mandatory update from 0.8.x. A fresh sync with 0.9 works just fine, a lot of 0.9 nodes aren't on the bad fork any longer (longest chain rule), and the 1 or 2 nodes that still seem to (bizarrely) be stuck will figure out they need to update.

Re: the thread title, with the mandatory hard fork policy every update is mandatory. We can put the latest version in the title, but I'm not sure it's necessary to use the word mandatory - thoughts?

Asking people on Bitcointalk won't help address the specific issue you're encountering, I'm afraid. You have to email us (support@mymonero.com) with your address and details of the problem you're encountering.

Du hast Recht, die Fork war kein Zufall. Jemand hat einen Grenzfall identifiziert, den wir nicht bedacht hatten und statt es uns mitzuteilen, hat die Person dieses Wissen böswillig missbraucht um das Netzwerk zu forken. Das war kein Versehen.

Du solltest dich fragen: Warum ist eine kleine Kryptowährung, die nur von geringem Wert ist, so interessant für einen Attacker und warum wurde sie in der kurzen Zeit ihrer Existenz schon so oft attackiert?

Hinsichtlich des behaupteten "ASIC Widerstandes" von Monero: Es wurde niemals versprochen, dass Monero auf magische Weise dazu in der Lage sein wird das Kreieren von ASICs und FPGAs zu verhindern. Selbst wenn leistungsfähige ASICs erfunden werden sollten, wird die Performance-Lücke nicht so groß werden, dass CPU oder GPU Miners nicht mehr funktionieren.

Das Wichtigste ist: Der Normalverbraucher wird immer dazu in der Lage sein mit seinen Gerät zuhause zu minen und das sogar an der Gewinnschwelle (plus / minus Null) oder mit nur geringen Verlust. Es bedeutet allerdings nicht, dass es diese schnelleren Miners in Zukunft nicht geben wird, sondern nur, dass durch ihre Existenz die vorherige Generation nicht unbrauchbar gemacht wird.


(And in English)

You're right, the fork was not a coincidence. Someone identified an edge-case that we hadn't thought of, and instead of reporting it to us they abused that knowledge to maliciously fork the network. This was not accidental. It is important to stop and ask yourself: why would a tiny cryptocurrency, that is almost worthless, be so interesting to attackers that it would be attacked multiple times in its brief history?

As to the "ASIC resistance" of Monero: it has never been promised that Monero will magically be able to prevent ASICs or FPGAs from being created. But even if powerful ASICs are created, the performance gap will not be so large that CPU or GPU miners will no longer work. That is the important thing: ordinary users will always be able to mine, breaking even or at only a small loss, using their ordinary equipment at home. It does not mean these faster miners won't exist, just that their existence doesn't kill the previous generation.

PS. My wife says it's ok, I'm not sweating Holzwolle anymore, instead she's sweating Holzwolle translating this:)

Just to check - how did you shut it down previously? Cleanly, by typing "exit", or was it a disruptive shutdown? lmdb is pretty robust, but not impervious to corruption, so I wonder if it's not a corrupt blockchain.

There isn't one - we were reorganising the contents of the download server, so it was in a bit of flux. We'll add a list of old versions to the site in the coming weeks.

They're all around the median, looks to me like someone is moving funds on a wallet with LOTS of inputs, and transfer_split has split it up over many transactions.

FWIW a few months back I sent someone 100k XMR on testnet from my testnet mining wallet, and that was split over something crazy like 130 transactions.

Even if MM disappeared we still wouldn't be able to spend your coins, and you'd be able to recover them either through some other service or directly through a modified simplewallet:)

Indeed - looks like the Galera cluster is getting hammered by a DoS, which is causing deadlocks for legitimate users. I'm busy filtering it out and it should be fine within the next 10-15 minutes.

https://github.com/monero-project/monero-core

I look forward to your pull request and continued work on it.

Just to reiterate - the idea is to code-freeze 7 months before the hard fork. This time we didn't code freeze as timeously as we would have liked, but even if you grabbed the code from like October you'd still be fine till after the March fork. Even the malicious fork from Friday wouldn't have affected you, as long as you gave it a few days for the fork to resolve.

From the release info:


Try sync from scratch first:)

We have a pretty comprehensive test suite, and this was an oversight in the tests - we missed adding one for this edge-case.

As always, this is an open-source project, feel free to submit a pull-request to expand the unit tests and core tests.

To get you started, here are all the unit tests: https://github.com/monero-project/bitmonero/tree/master/tests/unit_tests

And here are the hard fork unit tests we've created: https://github.com/monero-project/bitmonero/blob/master/tests/unit_tests/hardfork.cpp

I look forward to your first pull request, and thanks for offering to help!

NB: https://forum.getmonero.org/1/news-announcements-and-editorials/2452/monero-network-malicious-fork-from-block-913193-updates-and-resolution

From that post (which will be kept updated) -

Hi all,

The Monero network was (once again) the subject of an attack. Due to an error during the development of 0.9, Hydrogen Helix, we omitted a check that allowed for v2 blocks to be added to the network prior to the hard fork block height. Thus instead of forking on March 20, at block height 1009827, a v2 block was added to the network at block height 913193.

This is obviously problematic as not all services have updated to 0.9, and the bulk of the network hash rate is still on 0.8.x. We are preparing a point release to 0.9 that resolves this, but in the meantime only if you are running 0.9 you can do the following as a quick patch:

Shut down your Monero daemon
Grab a checkpoints.json file from getmonero: https://downloads.getmonero.org/checkpoints.json
Put the file in your bitmonero working directory (eg. ~/.bitmonero or C:\ProgramData\bitmonero)
Restart the daemon
As soon as the patched point release is out you can remove the checkpoints.json file, if you wish, and run the updated version. The checkpoints.json patch is a quick fix and does not prevent the attacker from replaying their attack at a later block.