Here's gmaxwell's original write-up on Confidential Transactions: https://people.xiph.org/%7Egreg/confidential_values.txt

Here's Denis Lukianov's latest paper on Compact Confidential Transactions: http://voxelsoft.com/dev/cct.html

Finally, here's the WIP paper that Shen Noether, of the Monero Research Lab, has been focusing on: https://github.com/ShenNoether/MiniNero/blob/master/RingCT0.3.pdf

YOU KEEP QUIET...YOU LETTER ON A KEYBOARD!

(I jest, I'm in agreement that we should just mellow out, no use in getting uppity)

Sure, it's an absolutely valid concern.

I think the important thing is not to compare Monero's block size with Dash, but firstly with Bitcoin so that we have a baseline. Monero's transactions are smaller than Bitcoin's, like-for-like. So if Monero were a "transparent blockchain" like Bitcoin's we would have a smaller blockchain than Bitcoin for the same transactions! But since part of Monero's "opaqueness" involves hiding the origin of transactions by making inputs appear to come from multiple transactions, this incurs an additional size penalty. This means that, for the same number of transactions, Monero's blockchain is about 4-5 times bigger than Bitcoin's.

It is important to note, though, that any privacy feature will have a similar impact. Dash's DarkSend, centralised Bitcoin mixing services, or even decentralised initiatives like JoinMarket (which is built on the CoinJoin scheme) all have an increased transaction size. If they are enforced on every transaction (ie. on a protocol level) it means the entire blockchain is significantly larger - and that applies to Bitcoin too!

The reality when it comes to blockchain sizes is that linear blockchain bloat is largely insignificant. What I mean when I say that is this: which is more convenient to host, a 350gb blockchain, or a 1.58tb blockchain? Well they're both inconveniently large, and whilst you could argue that a 350gb blockchain fits on a 512gb SSD today (where a 1.58gb blockchain doesn't) it's obviously growing so fast it'll outstrip that storage space in a matter of months. Basically any blockchain above, like, 20gb is a complete pain in the posterior.

The solution to this problem is not to try incremental, linear decreases in blockchain size. If you have a useful cryptocurrency that people are using the blockchain is going to be large. Suck it up, embrace it, accept it right now. Rather, the long-term solution can be found in blockchain pruning, whereby we cut off all the historical data and only keep a subset (the utxoset for Bitcoin, and the txoset + key image set for Monero). In this Bitcoin has a slightly different approach to Monero, where nodes are either "archival" (keeping the entire blockchain) or "current" (keeping a small portion). With Monero we will be implementing pruning in a per-node configurable basis, where node operators can choose to either keep the whole chain (default), keep only the last M blocks, or keep everything from block N. This will mean that, as a node syncs up, it will find progressively more nodes that have the blocks it is requesting, until it reaches the top block in the network, and every node has that available:)

It's one of those situations where we can't qualify every statement that is made.

It's like saying that we should change the Monero slogan from "secure, private, untraceable" to "secure (as long as you don't leak your private keys and no exploit or bug exists which lets someone steal your funds), private (as long as you're using i2p, coming soon, and the counterparties you deal with don't reveal your details), untraceable (as long as everyone is using mixin >0 and no systematic reveal of inputs leaks the real one)"...which is not quite as catchy;)

That's news to me...what sickness do I have? Let me know so I can tell my doctor.

Perhaps you're thinking of this: https://www.youtube.com/watch?v=09LTT0xwdfw

That's fair enough, and I apologise for misreading your comment as trolling.

Two things, then. First up, it hasn't occurred (at all) since that thread, and at the time I could not reproduce it by regular access even from different machines around the globe. I also couldn't reproduce finding the errant code (as it would appear by default, ie. without fudging JS versioning) either via archive.org or in Bing / Google's cache. Since then I have checked periodically to see if it is appearing, but have not seen the session-to-cookie snippet pop up. The snippet has not existed on the server in any way, shape, or form for many, many months, and so I can only assume it was isolated and unexpected. Needless to say that if it *is* ever reproducible by me then I will be able to tackle the exact cause and fix it from there.

Which leads me to the second thing I wanted to mention: I made it clear in that original thread, and it behoves repeating, web-based wallets are not "safe". Where a local wallet has a set of security risks (eg. a deviant local process can hijack your transactions as they are being built and redirect the funds) web wallets open up an additional class of security risks: trusting code that is delivered live, and passes through multiple points on the Internet. Using MyMonero involves trusting your ISP, trusting CloudFlare, trusting the CA, trusting MyMonero, and trusting the various data providers en-route, each and every time you use the web wallet. That having been said, MyMonero represents a smaller attack surface than a Bitcoin / altcoin-based web wallet where the keys are held on the server, as MyMonero is unable to spend funds independently of the user. Thus this attack would involve serving up compromised JavaScript, which would be noticed were it done on any sort of scale.

