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

[fluffypony]

If the Monero command-line client is not something you'd like to use, then use one of the GUIs as linked in our OP.

I'd like to use something that will work. I don't care command-line client or GUI! Before this mess with wrong fork  i can easy use command-line client & GUI!
Now i don't know what i can do with my dead XMR Wallet... 

Uh, the fork patch doesn't touch the wallet code. You can use the old wallet binary with the current daemon binary if you'd like. Literally nothing has changed in the way the wallet works in the last two weeks.

[pa]

<poetry deleted>
what do you think ?

I think you are a Vogon: http://hitchhikers.wikia.com/wiki/Vogon_poetry

[drawingthesun]

Fellow XMRs,

I recently had close to 6 figures in XMR. I used to be in love with this coin. I have sold it all, pending regaining confidence.

One of the reasons I lost confidence was the desperation I am seeing in the figure heads of the XMR community - the epitome of which is in desperate scared nonnsensical threads like this one ---> https://bitcointalk.org/index.php?topic=771925.0

I would hope that the leaders in this community would talk to and reign in your "spokespeople" who are giving this coin a HORRIBLE reputation. The fear mongering and arrogance that is thinly masked insecurity is depressing. Please think about taking this coin in a different PR direction. Thank you.

You've lost confidence in the coin/team because of people outside the team?

Interesting.

I'm quite amazed how weak a hand you are, to be so influenced by people that are not actually on the team of that coin. I and rpietila are not apart of this coin any more that we are "spokespeople" for bitcoin. I am hoping this isn't a FUD campaign just as you start your marketing campaign for BBR

...

EvilDave -

this week I am going to start organizing a BBR marketing committee/group with a PR gameplan. I know you are busy with Nxt PR but I'd love to see if there are some ways we could cross promote BBR and NXT.

I do think with Teleport+CryptoNote we have the opp to have the strongest anon coin in the world. It would benefit everyone if we work together. Let me know your thoughts. Thanks

Jon

[Aaxx]

Literally nothing has changed in the way the wallet works in the last two weeks.

OK. But when  i open  bitmonerod.exe, see:
"Sync data returned unknown top block: 206081 -> 207740 [1499 blocks (1 days) behind]
SYNCHRONIZATION started" That's all.
SYNCHRONIZATION stops and does not go beyond! What does it mean, hah? That's OK?
Then i open  simplewallet.exe but it freezes after enter of password.
If I have try to make a new XMR Wallet,  simplewallet.exe also freezes after enter of password.  What i did wrong?
 

[dga]

Fellow XMRs,

I recently had close to 6 figures in XMR. I used to be in love with this coin. I have sold it all, pending regaining confidence.

(Funny that I heard this same thing in the trollbox today.) You have an obsession on me, you know deep inside it is you who needs to apologize. But you won't do it. You don't even ask me to do anything, just stalk. The door is still open.

To others: this is a personal matter.

