I'm not going to say no, thank you
In fact, I added my Monero address at the bottom of the page. If people read that far down



Ah, I did not realize you were working on one too. We can have two though


Nice

About the logo, it autoscales, yes. It doesn't look bad here, but I'm on a laptop so I guess it doesn't look so large compared to the text... I guess you can add width="50%" to the img tag.

The image was taken from getmonero.org btw.

Of course, go right ahead.
And for those who aren't comfortable getting the file over plain HTTP, the github URL is on the page.

It has been requested many times, and it is here, at last.

https://github.com/moneromooo-monero/monero-wallet-generator is a browser based offline wallet generator for Monero. This means you can generate a new Monero address/wallet without the simplewallet binary. The page is self contained, so is suitable for saving and using offline (ie, possibly on a computer which is not connected to the network).

The git commits are GPG signed. If you know how to do so, I encourage you to verify the signature is a valid one. My key can be found in the Monero source tree:
https://github.com/monero-project/bitmonero/blob/master/utils/gpg_keys/moneromooo.asc

The Cryptonote code was adapted from MyMonero. I had to change the way it derives the view key to make it compatible with simplewallet. This means the wallets generated are NOT compatible with MyMonero, but with simplewallet.

Wallets generated with monero-wallet-generator can be restored at any time with simplewallet:
./build/release/bin/simplewallet --restore-deterministic-wallet --wallet-file mynewwalletfilename
Choose a new password, copy the seed you got from monero-wallet-generator, and the wallet will be restored.

Only English seeds are supported, due to issues with UTF-8 preventing restoring other languages. This will hopefully change in the future (though low priority).

Same thing for non Firefox browsers. I don't have them, so any fixing there is low priority.

Last, no warranty. If you have the opportunity, a test restore before moving monero to a new wallet is a good idea, though I guess it kinda defeats the purpose.

I'm guessing it needs to gather LOADS of inputs to reach 5m, and reaches a byte size limit.
If you pay 2m to yourself a couple times, you should then be able to send 5m using these two blocks to make 4m of the 5, then other smaller blocks to make up the rest.

Except if you build from current master.
There's a save_watch_only command. It saves a wallet keys file with just the view key, which you can then send elsewhere and load normally in simplewallet, and you can't spend with it, just see incoming txes.
There's another branch in development that will allow outgoing payments to use a scheme that's compatible with this too, so you will be able to see those as well.

In the dice example, network difficulty is akin to the number of faces on the dice. The more faces, the less likely you are to get a 1.

Conversely, block weight is akin to the target you must reach. If instead of getting a 1, you have to get X or lower. So a small weight block would need to roll a 1, a larger block would need a 2 or lower, etc.

The second bit takes into account every block you have. As an example that may be easier to grasp, imagine you have a dice, and you roll it till you get a 1. You have 1/6 chance to get 1 at each roll. The expected number of rolls till you get 1 is.... hmmm. a few. You will likely need to roll a few times to get a 1. You might get a 1 on the first roll, and you might need to roll 10 times before getting one if you're not lucky.

Now, picture a HYP block being such a dice, rolling every second. And now imagine you've got 100 dice. And think about if you roll these 100 dice at once, what is the expected number of whole rolls to get at least a 1 ? It's pretty likely you'll get at least a 1 in that first mass roll.

That's why you get an overall expected time to stake that's a lot lower than the typical time to stake for a single block. The more blocks you have, the larger the gap.

Maybe, I don't know. But it currently is not, and Poloniex apparently decided to do this preemptively, rather than after being forced/notified, so when other exchanges follow is not known. Even if they changed in a month's time, it's still better for people who want to trade and don't want to give names. That's not to say this won't get reversed later, should Bittrex later ask for more information than Poloniex does now (just in case someone decides to reply to what I did not claim).

Maybe this Poloniex name and country thing is a blessing in disguise, then. It may cause a significant enough amount of trading to go to Bittrex, thereby encouraging more people to trade there too, and we end up with two "large enough" exchanges, one of which is suitable for suit type people who would only trade on a regulated show-me-your-papers exchange (whatever their reasons might be).

See MRL4. It looks at how minimal mixin values affects the likelihood of an adversary with some percentage of outputs available to mix to see through to get the spent inputs in a ring signature. Turns out a rather low minimum mixin is enough to quickly drown a static (who doesn't generate more new known outputs) adversary.

For the active adversary above (I magically become the owner of loads of coins and inputs) then sure, if the NSA finds an exploit that lets them steal pretty much all the coins in existence, you're a bit screwed. Even if they didn't even bother to try to deanonymize.

Try scanning the monero binaries from http://getmonero.org/downloads/ the same way.
If you don't get those hits, then something's fishy, since Aeon is mostly monero clone. Some malware scanners flag crypto mining software because botnets sometimes have a mining payload.

If you're using tor, you can also try getting the binaries without tor (or using a different exit node) to make sure you didn't download binaries via an exit node that MITMed your download to add malware.

Does "incoming_transfers" show anything ?
It may be that you're looking at the wrong wallet, if you created a few different ones for testing.

This doesn't seem like anything to do with HYP itself, but the Qt stuff's display part, and doesn't seem fatal, just a warning that it's using some fallback.

As a stopgap, I've started looking at a simplewallet command to sweep up dust outputs in a tx to yourself, which should give you a nice round output as the cost of the tx fee.

My pool's been pretty much deserted for a month now, but I'm keeping an eye on this.

  _o<

There is no support for this in the pool code. However, if you PM me your Aeon address, I can hardcode an override to the payment code to use a threshold of your choosing for that address.

I think I do. There's a couple addresses that send bad hashes every so often, and the IP gets temporarily banned for a few minutes as a defense, this is probably yours. There are two AEON addresses from the same IP, behaving and then submitting bad hashes. The IP address ends in 143.

I think the issue is one of heat, which makes the GPU miner generate faulty blocks. I've never used the GPU miner, but AFAIK you can decrease the intensity, or number of threads, or similar, to load it a bit less, so that it will not reach the threshold which causes it to develop faults.

If that's not you with those two addresses on that IP, then I don't know.

It's now running on the pool, some blocks were found on it too. All seems fine.
CentOS 6 on x86_64.

Mine ("Works for me. Hash rate went up about 3.5 times, dififculty 10 times. Everything else seems fine.") was Fedora 20 on x86_64.

Works for me. Hash rate went up about 3.5 times, dififculty 10 times. Everything else seems fine.