Michael, I did not create the CryptoNight PoW, nor am I particularly attached to it. I am, however, against blatant incorrectness in a technical document, and would be just as vehement if the incorrectness were about scrypt. This is not the first time I've reacted this way - in this very forum I've passionately argued against incorrectness in all manner of "whitepapers" dished out by "developers" regardless of whether or not it relates to something I'm involved in.

That you feel the need to pop your head in and pass a smug and arrogant comment is not unsurprising, but it would behove you to tread carefully, as such behaviour reflects extremely poorly on the cryptocurrency you represent.


I stand by the turn of phrase I used. Lying, or misrepresenting a fact that he should know, in a formal technical document is unconscionable. In fact, I agree with everything else he said about the algorithm, but that entire last sentence is unnecessary and disingenuous. I'd expect something like this from a Newsweek reporter, but not from somebody who obviously understands the facts of the matter and is writing a technical document. If it was a developer working for me they would be in a disciplinary hearing, but spending a few years C-level at a listed company has maybe made me overly demanding.

I do not claim or pretend to be a dispassionate person.

That is true, but you and I are resigned in the knowledge that a purpose-built device will always be able to outperform a general purpose device, even if the cost of that purpose-built device is fiscally prohibitive. Thus, the gap cannot ever truly be closed, in the truest sense of the word. Thankfully, this is clarified somewhat: "It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power."

Holistically the take away is and should be that the performance gap needed to be reduced between CPUs, GPUs, FPGAs, and ASICs. CryptoNight delivers on that goal quite sufficiently.

Note: I much prefer Cuckoo Cycle over CryptoNight, and am watching its ongoing development with expectation and excitement. Although we do not expect to switch PoWs anytime soon, Cuckoo Cycle is on a very short list of candidates for future consideration.

The full sentence in the whitepaper is: "These constraints were supposed to protect hash from GPU and ASIC implementation, but a GPU miner appeared on the scene in 2 weeks after this technology got public attention." Thus, contextually we know that his meaning in the word "protect" is "ensure they do not exist". He considers the very existence of a GPU miner a failure of the algorithm, when, in fact, a GPU miner can and should exist as long as it the performance gap is closed. Currently GPU miners are 2-3x as performant / efficient as CPU miners, and by dga's calculations they shan't exceed ~5x the performance / efficiency. Thus the algorithm has completely succeeded at what it purports to do, and has met its primary goal.

Talk about resurrecting an old topic for the sake of spewing nonsense;)

Start here: https://bitcointalk.org/index.php?topic=583449.msg6597057#msg6597057

NoodleDoodle released the binaries in public on IRC. His changes were subsequently submitted as a pull request and committed. All of this happened in the space of 36 hours (between May 6th and May 7th). He was under no obligation to release the binaries or his changes, and from the hashrate graph it's clear that the earliest time he could have begin using the improved code was May 6th. Nobody had any significant advantage from this, even though they absolutely could have. Something to think about next time you want to throw a spurious argument out.

Busy reading through it - he leads into it with a huge fallacy that is either incredibly naive or very disingenuous of him. When describing CryptoNight he states: "These constraints were supposed to protect hash from GPU and ASIC implementation" [sic]. Literally the first paragraph in the CryptoNote whitepaper that describes the PoW algorithm says: "Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less profitable as possible."

Misrepresenting the facts of the matter in a whitepaper, purposely or not, is unconscionable.

Monero uses the CryptoNote protocol, which is completely different from the Bitcoin protocol. It does use a different proof of work algorithm from Bitcoin, but that is inconsequential, as that is definitely not the key or only differentiator.

For example, what you think of as a "wallet" in Bitcoin is a group of private (spend) and public keys that belong to you. In Monero, a wallet only contains two private keys: a spend key and a view key. An "address" in Bitcoin is a base58 encoded hash of the public key associated with a particular private key inside a wallet. In Monero, an "address" is a base58 encoding of the serialised view and spend public keys.

Incidentally, "mining" in Bitcoin is merely proof of work, and Satoshi openly acknowledges in the Bitcoin whitepaper that it is based on Adam Back's Hashcash.

