moneromooo> In any case, I'm not sure it's worth wasting time just to make github servers happy. <--- After taking a deeper though about it, what I'm doing is actually providing more error margin, IN CASE somebody overloads the Github servers one way or another. Then the mining process is not to be blamed for this, and thus should not be canceled, just because it took too much CPU time (which had to be shared at that moment).

anyone have an idea about monero-project/monero #7386 ?

he can try to download the same old version monero-wallet-cli and restore it there, then use the v0.17.1.9

ok suggested that in a comment

How is the monero wallet encrypted with password? ChaCha8 something?

chacha20

It used to be chacha8 until... maybe two years ago.

Someone got their parents into monero, and they lost both their password and image of seed ... looking at options for retrieving wallet - hashcat supports ChaCha20 but more for hashes than for decrypting a wallet

How much space size of password are you going to brute force ?

* What alphabet and how many characters are you going to brute force ?

If I could leverage hashcat with wordlists and masks, my chances are pretty good

There is default lang for masks with english lower/upper/both case alphabets

I wonder if a Cryptonight ASIC could be used for that. It might be much slower if you change the input all the time...

"If I could leverage hashcat with wordlists and masks, my chances are pretty good" You don't work size for brute force and don't know speed of your GPUs, right ?

also didn't extract hash of password from wallet file

I don't know if it is chacha8 or 20 even

speed of GPUs is easy enough to check - at least if it is chacha20

looks like a single vega64 can do 5.6GH/s chacha20 (synthetic, so only realistic for a mask attack)

I need the same script that accept wallet file path and return hashcat args to brute force

writing ...

chacha20 was checked in on Dec25th 2017. moneromooo: You don't do holidays, do you :P

Is there some good way to determine if a file is a valid monero wallet? I guess that is the only way to validate the decryption being "correct"

The plaintext should be valid JSON. So test whether the first few characters are... hmmm... {" maybe. Log your own wallet's decrypted contents, see the first few bytes.

If it passes that, parse with an actual JSON parser.

"github.com/ph4r05/py-cryptonight" this doesn't produce valid cn_slow_hash(...) hashes

* "github.com/ph4r05/py-cryptonight" this module doesn't produce valid cn_slow_hash(...) hashes

"I wonder if a Cryptonight ASIC ..." if these devices support only fixed offset for nonces then they are useless

"looks like a single vega64 can do 5.6GH/s chacha20" password -> [cryptonight (original)] -> chacha key -> [chacha20(<constant prefix from wallet.bin.keys>, <chacha key>, <chacha initialization vector from wallet.bin.keys>)] -> decrypted prefix of account data -> [memcmp(<...>, {"key_data":)] -> true / false

If there is no availabel ASIC then you take cn/0 implementation from xmrig and add support of this scheme into hashcat since xmrig doesn't have sophisticated pw generator

* If there is no available ASIC then you take cn/0 implementation from xmrig and add support of this scheme into hashcat since xmrig doesn't have sophisticated pw generator

cn/0 will be bottleneck of this brute force

you need at most 12 bytes of chacha so it isn't important

"looks like a single vega64 can do 5.6GH/s chacha20" 2kH/s for cryptonight (cn/0, you can check with xmrig)

Is it feasible to brute force forgotten characters with this speed ?

it should be easy to add support, e.g. hashcat/hashcat #2559/files, only 2 major files are need adopted OpenCL code from xmrig and input/output processing

but the speed will be slow

moneromooo, I believe the warning spam will be solver with:

Which you already approved.

.merges

dsc bot got k-lined

how sad

is it known that submodules are are borked?

"Fetched in submodule path 'external/miniupnp', but it did not contain 544e6fcc73c5ad9af48a8985c94f0f1d742ef2e0. Direct fetching of that commit failed.

"

on master

No. AFAIK they're not.

git submodule sync

git submodule update

git submodule unbork

^

(but if they're not borked, would it actually bork them...)

danke schon

gonna see if master has any new tricks to deal with my public node eventually just dieing on wallet connections

It actually builds the whole thing now, not just libminiupnpc.

lets see if xmrchain.net breaks it too

Remember kids. If you call project coral reef for what it is - fluffypony embezzling half a mil usd from the monero fund for a website with smaller adoption than monero woo plugin, you will get excommunicated. Why do you think charities need Teslas? They don't and Elon won't support Monero 150k will sure buy a lot of party time for those that actually do get it.

what the heck just happened to #monero

Hilarious :D

uhhh

Did our channel get taken down?

13:35 -!- mode/#monero [+b *!*@*] by ChanServ

seems excessive.

moneromooo we dying here

How did our channels get dropped?

chanserv hijack of some sort?

looks like it

Anyone else from Core around to help figure it out?

fluffypony maybe?

Heard Core has some special access to #monero* channels

Never a dull moment in Monero...

yesterday there were strange PMs on freenode from random nicknames, some windows batch commands or whatever, maybe someone got compromised who had access to chanserv

fluffy running windows ? :D

Oh wait, I should not, I'm fluffy...

*know

strange selection of targeted channels

one of those spam messages yesterday did say "attn: freenode is moving to irc.crimeircd.net" so it does seem like it could be related

Freenode ops are fixing.

thx

good to hear

I wonder if someone saw that msg and actually tried to login with their IRC passwd to that server

was the channel hacked or something

hyc: yikes, if true

wait so this is not #monero, but #monero-dev right?

yes

ahh this all makes sense now

Yes, seems like pony indeed.

Channels seem joinable now fwiw.

on purpose? >_>

20:54 <iDunk> It actually builds the whole thing now, not just libminiupnpc. <-- why?

was something wrong in my PR or change in miniupnp repo?

I think it refers to miniupnpc being only part of the repo IIRC.

monero branch in our repo was set up to only build libminiupnpc, IIRC.

Hello! Where can I find what the monero block template consists of (field blocktemplate_blob of getblocktemplate response)?