Author

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

legendary
Activity: 3836
Merit: 4969
Doomed to see the future and unable to prevent it

Quote
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

What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ?

Amounts of transactions are not hidden.

http://moneroblocks.eu/

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.

Thx for the more in depth explanation, I added to my post above. Maybe you could answer that for me?
legendary
Activity: 2968
Merit: 1198

Quote
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

What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ?

Amounts of transactions are not hidden.

http://moneroblocks.eu/

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.
legendary
Activity: 3836
Merit: 4969
Doomed to see the future and unable to prevent it

Quote
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

What do you mean it will be private ? Isn't it already private (with mixin) ? Am I wrong or are Confidential Transaction more obscure than current implementation ?

Amounts of transactions are not hidden.

http://moneroblocks.eu/


...

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

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



xa4
member
Activity: 71
Merit: 10
Hi GingerAle,

Thanks for your summary.

Two things I don't quite understand.

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.

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

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.
sr. member
Activity: 252
Merit: 251
I'd appreciate a dev going more into why 0MQ is a better choice than RPC.

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?

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.
sr. member
Activity: 371
Merit: 250
I'd appreciate a dev going more into why 0MQ is a better choice than RPC.

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?
sr. member
Activity: 373
Merit: 250
Thank you for the update. LMDB seems interesting indeed.

Quote
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.

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?

Quote
0MQ is already implemented in the development branch, and its quirks are being worked out.

I'd appreciate a dev going more into why 0MQ is a better choice than RPC.
legendary
Activity: 1260
Merit: 1008
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.

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

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.
legendary
Activity: 1276
Merit: 1001
Also, is there (plans to implement) an RPC or 0MQ call to shutdown bitmonerod or simplewallet (gracefully)?

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.
sr. member
Activity: 373
Merit: 250
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.
hero member
Activity: 794
Merit: 1000
Monero (XMR) - secure, private, untraceable
//offtopic. I'll delete it if against the rules.

We are raising donations for this campaign. There are already 351$ and 0.0403 BTC in donations for Bojia:
"The 80 years old mother Bojia Bikova was accused of growing hemp by the Bulgarian police, who found a few uprooted sprigs of hemp in her field in the countryside. She was sentenced to pay about $1100 including court taxes. The monthly pension of old mother Bojia is $100. The amount she has to pay is close to the full amount of her pension for the whole year."
You could watch a short video about her case here: https://www.youtube.com/watch?v=gqmGkti9uUQ.
I created an XMR address for this campaign. Please support it. If in doubt about the validity of the address, I could ask our admin to add an OpenAlias XMR address to promena.org:
Code:
49bXbjMqAGmQCApWssWKMd9pnMq2AnExkUCrajnAeGM6dsJNagvwCd8VQxVWs3gamMQTxWirG9yrEeKpSocFyTGbH4TEvu4

//offtopic
This may be the first non-governmental organization accepting Monero donations for its campaigns. We added OpenAlias xmr address to promena.org. It seems that the domain registrar is not adding TXT DNS records correctly with their GUI. They are adding "invisible spaces" like the space in the Monero address in bitcointalk (you could see the spaces here - type promena.org and select TXT record: http://manytools.org/network/query-dns-records-online). The result is that you can't add a valid OpenAlias address (or any valid long words TXT record). How many domain registrars are out there which are doing the same?
The domain registrar fixed their bug and the OpenAlias address promena.org is now working for the "Bojia" campaign. My contribution is 20 XMR. I'll make sure the total sum of Monero donations is cited at the end of the campaign and I'm pretty sure a successful campaign will catch some media attention (Bulgarian media are already following the "Bojia" case).

OpenAlias Monero address added to promena.org for the "Bojia" campaign. You could now send XMR to promena.org - there are 107 XMR in donations till now.

Donation of 25 XMR just sent

Great. Thank you! We are at 371$ + 134 XMR + 0.0402 BTC. 12 days left till the end of the campaign.


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.
legendary
Activity: 3836
Merit: 4969
Doomed to see the future and unable to prevent it
Anyone have an idea why there is such a large percentage of 7.8255 XMR sized transactions?

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.


W0w it's dropped that much! I thought it was in the 9's.
legendary
Activity: 2968
Merit: 1198
Anyone have an idea why there is such a large percentage of 7.8255 XMR sized transactions?

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.
legendary
Activity: 3836
Merit: 4969
Doomed to see the future and unable to prevent it


THIS IS GENTLEMEN! 

moneroblocks.eu now shows the participating outputs in each ring signature. Enjoy.



Looks great!

Anyone have an idea why there is such a large percentage of 7.8255 XMR sized transactions?
legendary
Activity: 2968
Merit: 1198
Anyone tried building for ARM and running on a tablet or raspberry pi? Do you also need to use BDB there?

Yes and yes

Quote
Also, is there (plans to implement) an RPC or 0MQ call to shutdown bitmonerod or simplewallet (gracefully)?

Pull requests accepted. Smiley
legendary
Activity: 3136
Merit: 1116
Anyone have working win32 binaries that they compiled? Is it really tricky to build Berkeley DB on windows?

Anyone tried building for ARM and running on a tablet or raspberry pi? Do you also need to use BDB there?

Can you build a simplewallet target without any database, LMDB or BDB, for win32 or ARM?

Also, is there (plans to implement) an RPC or 0MQ call to shutdown bitmonerod or simplewallet (gracefully)?
legendary
Activity: 1276
Merit: 1001
Git updates since last time:

Since last post:

- the IP banning code from Aeon got merged, and new commands/RPC for managing bans
- wallet refresh speedup (both parallelizing things, and avoiding others)
- a --restricted-rpc for the daemon (so others can't mine on your public node, for example)
- an option to let the wallet autmatically refresh periodically from the daemon
- a new show_transfers command to display transactions in a more useful way
- outgoing transactions info is now kept in the wallet cache so show_transfers can be even more useful
- the daemon will relay transactions periodically if they stay in the pool for too long (if they failed to relay, for instance if the network connection was down when the tx was first sent, for instance)
legendary
Activity: 1260
Merit: 1008


THIS IS GENTLEMEN! 

moneroblocks.eu now shows the participating outputs in each ring signature. Enjoy.


marvelous work!

now its blatantly obvious how opaque monero transactions really are. There'll be a tip coming your way!!!
hero member
Activity: 649
Merit: 500


THIS IS GENTLEMEN! 

moneroblocks.eu now shows the participating outputs in each ring signature. Enjoy.

legendary
Activity: 1105
Merit: 1000
Same issue with beta version for Windows (2015-Nov-01). Sometimes daemon successfully closes after first "exit" command, sometimes it needs to read second "exit".

I think I know what the problem is. It requires a coder with Windows (and some knowledge of windows APIs) to add a bit of code though. In contrib/epee/include/console_handler.h, the wait_stdin_data needs some code to implement what the select does (wait till there is data on stdin, while we're not told to stop). As it is, the Windows version will not care about that and go into a blocking std::getline, and I think there's a good chance you're getting stuck in that. Anyone with the above description to do this ? It's pretty simple if you know the right Windows API for this (assuming the API is not stupidly).


On the other hand, I run a daemon on Windows and *never* have to exit twice. Though, if I "exit" while the daemon is still starting up, craziness happens (it has to be killed).
Jump to: