I honestly don't see this "hype" situation you're describing. We don't make promises or say we're going to do something merely to create hype. When we push something out, like with the OpenAlias system we pushed out today, we are already well down the road to having it working, if not completed already. Anyone outside of the core team that tries to create hype will have to, unfortunately, deal with out release cycle.

We (the core team) have already stated that we will work on Monero regardless of whether the price goes up or down. Monero is not going to "die", even if the price goes down. The exploit still has more vague hand-waving than actual details. Nonetheless, if such an exploit exists then either we will figure it out over time and patch it, or the exploit will be used and we will patch it (just as we did with the block 202612 exploit).

This, too, will not make Monero "die" any more than Bitcoin "died" in August 2010 when someone created a block with 184 billion Bitcoins. They had to suspend the network and roll it back, causing a fork at that bad block. It took over 2 days for the correct fork to win out. In fact, Bitcoin has, over its history, had 23 exploits serious enough to have CVE numbers. And yet it hasn't died. This constant declaration of death because someone manipulates the price or some other person unverifiably claims to "have an exploit" is just silly.


The "big guys" were not around at the beginning, so I can't get how you say that "the entire thing is built around" them. That makes no logical sense whatsoever. Either way, they can be as greedy as they want, they're not affecting us or our ability to develop. Eventually their "greed" will either result in them being rewarded financially, or they will chicken out and leave. Not every early, loud-mouthed Bitcoin proponent is still around.


Again, where is the hype?

Are there proponents of Monero who say that Monero is "amazing" or what have you? Sure. But I have not seen them claim Monero is ready for prime time (in fact, quite the opposite), and I have not seen them claim we're developing anything that we aren't.

100% -

[ ric->bitmonero ]$ host -t TXT myagui.monujo.com
myagui.monujo.com descriptive text "oa1:xmr recipient_address=41goTv5ma7GZeiRKfdNisLGHPbYTPxtMs3mjH8NExEneNB2s9fasBrehsoMRESpJApXqcvqn7PMU3W1SpjNokA1a9d7ujyr\; recipient_name=Myagui\;"


Looks good, and -

[wallet 48NGTd]: transfer 0 myagui.monujo.com 10
For URL: myagui.monujo.com,DNSSEC validation FAILED!
 Monero Address = 41goTv5ma7GZeiRKfdNisLGHPbYTPxtMs3mjH8NExEneNB2s9fasBrehsoMRESpJApXqcvqn7PMU3W1 SpjNokA1a9d7ujyr
Is this OK? (Y/n)

We're starting the #Monero-Dev Fireside Chat #2 shortly, just a reminder for those that want to watch -

https://plus.google.com/b/101861896996947433029/events/c8094ts82ggh0mpkffu4ja5kohg

http://www.youtube.com/watch?v=s9gH2ndAAkE

https://www.certicom.com/index.php/52-the-elliptic-curve-discrete-logarithm-problem (and https://www.certicom.com/index.php/the-basics-of-ecc)

http://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication

http://homepages.warwick.ac.uk/~masiao/maths/lecturenotes/ellipticnotes.pdf

http://tools.ietf.org/html/rfc6090

http://people.irisa.fr/Arnaud.Tisserand/docs/slides-semcairn09-ecc-4p.pdf

http://crypto.stackexchange.com/questions/653/basic-explanation-of-elliptic-curve-cryptography

http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/

http://www.ccs.neu.edu/home/riccardo/courses/cs6750-fa09/talks/Ellis-elliptic-curve-crypto.pdf

http://crypto.stackexchange.com/questions/3907/how-does-one-calculate-the-scalar-multiplication-on-elliptic-curves

Please go read up, and then if there are specific questions once you have come to a proper understanding of the notation used when expressing elliptic curve multiplication then feel free to ask.

I'll just quote from someone who knows way more math than I do -


sarang: The operation is actually repeated elliptic addition... and that addition is really a curve intersection and some other complicated shit
sarang: Multiplying an integer by an elliptic curve point is well-defined
sarang: the x*H(p) is not another hash
sarang: You convert the hash output H(p) to an elliptic point
sarang: and then do the integer-elliptic multiplication
sarang: so it's super important to identify what is an integer and what is an elliptic curve point
sarang: The notation is identical, as it would be in formal mathematics
sarang: They usually use lowercase for integers and uppercase for points
sarang: and always use the multiplication order integer*point
sarang: just as a matter of convention, that is
sarang: so anyone saying you can divide a point by an integer is wrong
sarang: elliptic curve crypto would be broken wide open if that were the case
sarang: Oh, and G is NOT a hash function. It's the elliptic base point
sarang: so A is also an elliptic point

lol cryptography, how does it work?

https://www.certicom.com/index.php/52-the-elliptic-curve-discrete-logarithm-problem

H_p is a deterministic hash function. You only know I, x is secret. P is computed using x. Explain again how you're going to reverse the hash function?