Of course you think I have an obsession with you because your ego is larger than your gigantic bald head (I'm kidding) (ok, not really ) .

But, seriously, I issue I have with Risto is that he has too much influence over crypto noobs who think because he has a little money, that that makes him smart. But to the rest of us his actions are transparent and not noble.

I like XMR. I hope it suceeds. I will probably reinvest.

But for XMR to succeed it needs to have new representation. Risto hurts the things he touches.

I have praised Risto for certain actions and insights he has provided over the years. When he is on, he can be a useful resource and encouragement to people. But when he's freaking out about his finances, he can become a detriment to the cause.

XMR, BBR, both - I dont care.  Im an early adopter no matter what. But if there is an elephant in the room, we should point it out.

Let's hope that people coming to this forum realize the most basic rule:  Trust nobody.  The baseline expectation should be that everyone else is trying to maximize their gains, and may be lying, misleading, fudging, telling the truth, etc., and you have very little idea of which it is.

Verificable technical advise is often a safe ground, but if you listen to investment advice on bitcointalk, you're probably going to end up donating your funds to someone.

(But, seriously, be realistic:  AnonyMint once asked the XMR devs to muzzle me, and you can see how far such a request gets.  They can control themselves.  You can control yourself.  And judging a currency based upon the posts of someone outside the dev team is simply giving that someone control over you by way of your reaction, which is just as dangerous as trusting them.)

End of off topic.

[tacotime]

I'm updating my copy of the blockhain with 0.8.8.3 and it's saying it is -3 days ahead at this point. Is this how it is supposed to be going?

My guess is that it's seeing that the bad chain exists, and will download that, fail to verify it and its work, and switch back to the main chain.

[akula999]

XMR address: 4AqrzGPfEKeZrVXyPDNXUrNeKZZGNYiXMDoY49PvdffKNTRg6xp2Qz74SZ72gT5F9HH8Vaic99ndRg6 UBGcVijaNStQjwwf

If you no longer want to invest int his coin, i'll be happy to take it off your hands.

[dga]

Technology is opened and transparent. It's not messy - all you need is strong exprience with modern C++ design, passion and maybe little different attitude to it. (not you personally sure )  
It's not only my opinion - for example i have another dev who was helped me with some core patches (difficulty adjustment from 64 to 128 bit to be more concrete) - he also gave good feedback about codebase. And also it said dga (Dave Andersen) if i'm not mistaken (correct me if i wrong).

I haven't looked at a lot of the core code for things like transactions.

On the whole, I have mixed feelings about it.  I can comment on, for example, the wild keccak implementation and the cryptonight PoW implementation:

- CryptoNight was deliberately obfuscated, so it's not a very useful example.  It was ugly, but it was someone clever trying to be ugly.  The underlying *algorithm* (also invented by CN) was really elegant.

- Wild Keccak was reasonable.  It made use of some fancy very-modern C++ features in ways that I might call excessively clever  (there's a funky use of a type trait template in there to differentiate the real keccak code from a tweaked version used in the PoW with extra multiplies), but that's a bit more in the realm of style, and I see why it was done that way.  (I think that's related to some of my comments below about the code being designed for ease-of-being-written).

- The RPC design is very reasonable.  Much better than most of the C-based protocols in other currencies.  The use of C++ there helps clean it up a lot, and it's both readable and easier to verify correctness and lack of things like buffer overflows.

- The tree_hash code that PT was complaining about is almost unreadable and very difficult to determine what the heck it's actually trying to do.  The lack of comments there are brutal for an outside developer.

- The simpleminer code was mixed.  It wasn't commented, but it wasn't too hard to figure out.  I only spotted a few issues.

- The code is structurally complex -- understanding it requires too much bouncing between many different files.  It would really benefit from a big refactoring that focused on simplification and clarity.  It has the feel of code that was written with an eye towards programmer efficiency on *writing* (getting a lot out of relatively few lines of code).  Simple examples would be things like "why the heck is get_donation_accounts() in a file called currency_format_utils.cpp" (or the equivalent functions in cryptonote_format_utils for XMR).

The last comment is really the best way to sum up the state of the codebase:  My guess is that it was written by folks who know what they're doing, but were focused on developer speed, not the kind of structure that makes it easier to maintain the code over longer periods of time.  A lot of that can be fixed with refactoring and (serious) reviews from other developers about where things need to be clarified.  Some bits should be shot and rewritten, such as that nasty bit of C that PT identified.

There are some big chunks in C that I haven't looked at, and which I gather are the source of a lot of the horribleness.

But it's not too hard for a good C++ programmer to jump in and start doing some work on the parts of the codebase that *aren't* directly tied to the core transaction stuff.  That part will take someone longer to get into, but it's not impossible.

[smooth]

I'm updating my copy of the blockhain with 0.8.8.3 and it's saying it is -3 days ahead at this point. Is this how it is supposed to be going?

My guess is that it's seeing that the bad chain exists, and will download that, fail to verify it and its work, and switch back to the main chain.

Should I download the blockchain from the OP and use it instead of what I have synced or is mine ok?

You are okay as long as you updated to the latest release are able to sync to the current height, no need to download a new blockchain.

It is the peer you connected with that is on the wrong chain. Nothing we can do about that, some nodes are just neglected, forgotten, etc. The network must function even with bad nodes, and it does.

[trip96]

My progress: Downloaded new client from the original post (0.8.8.3) Everything is fine. Windows 7 64-bit. Just synced and it went smoothly.

[argentinx]

Code:

2014-Sep-07 19:43:22.135157 [P2P5][193.150.121.37:18080 OUT]Sync data returned u
nknown top block: 205913 -> 207812 [1899 blocks (1 days) behind]
SYNCHRONIZATION started
2014-Sep-07 19:43:25.102635 [P2P4][68.52.136.224:18080 OUT]Sync data returned un
known top block: 205968 -> 207812 [1844 blocks (1 days) behind]
SYNCHRONIZATION started
2014-Sep-07 19:44:36.040358 [P2P7][188.40.137.12:18080 OUT] SYNCHRONIZED OK
2014-Sep-07 19:45:17.156474 [P2P3][95.188.116.35:18080 OUT]Sync data returned un
known top block: 207812 -> 202659 [5153 blocks (-3 days) ahead]
SYNCHRONIZATION started
2014-Sep-07 19:46:10.360146 [P2P7][54.64.122.255:18080 OUT]Sync data returned un
known top block: 207813 -> 202659 [5154 blocks (-3 days) ahead]
SYNCHRONIZATION started
2014-Sep-07 19:46:13.816759 [P2P7]Block with id: <78fbbca5edea204b3ff5e92fbe6413
029a32849ccad434481cc9e2b944244845>
 can't be accepted for alternative chain, block height: 202658
 blockchain height: 207813
2014-Sep-07 19:46:13.847525 [P2P7][54.64.122.255:18080 OUT]Block verification fa
iled, dropping connection

what is the problem?

[equipoise]

Literally nothing has changed in the way the wallet works in the last two weeks.

OK. But when  i open  bitmonerod.exe, see:
"Sync data returned unknown top block: 206081 -> 207740 [1499 blocks (1 days) behind]
SYNCHRONIZATION started" That's all.
SYNCHRONIZATION stops and does not go beyond! What does it mean, hah? That's OK?
Then i open  simplewallet.exe but it freezes after enter of password.
If I have try to make a new XMR Wallet,  simplewallet.exe also freezes after enter of password.  What i did wrong?
 

Just wait some time and you should be OK. Simplewallet is waiting for a response from bitmonerod - that's why it freezes. Bitmonerod is starting the sync and is just 1 day behind, so just wait it to finish.

[psterryl]

Code:

2014-Sep-07 19:43:22.135157 [P2P5][193.150.121.37:18080 OUT]Sync data returned u
nknown top block: 205913 -> 207812 [1899 blocks (1 days) behind]
SYNCHRONIZATION started
2014-Sep-07 19:43:25.102635 [P2P4][68.52.136.224:18080 OUT]Sync data returned un
known top block: 205968 -> 207812 [1844 blocks (1 days) behind]
SYNCHRONIZATION started
2014-Sep-07 19:44:36.040358 [P2P7][188.40.137.12:18080 OUT] SYNCHRONIZED OK
2014-Sep-07 19:45:17.156474 [P2P3][95.188.116.35:18080 OUT]Sync data returned un
known top block: 207812 -> 202659 [5153 blocks (-3 days) ahead]
SYNCHRONIZATION started
2014-Sep-07 19:46:10.360146 [P2P7][54.64.122.255:18080 OUT]Sync data returned un
known top block: 207813 -> 202659 [5154 blocks (-3 days) ahead]
SYNCHRONIZATION started
2014-Sep-07 19:46:13.816759 [P2P7]Block with id: <78fbbca5edea204b3ff5e92fbe6413
029a32849ccad434481cc9e2b944244845>
 can't be accepted for alternative chain, block height: 202658
 blockchain height: 207813
2014-Sep-07 19:46:13.847525 [P2P7][54.64.122.255:18080 OUT]Block verification fa
iled, dropping connection

what is the problem?

No problem, just your node receiving blocks from others that are on the wrong chain. You can safely ignore these errors.

[argentinx]

perfect thanks
but
I thought that
they patched
all nodes

[psterryl]

perfect thanks
but
I thought that
they patched
all nodes

Nope, they released a patched version. It's up to all the people running these nodes (like you and me) to update to the correct version, or they won't be able to use their wallets.

[coins101]

I'm updating my copy of the blockhain with 0.8.8.3 and it's saying it is -3 days ahead at this point. Is this how it is supposed to be going?

My guess is that it's seeing that the bad chain exists, and will download that, fail to verify it and its work, and switch back to the main chain.

Should I download the blockchain from the OP and use it instead of what I have synced or is mine ok?

You are okay as long as you updated to the latest release are able to sync to the current height, no need to download a new blockchain.

It is the peer you connected with that is on the wrong chain. Nothing we can do about that, some nodes are just neglected, forgotten, etc. The network must function even with bad nodes, and it does.

I must have missed something. Is this release a patch or final fix? There was a post a few pages back that there was a rollback - is that part of the patch or fix, to get rid of the corrupt block(s)?

https://bitcointalk.org/index.php?topic=583449.msg8698576#msg8698576

Thanks

Edit: Just seen the post above which indicates this is a patch release.

[othe]

Coins101, you understood the word rollback in a incorrect manner.
The patch just syncs to the correct chain if you are stuck on the wrong one; it goes back to the block where the split occured and syncs from there on.

This "rollback" has nothning todo with a bc rollback, i agree the word is confusingly used tho.

This is a "final fix" or "patch" call it how you want but the daemon continues to operate correct with it.

[coins101]

Coins101, you understood the word rollback in a incorrect manner.
The patch just syncs to the correct chain if you are stuck on the wrong one; it goes back to the block where the split occured and syncs from there on.

This "rollback" has nothning todo with a bc rollback, i agree the word is confusingly used tho.

This is a "final fix" or "patch" call it how you want but the daemon continues to operate correct with it.

Obviously not my area of expertise, but longest chains are supposed to win and miners will eventually drop shorter chains when the proper blocks are eventually broadcast across the network. So, I'd be interested to know what the fix, fixed. Was it a patch that fixed the attackers means to enter the network with a checkpoint that loses the corrupted chain(s)?

[smooth]

Coins101, you understood the word rollback in a incorrect manner.
The patch just syncs to the correct chain if you are stuck on the wrong one; it goes back to the block where the split occured and syncs from there on.

This "rollback" has nothning todo with a bc rollback, i agree the word is confusingly used tho.

This is a "final fix" or "patch" call it how you want but the daemon continues to operate correct with it.

Obviously not my area of expertise, but longest chains are supposed to win and miners will eventually drop shorter chains when the proper blocks are eventually broadcast across the network. So, I'd be interested to know what the fix, fixed. Was it a patch with a checkpoint that loses the corrupted chain(s)?

There were three fixes. One to prevent the type of malicious blocks that caused the fork from being used again, the second is adding checkpoints to make sure you are on the correct fork when syncing past the malicious blocks, and finally checking of checkpoints in the saved blockchain file to ensure that you end up on the correct fork after restarting your daemon.

The normal "longest chain wins" code used for normal forks that happen all the time (usually just one or two blocks, but can be longer) doesn't work in this case without the fixes because it assumes that there is only one version of a block with the same block ID, which the exploit violated.

[coins101]

Thanks @smooth