[XMR] Monero - A secure, private, untraceable cryptocurrency

[dEBRUYNE]

@medusa13, have you tried this already? (Doing both steps!)

It may well be that your wallet's idea of what outputs are spent got out of sync with the blockchain. I believe there is a bug there. One thing you can try that's pretty fast (assuming you're running your own daemon):
- run simplewallet with --trusted-daemon
- in simplewallet, run: rescan_spent

You can also run this in the daemon:
print_pool_sh

If you see your tx, it means it's not being mined. In this case, the likely reason is that it's a double spend caused by the sync problem above.

[1713913892]

1713913892

[1713913892]

1713913892

[cryptonic21]

A "strong" password helps a bit but most of the security comes from the coin ID itself.

If you want to be reasonably paranoid, you must assume that between production and shipping, the coin ID is compromised.
I'd personally make sure the entropy of my password is fine by itself.

If you don't use it at the very beginning or end, a compromised coin ID is still useful to salt/stretch something human-memorable, especially if you tweak it a bit.

http://rumkin.com/tools/password/passchk.php

Thanks a lot, everybody! We have updated the F.A.Q section at cryptonic.net.

[medusa13]

i do not know which trxid the transaction had that causes the problem, so i can not look if one of my trx is inside the pool.

yes i allready deleted .bin and synced from scratch. also used rescan_spent.
since i did this, the amount shown in simplewallet is right (it was wrong before too, think its due to the same transaction that causes problems now)

anyway yeah, i will come to irc if i have time (not today i guess)
much easier i agree.

[canonsburg]

Can someone explain how to decrypt the .keys file?

Specifically, the load_keys function within the wallet2.cpp in the source. Can explain the logic behind it and the procedure. (Not that fluent in C)

void wallet2::load_keys(const std::string& keys_file_name, const std::string& password)
{
  wallet2::keys_file_data keys_file_data;
  std::string buf;
  bool r = epee::file_io_utils::load_file_to_string(keys_file_name, buf);
  THROW_WALLET_EXCEPTION_IF(!r, error::file_read_error, keys_file_name);

  // Decrypt the contents
  r = ::serialization::parse_binary(buf, keys_file_data);
  THROW_WALLET_EXCEPTION_IF(!r, error::wallet_internal_error, "internal error: failed to deserialize \"" + keys_file_name + '\"');
  crypto::chacha8_key key;
  crypto::generate_chacha8_key(password, key);
  std::string account_data;
  account_data.resize(keys_file_data.account_data.size());
  crypto::chacha8(keys_file_data.account_data.data(), keys_file_data.account_data.size(), key, keys_file_data.iv, &account_data[0]);

.....

[smooth]

Can someone explain how to decrypt the .keys file?

Specifically, the load_keys function within the wallet2.cpp in the source. Can explain the logic behind it and the procedure. (Not that fluent in C)

void wallet2::load_keys(const std::string& keys_file_name, const std::string& password)
{
  wallet2::keys_file_data keys_file_data;
  std::string buf;
1 bool r = epee::file_io_utils::load_file_to_string(keys_file_name, buf);
  THROW_WALLET_EXCEPTION_IF(!r, error::file_read_error, keys_file_name);

  // Decrypt the contents
2 r = ::serialization::parse_binary(buf, keys_file_data);
  THROW_WALLET_EXCEPTION_IF(!r, error::wallet_internal_error, "internal error: failed to deserialize \"" + keys_file_name + '\"');
  crypto::chacha8_key key;
3 crypto::generate_chacha8_key(password, key);
  std::string account_data;
  account_data.resize(keys_file_data.account_data.size());
4 crypto::chacha8(keys_file_data.account_data.data(), keys_file_data.account_data.size(), key, keys_file_data.iv, &account_data[0]);

.....

I labeled some lines of the code above:

1. Loads the data file into a memory buffer

2. Parses the memory buffer into a data object

3. Derives a chacha8 decryption key from the password (this uses the CryptoNight slow hash for key stretching, which greatly limits the possibility of brute forcing).

4. Decrypts the data using the decryption key

The unlabeled lines in the code are error checking, memory management, etc.

[ktfutura]

it looks like the vanillacoin developer is not impressed with the 0.9.0.0 Hydrogen Helix release 



https://twitter.com/john_a_connor/status/684152084141314048



https://twitter.com/john_a_connor/status/684183295983136768

 

[smooth]

it looks like the vanillacoin developer is not impressed with the 0.9.0.0 Hydrogen Helix release  

Maybe "the vanillacoin developer" should focus more on not ripping off Bitcoin code and lying about having written it from scratch and less on ridiculous and dishonest FUD about HDD failure from using a database engine (which naturally engage in disk activity to maintain indexes, etc.)

EDIT: BTW, I just checked my laptop and it has 369.98 GB written since the last reboot (not running an XMR node nor anything else outside of a normal end-user workload). It is something like 4 years old and hasn't failed yet.

There are many places where Vanillacoin copied Bitcoin code. I have pointed out a good example previously, it won't be hard to find dozens more.

There's nothing wrong with copying and modifying the Bitcoin code, the MIT license allows you to do with it what you like, it just ask you not to be a scumbag and remove attribution and pretend you wrote the code in the first instance.

[smooth]

it looks like the vanillacoin developer is not impressed with the 0.9.0.0 Hydrogen Helix release  

Maybe "the vanillacoin developer" should focus more on not ripping off Bitcoin code and lying about having written it from scratch and less on ridiculous and dishonest FUD about HDD failure from using a database engine (which naturally engage in disk activity to maintain indexes, etc.)

EDIT: BTW, I just checked my laptop and it has 369.98 GB written since the last reboot (not running an XMR node nor anything else outside of a normal end-user workload). It is something like 4 years old and hasn't failed yet.

There are many places where Vanillacoin copied Bitcoin code. I have pointed out a good example previously, it won't be hard to find dozens more.

There's nothing wrong with copying and modifying the Bitcoin code, the MIT license allows you to do with it what you like, it just ask you not to be a scumbag and remove attribution and pretend you wrote the code in the first instance.

Don't make replies like this - it's not worth your time and only will be used for a counterattack. Dude has a God complex and is narcissistic - tries to bully other people all the time. Just ignore it.

Maybe, but I just replied to Spoetnik too. I'm not really sure which was more of a waste of time. Toss up, I guess.

[e-coinomist]

Simple example, assuming my brain wallet is 12MD516SHAparmiggianoIsMySalt.

Wuts "Parmigiano-Reggiano"  but overall, solid method  we are definitely entering the age of culinary cryptography, yummy!
Adding semantics definitely helps a lot. And never be afraid to store data outside of your brain "somewhere". The world is full of data, so many places.

[birr]

Salt for a brain wallet passphrase is essentialy different from from the salt you would use, for example, to salt the password of a customer logging in to a website.

In the latter case, a common word like parmiggiano is more than acceptable.  In fact, website administrators can keep salt stored in plain text or even publish it without compromising its effectiveness.
But for a brainwallet, parmiggiano is just like any other word:  vulnerable to rainbow tables.  

You should salt your brainwallet passphrase with your driver license number, phone number, or some other piece of data familiar to you but which will look like random characters to a rainbow table, because the people who compile rainbow tables don't, they can't generate all possible telephone numbers and then simply fold such a huge amount of utterly arbitrary data into the table.  The whole point of a rainbow table is that it looks for patterns, and does so as efficiently as possible.  Brute-forcing every telephone number in the world is out of the question.

Thus your telephone number or driver license number won't appear in the rainbow table, but "parmiggiano" will.

[TooDumbForBitcoin]

Salt for a brain wallet passphrase is essentialy different from from the salt you would use, for example, to salt the password of a customer logging in to a website.

In the latter case, a common word like parmiggiano is more than acceptable.  In fact, website administrators can keep salt stored in plain text or even publish it without compromising its effectiveness.
But for a brainwallet, parmiggiano is just like any other word:  vulnerable to rainbow tables.  

You should salt your brainwallet passphrase with your driver license number, phone number, or some other piece of data familiar to you but which will look like random characters to a rainbow table, because the people who compile rainbow tables don't, they can't generate all possible telephone numbers and then simply fold such a huge amount of utterly arbitrary data into the table.  The whole point of a rainbow table is that it looks for patterns, and does so as efficiently as possible.  Brute-forcing every telephone number in the world is out of the question.

Thus your telephone number or driver license number won't appear in the rainbow table, but "parmiggiano" will.

Everybody knows some words that won't.  Here are some of mine, from memory:

prollum
aks
happeners
basghetti
skanking
bitz
frones
groinacologist


How do I know they won't?  A squiggly red line appears underneath them when I type them.


 

[Shrikez]

Parmiggiano just might do as it's spelled Parmigiano

[birr]

How do I know they won't?  A squiggly red line appears underneath them when I type them.

As everyone knows, you can stake 100 coins on that squiggly red line.  Safe as milk.[/snark]
Can you quantify the entropy held in that squiggle?

[GreekBitcoin]

Hydrogen Helix is great! Very good work guys. Blockchain synchronized rather fast and everything worked smooth for my laptop

Now since monero needs businesses accepting it, well, i created a rather noob jewelry eshop for some time now. I was waiting to perfect it but since this is going to take like forever with my lack of time i decided to post it and see what happens. It really is in "beta" stage if not "alpha" and after all it was intended to simply be my family business catalogue. So here it is:

http://monero.gr/eshop/

The products are handmade and are being sold in Greek islands for more than 30 years now.

Much work needs to be done, like more products, better photos, better design, gold items, more info, better way of accepting the coins, better security, etc. But anyway i dont expect to have huge volume for now...

I also pledge to donate 1% of the volume towards monero development.

For any questions please contact me either through the shop or send me a pm here. Even better is to contact me via both ways.

[Hueristic]

Hydrogen Helix is great! Very good work guys. Blockchain synchronized rather fast and everything worked smooth for my laptop

Now since monero needs businesses accepting it, well, i created a rather noob jewelry eshop for some time now. I was waiting to perfect it but since this is going to take like forever with my lack of time i decided to post it and see what happens. It really is in "beta" stage if not "alpha" and after all it was intended to simply be my family business catalogue. So here it is:

http://monero.gr/eshop/

The products are handmade and are being sold in Greek islands for more than 30 years now.

Much work needs to be done, like more products, better photos, better design, gold items, more info, better way of accepting the coins, better security, etc. But anyway i dont expect to have huge volume for now...

I also pledge to donate 1% of the volume towards monero development.

For any questions please contact me either through the shop or send me a pm here. Even better is to contact me via both ways.

Very nice, needs button to switch to XMR and whatever other currency you will accept.

[arnuschky]

Haven't been in this forum since a loong time, but while I am here, I had to bow deeply to the Monero devs. Kudos, guys, very impressive what you did with 0.9

Thank you.

[GreekBitcoin]

...

Very nice, needs button to switch to XMR and whatever other currency you will accept.

There is a "switch" under the the currency icons. And there is a choice at checkout. But i get that it needs to be shown more clearly
As i said there is much work to be done yet!

[Hueristic]

...

Very nice, needs button to switch to XMR and whatever other currency you will accept.

There is a "switch" under the the currency icons. And there is a choice at checkout. But i get that it needs to be shown more clearly
As i said there is much work to be done yet!

Great! I don't have my reading glasses with me, checking it out now.

Also if you have any solid gold hunter cases in the 16-18s range pm prices. Inners unnecessary.

[Jason.W]

Is the daemon supposed to pass blocks synced during a session out of memory?

The blockchain is stored on disk first and foremost.

Your OS might or might not also keep some portion of it in memory as a form of caching, depending on the amount of other memory usage on your computer.

The synced blocks during my sessions have been appearing in memory and grow until my memory is maxed out. These are cleared only when I exit the daemon.

The blockchain itself is being saved to disk, but my ram usage grows with each reported synced block. I am syncing from nothing. My programs hang as the memory becomes maxed out.

Is this a bug?

That does not sounds like you are using the current version.

I'll try resyncing from scratch again, as I'm almost caught up.

The version I am using is the HH release from github yesterday, windows.

It put 1.59 GB from my most recent session into memory over one hour. Note this is not what It starts up with, which is around 200 Mb. Just figured I'd ask, because I remembered you posting that it only took up a few hundred mb as well. In total it took 1.79 Gb before I restarted it.

TY smooth.

As I said it will use what you have. If no other programs are using the memory, then your OS will give it more (especially during sync). If other programs need RAM, the memory usage for the node will shrink down to almost nothing (especially once synced).

However, you shouldn't see anything hang. That was what I thought pointed to a problem.

I can't rule out that there is something else wrong with the OS currently.

Give me a few hours, I'll have a duplicate fresh OS installation on this HW and get back to you.

Turns out root cause was a power supply surging problem. Luckily it's still in warranty

Thanks again!

[nioc]

Have any of the exchanges updated to 0.9?