This is a TA thread - if you're struggling to grasp the cryptography then you are welcome to continue this discussion in the Monero ANN thread: https://bitcointalk.org/index.php?topic=583449.0

Alternatively, if you believe you've found an exploit, I do encourage you (again) to document it and write a PoC like every other security researcher. The process of writing a PoC normally forces me to come to grips with the intricacies of the subject, and I document thereafter.

Rem tene verba sequentur, as they used to say.

Ah ok, so just to make sure everyone's on the same page, this is the screenshot from the Missive:



The idea was to make it "ticked" by default, and it's a per-wallet setting, but if people want to disable it or increase/decrease the percentage they can at any time. Before the GUI is even released, though, we wanted to add this in to simplewallet / rpcwallet - again, prompted during wallet creation, and configurable at any time.

Now I know this seems like a small amount, and it won't do much difference, and you're right. This is not going to satisfy the immediate and large funding requirements. Which is why this is more of a longer-term thing to make sure we always have budget for ongoing efforts / maintenance. It does not preclude fundraising for specific features / tasks.

The problem is that in these early stages we (as in the core team) need to take the role of "benevolent dictator". The reason is that "design by consensus" has never worked - invariably someone or some group will be able to swing the vote in favour of what "they" want. By having a "benevolent dictator" that the community trusts will act in the best interested of the cryptocurrency (and not in the best interests of individuals with voting / buying power), AND who will revert a change / proposition if there is sufficient kickback, you allow for a more unified vision to be realised.

As a core team we have a pretty concrete vision, but it's hard to put it down on paper and look ahead when we're scrabbling to fix urgent things right now.

What I think would work is for us to raise funding to sort out the short-term urgent issues, and then longer-term we can raise funds for specific features / aspects.

Slow compared to 0.8.8.3? What part of it is slow, what operating system?

What damage? Should we react every time someone claims something? At this stage, given that there are no technical details, we can only assume that it may be true or it may be false. And, thus, do nothing until something tips the evidence either way.

Claiming to have something and providing evidence thereof are two different things.

If you have an exploit for a (genuine, not-scammy) FOSS project, not releasing it *at least* to the developers is unconscionable - you aren't hurting a corporation or a bunch of fat cats, you're hurting a small group of developers who work - unpaid - on a software development project for the presumed betterment of everyone. You're hurting altruists who are giving of themselves for little or no reward, but I guess there are people who are so ethically imbalanced that they don't even consider this.

At a minimum some technical details about it would be nice.

I don't think that it's fundamentally bad to build something into the software. Not sure if you saw the Missive, but in the last wizard screenshot there's an idea for an auto-donation system we want to implement: https://i.imgur.com/ACDmOFJ.jpg

The basic idea is that it's completely user-selectable, based on a % of your tx fee (cumulative to avoid adding dust outputs) that is added on top of the tx fee, so it'll never have a major impact. In the GUI we'd most likely have it on at 50% by default.

You're right. What you've pointed out is clearly a gaping hole that allows an attacker to just take everyone's money, and somehow myself, tacotime, smooth, the rest of the Monero core team, andytoshi, gmaxwell, Wladimir v d Laan, Peter Todd, the Monero Research Lab mathematicians / cryptographers, and everyone else that has read the whitepaper and/or looked at the implementation missed this obvious and gaping flaw. Clearly you have the superior intellect and knowledge, I look forward to seeing your published research and PoC code for this flaw soon.

Until then, have a good day.

Yes - rates are at-the-time that the expense needs to be paid, so obviously donations took a beating when the exchange rate was quite a bit lower.


It is kinda frustrating to see other projects raise hundreds and thousands of BTC based on a whim and a promise...but then again, it does change the dynamic as respects the integrity of the project. If we're perpetually in the negative there's nobody's money we can run away with:-P

To give you some input on this from the Monero core team's perspective: we try keep the SNR in the Bitcointalk ANN thread as high as possible, and #monero-dev on Freenode has a pretty high SNR as well.

We do not sanction or control any of these other threads. In due time we will likely stop posting anything on Bitcointalk related to Monero apart from announcements in the ANN thread.

No, it's double the work to first do an RPC hack-job and then follow it up with a proper, integrated solution.

The view key for the XMR fund is in the OP...we just need to provide tooling for that:) We've received around 25.3 BTC in XMR donations, and 7.80559 BTC in BTC donations, so a total of 33.10559 BTC. Actual expenses / contributor tips / freelancers / mathematicians+cryptographers / hosting have been significantly higher (in the region of 110 BTC excluding the core team's time), which we have been covering out of our pockets. In other words, we're in a perpetually negative balance.

Please take the time to familiarise yourself with some basic cryptocurrency concepts:

https://en.bitcoin.it/wiki/Transactions#Input
https://en.bitcoin.it/wiki/Transactions#Output

http://www.coindesk.com/information/how-do-bitcoin-transactions-work/

https://bitcoin.org/en/developer-guide

Edit: again, not to repeat myself, but as I already said in my previous post: "You can't change an input without mucking up the signature for the whole transaction."