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

This attack on XMR was meant to distract bears attention from BTC, so the bulls can do their job lol jk.
Still, I hope we will capture this BTC bull moment (if its not over already)...

This isn't stupid at all - he's being accurate.  If you heard someone from the dev team saying anything except what smooth just posted, you should be running.

Yes, of course there are other attacks that can, and, if the coin continues to be successful, will be mounted against Monero and the other cryptonote coins.

It's a new codebase, and it was inherited from an unknown set of developers whose motivations, competence, and trustworthiness are unknown.

If you're buying Monero or any other coin based on the codebase, you'd damn well better be doing it with your eyes open:  These coins are new.  They're not based on a fork of the bitcoin codebase.  They're different, and they come will all sorts of attendant risks of bugs and vulnerabilities.  That's also part of what makes them interesting, and not just a blah-blah "i cp'd bitcoin and tweaked a parameter".

Don't rail at the developers for being honest with you.  Thank them for assuming you're adult enough to deal with reality, and thank them for not misrepresenting what they're working on.

You're criticizing the developers for bringing in external expertise?  Give me a break.  Taking over a foreign codebase that's got interesting cryptography and implements a distributed system is hard.

As I said about an earlier Monero bug:  https://bitcointalksearch.org/topic/m.7988816

the test is how the team responds, whether they're able to identify and fix the bug, and whether the quality of the code and the process for preventing bugs improves over time.

So I have a very concrete suggestion for you:  Shut up for a moment.  Give all of the devs involved a day or two to recover from what must have been an annoying and stressful bug hunt.  And then ask *politely* if they'll include in the next Missives a summary of the things they're doing to improve the codebase and the development process for the coin, such as progress on regression testing and the ability to do things on testnets, elimination of buggy coding patterns, etc.  See what's been changed, if anything, from the previous bugs, and if there's improvement going on, and then decide for yourself whether the trajectory is good or not.

Trading should be resumed in hours.

Thanks

Not a core dev here, just a very experienced one commenting from observation:

It is necessarily an incremental process, in the context of a working system.  Breaking things that people depend on is anathema.  And you would be surprised at the sort of unsupported edge cases that people come to depend upon.

Removing functionality which is not actively causing a more serious problem is very undesirable.  Sometimes it is practically unavoidable, however.

The evolution of the XMR codebase will be a long series of focused refactorings (think of replacing a hip with titanium) and cross-cutting ones (think of chemotherapy to kill a blood cancer circulating throughout the body).  It's not a large codebase, but it is an (often unduly) complex one.  The cost and time are sunk mostly into the links between the parts, the interfaces.  The more there are and the more complex those interfaces are, the longer it takes and the more it costs.

If you try to basically rewrite the thing before rolling out a big gem, maintenance costs can bankrupt your development effort, and the released feature set is stagnant.  Although it takes longer, as long as it is viable, it is wise to choose the incremental refactoring path.  Then incremental features which are practically necessary can be released as the improvements in infrastructure allow.  

In general, refactoring is the process of performing correctness-preserving transformations on the code, until the interfaces fall along the boundaries necessary to contain the complexities inherent in the feature requirements into modules which have more managable size and complexity.  It is slower than rewriting, but far less risk.

In crypto, as in embedded vehicle or weapon controls, minimizing risks takes on profound importance.  

XMR is the future.

https://twitter.com/Poloniex/status/507571637214920704

Devs, when will you give exchanges the green light to trade?

What does all of these users have in common?











Hint: no avatar

His assessment of CN code is correct imho.  It's a mess.  Shouting "Cryptonote code is terribad" on twitter is extremely foolish.

(Edited to remove funny, put possibly insulting last line)

It is a bit of a bastard to get up and running in my experience. also hi james. unexpected to see you over here.

I haven't looked at it (we are forked from bytecoin, though the copyrights on the code still say cryptonote) but from what I remember, their reference code is more of a toolkit and probably requires some edits to turn into a working coin.

Any of the working cryptonote forks should be easiler to build. I've never done anything other than (install dependencies and) type make.

Peter Todd is the new CEO of Monero!  That's great news!  

I am curious if the cryptonote code base is intentionally done with crayons and monkeys. What is to be gained from this?
Simple things like their reference code didnt compile for me. Now I am always having problems getting all the modules installed, but I would think a supposed reference code should compile. So if it doesnt compile, then what other problems are there?

Didnt make sense to me and I didnt have time to investigate

James

I agree with this position.  I am disappointed at that display.  I think it can be said, but this was a bad way to do it.

Thanks for the answers to my questions. I have nothing to add.

There is no plan to replace the codebase entirely. We are open to input and considering ideas. Two very different things.

other trolls could learn a thing or two from you.

Whatever works.

But:

"glad to hear the devs had the same idea" sounds more like you were? are? considering changing the codebase entirely.

We've discussed this through and through, and the general consensus is that the effort it would take to port everything over is huge, and then we'd be stuck inheriting a lot of other stuff that would make what we want to do in future more difficult.