Therefore, just because it appears to be similar in concept and uses similar terminology does not mean that it is the same thing. Satoshi Nakamoto pulled many things together in Bitcoin, from a HashCash-derived proof of work system, to the blockchain which is, essentially, a Merkle tree that is not too dissimilar from what Ralph Merkle patented in 1979. Similarly, Monero certainly uses many of the theoretical principles espoused in Bitcoin, but it pulls many other cryptographic concepts together, such as its use of ring signatures (per the "group signatures" paper published by D. Chaum and E. van Heyst in 1991).

Huh? No, pfo released a wallet for Monero on June 10, and he's now released the same wallet for QCN. He initially wrote it for mropool.org.

But that just means it shares common principles. Bitcoin used principles from Adam Back's Hashcash, blinded payments from DigiCash, and several other virtual currencies that preceded it. Here is a good article that is a starting point if you're interested: http://bitcoinmagazine.com/12241/quick-history-cryptocurrencies-bbtc-bitcoin/

I think it's important to make a distinction between something that builds on the theoretical foundation of Bitcoin, yet shares no common code with it, and something that merely inherits Bitcoin's code and adds a few features. I do not think calling the former a "semi-clone" is valid, any more than I think it's fair to call Bitcoin a semi-clone of DigiCash;)

So in order to send $1000 you first need to have $2000 available AND it needs to be tied up until this transaction is complete?

I'm going to guess, but I may be reaching, that this will never have any sort of longevity:-P

Monero isn't a clone of Bitcoin, so I guess that puts it in the same boat, wouldn't you agree?

I know, right?

<popcorn.gif goes here>

:-P

The database stuff will be done quite some time before a GUI is complete. Because we're cognisant of the amount of work involved in bring the GUI to fruition to the standards we expect, we have had no problem starting work on it sooner rather than later. By the time it's done all the other bits will be done;)

Looks like it's actually the Quazarcoin botnet mining Quazarcoin as usual:

Nothing earth shattering? How is purposeful deception not earth shattering? Based on the information provided we now know not to trust a group of cryptocurrencies that are most likely churned out by the same coin mill. I think that's pretty earth shattering.

Read the last two Missives:

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

If anything is unclear, please ask:) If you'd like to speed up the effort we're able to put in to development, please consider donating:

Donations for general development

XMR: viewkey: e422831985c9205238ef84daf6805526c14d96fd7b059fe68c7ab98e495e5703

BTC:
Monero Community Hall of Fame

Sorry yes - I mean dump the 64-char hex string and go for something that tops out at a reasonably sane amount, which will cause tons of collision on the blockchain over time. The stealth idea wouldn't require this, it would be unbound and sent as a hash because it's stealthed. Regardless of which route we take, packing it in with the account number is a necessity, even if this means the account number grows by a number of base58 characters.

A malleability attack doesn't stop the transaction from going through, it just mostly goes through with a different tx ID to the one kicked back by your wallet. Your coins won't disappear, the recipient address will still receive them, and nothing can be stolen. Malleability does not and cannot change the validity of the transaction, the destination, the amount, the p2sh hash (if there is one), the inputs, the outputs, or anything else. The only thing it changes is the transaction ID.

Therefore, if you made a payment to your friend, and sent him the transaction ID, he may not be able to match that with his address history by payment ID. He will still be able to match it based on where it came from and the amount. Bitcoin is still vulnerable to this, as pointed out in the link you reference, and Eligius and other pools will still gladly mine valid transactions that fail isStandard() tests.

Requesting one with a protocol is a problem, the daemon shouldn't touch out via non-p2p channels except for certain convenience features that a paranoid user can disable. Using something like that also makes offline rawtx's that much harder to make.

I'd argue for a smaller payment ID set than the current huge one - maybe as low as 10k possible payment IDs per wallet. The more payment ID collision there is in the blockchain the more useless it is as a metric.

