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

Thx

If I recall correctly, this one -> https://github.com/monero-project/bitmonero/tree/development

I remember reading a while back that 0MQ is in one of the developmental branches.  If I wanted to play around with that, which branch/repo should I clone?

There is an exception for that.

Also, non-standard outputs can't be created any more, so they will eventually be "used up".

The original crypto code was taken from Daniel J. Bernstein's library without attribution, slightly modified (though the modifications have been reviewed and were not nefarious).

The copied/modified code has been replaced by the actual, original Danlel J. Bernstein crypto library, which makes more clear the source and integrity of the crypto library. It will also make it easier to incorporate upstream patches to the crypto library if any are released.

Here is an ELI5 for if it's not clear for you after reading the other comments:

ELI5: Next to hidden origins and destinations that are inherent to the Monero protocol (provided by ring signatures + stealth addresses), this will also hide amounts, while viewkeys will still work, and of course it will still be auditable.

See this particular commit -> https://github.com/monero-project/bitmonero/commit/0a4bc84b2f681dfd89b501648f65a951d876e2d8

Basically, Shen Noether included the reference code used by Bernstein et. al. (http://ed25519.cr.yp.to/ed25519-20110926.pdf)

Thx for the more in depth explanation, I added to my post above. Maybe you could answer that for me?

Mixin doesn't hide amount of transactions, it hides the source. However, amounts are somewhat hidden by change. A small amount of work has been done to improve how the wallet constructs transactions to improve the ambiguity of amounts and some more work has been done to come up with methods to improve that. They may or may not be made obsolete by RingCT though.

Amounts of transactions are not hidden.

http://moneroblocks.eu/



Do you have a link for a more detailed explanation on this?

Hi GingerAle,

Thanks for your summary.

Two things I don't quite understand.

just a few benefits:
 - multiple calls over one tcp connection
 - loadbalancing
 - automatic retry handling (eg when server restarts)
 - reliable

EDIT: 0mq is to http what tcp is to udp.. much more useable and less hassle for 3parties.

not an expert i 0MQ, but:

RPC = remote procedure call
0MQ will still used as remote calls (aka RPC)

0MQ is more the underlying tech/lib/... which will handle the RPC requests, or am i wrong?

Thank you for the update. LMDB seems interesting indeed.


If I recall the proposal correctly, it imposes a new rule on outputs. They cannot be spent in the next transaction unless a minimum mixin is provided. Correct me if I'm wrong. But what about the case when certain inputs cannot be mixed due to absence of ringsig partners?


I'd appreciate a dev going more into why 0MQ is a better choice than RPC.

I can provide a quick update, but I don't know if it will be a correct update

The current push is to get the 0.9 binaries released, which include major improvements over the last release. In-line with the development priorities after the block 20612 attack (https://bitcointalksearch.org/topic/m.8677607), the primary improvements are in the underlying protocol. I can't give a full rundown of what these are, and its been listed somewhere before, but IMO a main improvement is the movement of the blockchain to an LMDB database. LMDB is quite an impressive database solution - it has dynamic memory usage, so if your system has the available RAM and bitmonerod needs it, then it will use it. However, once its done needing all of this ram (mostly during sync), the 0.9 binaries use about 50 MB of RAM. Furthermore, LMDB was built to withstand database corruption. So if you lose power, or your daemon exits uncleanly, your database is intact. This is in contrast to mostly all other cryptocurrencies that use bdb, which apparently requires re-indexing or something after not-so-uncommon events. Indeed, I find the fact that monero is the only cryptocurrency using LMDB kind of ridiculous, considering that the entire technology is based on a database.

Currently with work with the database improvements is to ensure all of the failovers / other implementations are functioning properly... i.e., a bdb implementation is still necessary for 32 bit systems, and ARM systems also require a different solution than LMDB, so I think these are the final sanity checks before 0.9 is released.

Another interesting improvement is change of the base cryptography to the actual standard, as opposed to the cryptonote version of the cryptography.

The above two instances sort of exemplify the work thats been done leading up to the 0.9 release - the cryptonote codebase was a bit messy (apparently... im just regurgitating what I've been told because im no coder). Thus, in order to actually make the network stable, the underlying code had to be improved.

Additionally, there are some pretty core changes in the protocol being implemented for an upcoming hardfork. Primarily, a minimum mixin will be required - this significantly enhances the privacy of the blockchain. For research in the minimum mixin and mixin 0 problem, check out one of the Monero Research Bulletins. Blocktimes will also be changed to 2 minutes in order to try and fix the amount of reorgs that occur.

Finally, a lot of work has been done in simplewallet to increase the utility of actually using the monero protocol / blockchain / network. For instance, one can now use integrated payment IDs, instead of attaching a payment ID to a transaction. This also increases privacy because in the cryptonote implementations, payment IDs are unencrypted / unmasked etc.... essentially just plain text on the blockchain. Now only the sender and receiver can de-code the payment ID. There are also view-only wallets, providing users with some security knowing that intruders onto their hardware can't use their bins to spend their monero. Simplewallet sync times have also been improved.

Thats the stuff that manifests most obvious to me, as a non-coder monero enthusiast that plays around with the software to beta test etc. This is probably a disservice to the coders that have worked on this, because there's probably a lot more.

The next wave of work going into the next release will also be amazing. 0MQ is already implemented in the development branch, and its quirks are being worked out. i2p integrating is also going into the development branch. Ring-confidential transactions will also be in the development branch at some point, which means that now the amount of a transaction will also be private.

The easy answer would be to point you here: https://getmonero.org/design-goals/

Long story short, if I had more money I'd be buying more monero.

There is one for the daemon (stop_daemon), but not the wallet. I'll add that next time I hack on it, it's pretty simple.

Hey everyone,
Can anybody provide a quick update as to what's been up to Monero development recently and what the short/mid term goals are.

Thanks.

The Indiegogo campaign ended on on December 2, 2015 with $376 USD in donations. The bithope campaign is still on 0.0402 BTC and the XMR campaign is still on 134 XMR. Converted to Bulgarian Lev (that's what the fine should be paid in) on today's rate that makes 810 BGL (45% from the 1800 BGL needed for the fine). We are still accepting BTC and XMR donations and we'll soon decide what to do next.

W0w it's dropped that much! I thought it was in the 9's.

That is approximately the size of the current block reward (coinbase). Although the transaction you included in your post had inputs so it wasn't a coinbase, it was probably a miner or pool moving one of their block rewards.