To that end, I'd like to reiterate my original comment from our previous discussion on the security of MyMonero:


One final bootnote: the view key is sent to the MyMonero server every single time, so we don't state that "no keys" are sent to the server, merely that the spend key is not. That is a factually correct statement, barring any number of circumstances outside of our control, such as a user's ISP being compromised. I hope it is unnecessary for me to qualify that statement every time I make it:)

I'm going to hazard that you're not BlockaFett, as he and I had a good chat about this months ago and all was resolved. He seemed a reasonable, logical person who understood the situation and was content with the resolution.

He's also perfectly capable of following up on his own research, you seem to lack the technical chops to do so. Pity, one always hopes that trolls will be a little less "talk" and a little more "action".

Nonetheless, it's probably not a bad idea for you to exit stage right and let BlockaFett talk on this matter if he so desires.

Let's imagine I have some coins that I stole during Evolution's demise. Are you willing to swap all of your coins for mine?

Or put differently: if I borrow your car for a month, and at the end of that month I give you back the same make, same model, same year, same colour car, is that ok?

Bitcoin isn't fungible for the same reason that you won't appreciate me giving you some random car in exchange for yours, regardless of the properties of that car.

Muhahahahahaa...I'm secretly raising an ARMY of ponies!

We're going to...uh...errrrm...have the best petting zoo of all time!

1. Yes, which is actually surprising considering we didn't know each other at all before we found Monero and each other (some of us knew of each other, othe and I spoke a bit because he'd bought GPU frames from me)
2. I think 1 is a testament to this: we share a vision, and because of that we get along
3. Well we're certainly not perfect, and we are going to sometimes say things out rightly incorrect or based on flawed assumptions. You'll notice that there are no qualms about disagreeing with each other or correcting each other, even publicly, because we're not "buddies". We sharpen each other and bring out technical excellence in each other.
4. Yes very much so. We were very keen on pushing a GUI out until the block 202612 attack, which was a huge wake-up for us. Realising the fragility of the Monero code and network helped us get on track and re-prioritise.
5. Yes

I think it's naïve to imagine we'll never have a serious disagreement, but I also think that individually we've got less of an "ivory tower" complex than expected. We're all generally accepting of each other's ideas, and we also don't hold on to our mistaken beliefs which such vigour that we can't accept correction. We seem to be comfortable with our lives and individual success, so ego and pride rarely play any role in discussion and decision-making.

There are a handful of small things we need to finish and merge into development and master before we can release 0.9 RC, and then go from there.

That's correct - the import function is a convenience tool for people who want mobile access to an existing wallet or similar. It chews up some of the CPU cores on the backend (and hammers the disk) whilst it scans through the whole blockchain, so the fee is for us to offset the added cost of extra availability for this.

This may be an obvious question, but you have enough free disk space, right?

Bear in mind that the memory usage is NOT constant. LMDB is greedy for free memory so it can cache aggressively, but it's also very willing to give that memory up to anything else that needs it. On an under-utilised system you can expect LMDB to suck up as much available memory as it can, whereas on a busy system you'll see it drop down to the <100mb mark for the most part.

Oh look at you go, I was trying to figure out how the offline generator could be generating seeds that MyMonero can't detect are simplewallet seeds, looks like you've solved it:) Will you PR it to the offline generator?

That...is...weird.

MyMonero's viewkey is completely wrong, it should be 0a731057880aec5b222887ee5101e5d8b6c0734c30cefb293f512f4c75637009. I'm going to have to figure out what's gone wrong.

Did you use the HTML offline generator, as in this one: https://github.com/moneromooo-monero/monero-wallet-generator ?

Bit of both - syncing up only requires tx/block verification, whereas simplewallet actually has to check each transaction for your viewkey. The other problem is that there's no parallelisation in simplewallet, and it chews memory on large wallets (as it keeps the entire cache in-RAM which is silly). We'll be addressing both of those in a future release.

Not yet - we're getting segfaults on older versions of OS X, busy fixing it now. Beta binaries are compiled sorta on-demand when someone is helping to test a specific feature / commit but doesn't have a compile environment.

This is from last week: https://downloads.getmonero.org/monero.win.x64.v0-9-beta.zip

Exercise the appropriate level of care with it being a beta. We've recently found and solved what we hope to be the only major, breaking database issue (that could have caused major issues if we'd tagged prematurely), but that means that prior LMDB sync ups have to be resynced from scratch or imported from a fresh blockchain.raw export.