Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1465. (Read 4670972 times)

It sort of worked. Everyone should have switched to one chain once it got longer (switches back and forth a few times are possible until it is clear which chain wins), and that part didn't work.

Checkpoints were only needed in this case because of the exploit. Most coins do use checkpoints in practice, including Bitcoin, even if they aren't needed in theory (if everything works as intended).

Thanks.

This sounds like a temporary patch (based on smooth response above) because of constant moving check points pushing everyone back to a particular chain rather than a chain chosen by consensus? If so, is there a time frame when there are sufficient number of blocks to enable the checkpoints to be removed?

Ah yes - sorry, the terminology used in the blockchain storage class is rollback -

https://github.com/monero-project/bitmonero/blob/master/src/cryptonote_core/blockchain_storage.cpp#L399

rollback_blockchain_switching() is used when a node disconnects from one chain, rolls back, and then switches to another chain that it determines is "best" (longest verifiable).

Thanks @smooth

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.

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)?

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.

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://bitcointalksearch.org/topic/m.8698576

Thanks

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

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.

perfect thanks
but
I thought that
they patched
all nodes

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

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.

what is the problem?

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.

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 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.

XMR address: 4AqrzGPfEKeZrVXyPDNXUrNeKZZGNYiXMDoY49PvdffKNTRg6xp2Qz74SZ72gT5F9HH8Vaic99ndRg6 UBGcVijaNStQjwwf

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

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.

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.