Cryptonote Explained

You may be 100% correct that block size may end up being served to the users. However, I see two dangers in that, the first already being solved by the masternode network, and that is, it must be kept decentralized. If only a few servers end up being out there to feed the users the blockchain, it would be a huge weakness. The second is that cryptonote requires running through a database to find a match (or verify there is no match) for every coin spent. And if that database gets huge, it will take longer and longer to process, which could slow the whole thing down to a crawl = no more instantX

Everything is give and take, but there may be a way to merge the best of both worlds, we'll have to see :) I certainly need to digest this more :)
 
Here is a little more from Luigi. He made a better diagram :)

I thought perhaps an diagram of my own would help.

8F5Z4oW.png
 
fible1 said:
Just re-read this after a long while, still a great read:

https://cryptonote.org/whitepaper.pdf

Pablo.
Click to expand...

I got confused reading the whitepaper, probably because I'm not familiar with all the technical terms, that's why I needed it "dumb-a-fied" But hopefully after I study it enough in simple terms, I'll get it. I just hope others like me that are not so technical will give understanding this a go. Because it's not always the technical geniuses that see the solutions to the problem at hand, they can sometimes be too close to the problem, and that's where the rest of us can and have been of use. Anyway, knowledge is power, and the more people with knowledge in this community, the more power this community can have ;) LOL.

I'm still getting my eyes crossed reading the whitepaper, but it's definitely the main go to for me to work out how it works :)
 
TanteStefana said:
I got confused reading the whitepaper, probably because I'm not familiar with all the technical terms, that's why I needed it "dumb-a-fied" But hopefully after I study it enough in simple terms, I'll get it. I just hope others like me that are not so technical will give understanding this a go. Because it's not always the technical geniuses that see the solutions to the problem at hand, they can sometimes be too close to the problem, and that's where the rest of us can and have been of use. Anyway, knowledge is power, and the more people with knowledge in this community, the more power this community can have ;) LOL.

I'm still getting my eyes crossed reading the whitepaper, but it's definitely the main go to for me to work out how it works :)
Click to expand...

Yep, it's very thick and I can't say that I got 100% of it but it does get the main points across regarding how ring signatures are meant to work so it's worth to sit down for an hour and then reread it. On the technical side, I don't think I'm qualified to review the math but the sources look legit.

I gotta say I'm very excited by this tech; transparent anonymity is what we should be aiming for I think :). I bet that if Evan wanted to he could improve on this by leaps and bounds; or build something completely new.

Pablo.
 
And here fluffypony explains how they query the blockchain to find inputs. Please, although he's stalking about Monero, the point here is to understand solutions to anonymity. or even techniques of inserting doubt of origin, in whatever function that might be useful in.

Heya,

Not sure if it's been pointed out to you yet, but you may enjoy my talk on Monero from Bitconference:

The brief technical primer starts at the 14 minutes in, and I tried to keep it as accessible as possible. One thing it touches on that may be of interest to you is how the mixing works. Basically transaction outputs are split into powers of 10, so a 123.4 XMR transaction will have outputs of 100, 20, 3, and 0.4 XMR (plus change outputs). Later on if I'm trying to send 100 XMR I will use that previous output as an input in a transaction, but I'll mix just that with other 100 XMR outputs on the blockchain.

Which comes to a point about scalability: obviously scanning the blockchain for outputs to mix with would be slow, so how does Monero do it so quickly? Well, in older clients we kept the entire blockchain in memory, so it was fast, but with the current blockchain database implementation we instead keep a whitelist of mixable outputs grouped by their denomination. So a single call to the blockchain database will take a set of all the mixable 100 XMR outputs, and then randomly choose however many the wallet software needs. It only actually needs to read the output data off disk for the ones it has chosen, not the entire set, so even if there are millions of those 100 XMR outputs it only processes a lookup on the 5 or 10 or whatever that it has randomly chosen (and LMDB, the database engine we use, can grab those from database pages on disk in fractions of a second).

Let me know if you have any questions, and if necessary I'll gladly have a Skype chat with you and answer any questions.

Riccardo
 
TanteStefana said:
And here fluffypony explains how they query the blockchain to find inputs. Please, although he's stalking about Monero, the point here is to understand solutions to anonymity. or even techniques of inserting doubt of origin, in whatever function that might be useful in.

Heya,

Not sure if it's been pointed out to you yet, but you may enjoy my talk on Monero from Bitconference:

The brief technical primer starts at the 14 minutes in, and I tried to keep it as accessible as possible. One thing it touches on that may be of interest to you is how the mixing works. Basically transaction outputs are split into powers of 10, so a 123.4 XMR transaction will have outputs of 100, 20, 3, and 0.4 XMR (plus change outputs). Later on if I'm trying to send 100 XMR I will use that previous output as an input in a transaction, but I'll mix just that with other 100 XMR outputs on the blockchain.

Which comes to a point about scalability: obviously scanning the blockchain for outputs to mix with would be slow, so how does Monero do it so quickly? Well, in older clients we kept the entire blockchain in memory, so it was fast, but with the current blockchain database implementation we instead keep a whitelist of mixable outputs grouped by their denomination. So a single call to the blockchain database will take a set of all the mixable 100 XMR outputs, and then randomly choose however many the wallet software needs. It only actually needs to read the output data off disk for the ones it has chosen, not the entire set, so even if there are millions of those 100 XMR outputs it only processes a lookup on the 5 or 10 or whatever that it has randomly chosen (and LMDB, the database engine we use, can grab those from database pages on disk in fractions of a second).

Let me know if you have any questions, and if necessary I'll gladly have a Skype chat with you and answer any questions.

Riccardo
Click to expand...

Great links!

Pablo.
 
You must log in or register to reply here.
Back
Top