The only alternative off the top of my head is to have a stealth payment ID. Following the parlance in the whitepaper (section 4.3), Bob would give Alice his public key (A, B, C) where C is the public ec-key of (c), the private ec-key that is the payment ID, and is packed into the address. The one-time public key computed by Alice by generating a random r ∈ [1,l−1] and then computing the public key as P = H_s(rA)G+B. Alice then generates a visible payment ID (that is sent in tx_extra) by computing I = H_s(rC)G. Bob identifies his transactions by computing P′ = H_s(aR)G + B (he knows R since Alice has packed R = rG into the transaction) and matching them against every passing transaction. Upon identifying a transaction, Bob is able to then determine the recipient by taking his set of locally generated payment IDs (the method by which he computes these, whether deterministic or random, is irrelevant, and the transaction is guaranteed to have a payment ID as the address given to Alice contained one) by computing I′ = H_s(cR) (since cR = crG = rC and I′ = I). Then again, I'm no mathematician and could be reaching with this.

Lots of really good discussion about ripping out old terminology and replacing it with more intuitive and natural terms:)

There may be some value in retaining "address", as "address book" is a familiar concept for having a list of thing-I-remember (name) linked to thing-I-don't-remember (address), and "email address" is a familiar concept as a unique destination. If we replace address with account number, what do we call "Address Book"? I checked on my online banking, and the equivalent they have are "beneficiaries" in a "favourites" list, which I suppose is ok (although I've never been fond of "beneficiaries"..."recipients" maybe?) I'm not averse to dropping "address", as long as we can find a convention that fits.

One additional thing to consider: we are looking at ways of packing the payment ID into the "address" so that there are no longer issues with it being a separate thing that people forget. In this regard alone I lean towards address rather account number, because with a bank you pay into a person's single account number and allocation is manual/semi-automated, whereas with this you'd pay into seemingly-unique "addresses". Conceptually I would think this is somewhat similar to Gmail's functionality where you can receive email to name+description@gmail.com and it tags them with the bit after the +.

I think the 24 word "seed" is fine as a term, since it conveys the sense of "thing that everything else grows from" which underscores its importance, else we should call it a 24 word "key"? We will have additional formats that can be used to store your seed, such as a password-encrypted, base58-armoured version. Given that the use of stealth addresses removes the need to have multiple addresses in your wallet (and thus multiple privkeys) we can use the term "seed" or "key" comfortably (I have no preference between the two).


A brain wallet is a terribly bad idea, not in and of itself, but because people are terribly bad at setting secure passphrases. Even a seemingly safe, single line from a very obscure Afrikaans poem got someone's brainwallet hacked and 4 BTC taken from it. It doesn't matter how much we educate, people are simply not going to use secure passphrases. If we enforce certain things automatically (say, 25 char minimum length, automated Google search must return no results, must not exist in previously known password caches) we are not only compromising our users by sending their secure password out to check (thus exposing it), but we are raising the barrier to entry to a point that is high enough to irritate newcomers and cause them to walk away in frustration.

The 24 word seed is sufficient for you to use Monero on any computer, and we can definitely look at ways of having a much shorter, password-encrypted base58 token in future.

The author of this post is NOT involved with Monero in any way. I cannot refute some or even most of his findings, but I certainly disagree with the vitriolic voracity with which it is delivered. He is exceedingly angry, and that is at odds with the way any members of the Monero core team view CryptoNote or Bytecoin.

I can only find the one comment that smooth made recently in the Bytecoin thread, and I don't think there is a fundamental problem with engaging cross-thread. We harbour no ill-will against Bytecoin, so to label a tongue-in-cheek comment as "trolling" is a bit of a stretch, don't you agree? I know it's a fine line, but I don't think we're being purposely obtuse or abrasive.

As to those involved with Monero who you label "Monero trolls", we simply cannot control anyone. People are going to say good things and bad things about Monero, and it is not our responsibility or in our best interest to attempt to stifle free speech. There will always be people that passionate like or passionately hate Monero, and that's a good thing, as it encourages intense debate. For those that cross the line to trolling or excessive pandering, I apologise for their behaviour on behalf of the core team. We do not condone it, but we are also not in a position to be able to stop it. Please accept my personal apology as well if the behaviour of anyone even peripherally involved with Monero has offended you in any way.