[XMR] Monero - A secure, private, untraceable cryptocurrency

[tezaurop]

New original and unique MONERO abstract paintings-click to zoom,please use PM for any details
Original price  400 USD
Price now 180 USD

click to ZOOM

this true?

[KizaruOG]

Update on current and future achievements regarding XMR adoption.
https://www.reddit.com/r/Monero/comments/6juluf/any_new_updates_on_xmr_adoption/

Summarized it seems that the devs are making Monero now quite easier to adopt. Also - the work on mobile wallets is very unique and great.
If the cryptoworld actually has some logic(which I from time to time doubt) and any financial/economic culture Monero should be at top 3 coins.

Good news!

I'm very proud for the monero team! Good development and marketing.

[birr]

I'm pleased to hear that subaddresses are on the roadmap.  Sounds like it might be a little clumsy to use them, however:

One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056)

It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation.  Have a table of pre-generated addresses, and make sure you don't run out of them.  It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication.

[Nathan047]

Update on current and future achievements regarding XMR adoption.
https://www.reddit.com/r/Monero/comments/6juluf/any_new_updates_on_xmr_adoption/
Summarized it seems that the devs are making Monero now quite easier to adopt. Also - the work on mobile wallets is very unique and great.
If the cryptoworld actually has some logic(which I from time to time doubt) and any financial/economic culture Monero should be at top 3 coins.

This is great, thanks for the share! Also, I'm glad to hear XMR is being added to Coinomi. I already use it so now I'll have the ability to store my XMR on my phone instead of my usual exchanges and mymonero.com.

[Hueristic]

I'm pleased to hear that subaddresses are on the roadmap.  Sounds like it might be a little clumsy to use them, however:

One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056)

It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation.  Have a table of pre-generated addresses, and make sure you don't run out of them.  It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication.

Thanks for pointing this out, for years I never knew this was an issue as I only use a few addresses and all of them are on sites except one.

Because you don't want people to be able to associate you with that anonymous identity by Googling your address, you'd want to use separate wallet addresses for these two purposes. While you can easily do so by simply creating two wallets separately, you're going to spend twice the time for scanning the blockchain and need twice the storage for the wallet cache. And this cost grows in proportion to the number of additional wallet addresses you'd like to have.

[dEBRUYNE]

I'm pleased to hear that subaddresses are on the roadmap.  Sounds like it might be a little clumsy to use them, however:

One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056)

It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation.  Have a table of pre-generated addresses, and make sure you don't run out of them.  It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication.

If I recall correctly, the hashtable contains 10k subaddresses by default, which should be sufficient for the normal user. Although, I agree that in the future we might want to look at a more elegant solution. 

[aminorex]

Is there an official Chinese name for Monero?
私币 is logical but lacks poetry and seems too venial.
私宝币 is only slightly better.
自由币 Perhaps?

[bitebits]

As usual part of aminorex's posts read like Chinese to us mortals.

[Hueristic]

As usual part of aminorex's post read like Chinese to us mortals.

Hah good one.

Is there an official Chinese name for Monero?
私币 is logical but lacks poetry and seems too venial.
私宝币 is only slightly better.
自由币 Perhaps?

Well since Monero is just the English word money in Esperanto I guess you'll have to ask the language experts.

[Millionero]

I'm pleased to hear that subaddresses are on the roadmap.  Sounds like it might be a little clumsy to use them, however:

One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056)

It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation.  Have a table of pre-generated addresses, and make sure you don't run out of them.  It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication.

Thanks for pointing this out, for years I never knew this was an issue as I only use a few addresses and all of them are on sites except one.

Because you don't want people to be able to associate you with that anonymous identity by Googling your address, you'd want to use separate wallet addresses for these two purposes. While you can easily do so by simply creating two wallets separately, you're going to spend twice the time for scanning the blockchain and need twice the storage for the wallet cache. And this cost grows in proportion to the number of additional wallet addresses you'd like to have.

At leastin the CLI wallet, you don't have to scan the blockchain to start a new wallet.  You can choose the block to start the wallet scan at.  So just choose the current block.  You don't need to scan the blockchain for a new wallet, because such a wallet has nothing in it.
Am I right?

[nioc]

^^^ maybe they are talking about after the wallet is created and having to  sync after a certain period of time not having synced it.  Even in this case it seems a non issue to me as the wallet synced very fast, we are not talking about the daemon.

As far as a separate wallet cache, is this really an issue?  Who has just one wallet?  

Edit:  I think if is possible to choose a wallet sync height with the GUI. I created a GUI wallet for the first time not long ago as I needed another wallet where I could easily check tx hx and that is easy to do with the  GUI.

[Hueristic]

I'm pleased to hear that subaddresses are on the roadmap.  Sounds like it might be a little clumsy to use them, however:

One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056)

It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation.  Have a table of pre-generated addresses, and make sure you don't run out of them.  It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication.

Thanks for pointing this out, for years I never knew this was an issue as I only use a few addresses and all of them are on sites except one.

Because you don't want people to be able to associate you with that anonymous identity by Googling your address, you'd want to use separate wallet addresses for these two purposes. While you can easily do so by simply creating two wallets separately, you're going to spend twice the time for scanning the blockchain and need twice the storage for the wallet cache. And this cost grows in proportion to the number of additional wallet addresses you'd like to have.

At leastin the CLI wallet, you don't have to scan the blockchain to start a new wallet.  You can choose the block to start the wallet scan at.  So just choose the current block.  You don't need to scan the blockchain for a new wallet, because such a wallet has nothing in it.
Am I right?

^^^ maybe they are talking about after the wallet is created and having to  sync after a certain period of time not having synced it.  Even in this case it seems a non issue to me as the wallet synced very fast, we are not talking about the daemon.

As far as a separate wallet cache, is this really an issue?  Who has just one wallet? 

Edit:  I think if is possible to choose a wallet sync height with the GUI. I created a GUI wallet for the first time not long ago as I needed another wallet where I could easily check tx hx and that is easy to do with the  GUI.

I have no clue maybe it is old info that wasn't updated? I'd like to know though.

[Kryptowerk]

Strong signals for Monero - You guys may like this (or not): https://www.youtube.com/watch?v=k5GILFQKJR4&t=45m49s
Personally I would be happy to see some more realistic prices, especially in comparison to Dash.

[USAS-12]

Announce!Special price on XMR!!!

Trusted OTC exchange runs on a new level! Now we are accepting any cryptocurrency!
If you need to make fast and well priced exchange we are here to help you!

Your privilege:
Fee - 1% from the deal
Minimum transaction amount - $500
The best counterparty range
Fast and smooth exchange
2 ways of support during the deal
Escrow service/agent upon request

In this regard, we're announcing the Special price on XMR!!!

Write me now to get more information!

[CryptoScientist]

Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?

[Febo]

Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?

They were every half year. Next should be in few months. I am sure block number is already set.  In anonymity aspect it should set minimal mixing. Basically is not really  needed, and that was a reason why i had problems to remember why this hard fork is needed,  since like only 0.1% of transactions are non RingCT.

[nioc]

Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?

They were every half year. Next should be in few months. I am sure block number is already set.  In anonymity aspect it should set minimal mixing. Basically is not really  needed, and that was a reason why i had problems to remember why this hard fork is needed,  since like only 0.1% of transactions are non RingCT.

It is not mixing it is ring signatures.  Ring signatures was also given an unfortunate name of mixin for the number of signatures for a transaction other than yours.  mixin does not equal mixing.  The other thing the Sept fork will do is make it mandatory for the minimum ring signature to be 5 (mixin 4) and currently that minimum is 3 (mixin 2)

Please note that there is discussion about increasing the mandatory minimum ring signature size beyond 5 for this Sept.  No decision has been made regarding it at this time.

[smooth]

Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?

They were every half year. Next should be in few months. I am sure block number is already set.  In anonymity aspect it should set minimal mixing. Basically is not really  needed, and that was a reason why i had problems to remember why this hard fork is needed,  since like only 0.1% of transactions are non RingCT.

The more significant change in this fork will be increasing the minimum ring size. Although the default is 5, still a very high number of transactions use 3 (because people want to reduce cost and choose the minimum, even though this is currently a negligible savings). The fork will increase the minimum to at least 5 and possibly higher. The cost difference of even 10-20 is currently fairly small, and the improved resistance to blockchain analysis is significant.

Mandatory RingCT is largely irrelevant as you point out since nearly all already use RingCT and that would continue to get closer and closer to 100% anyway.

[binaryFate]

XMR.TO introduces zero-confirmation, instant conversions.
We also added integrated addresses, and increased the maximum amount you can convert in one go to 20BTC.

Enjoy!

[Hueristic]

ExchangeD.I2P will be starting Monero trading on July 1

Traders will be able to exchange Monero for Bitcoin anonymously without any KYC or ID verification

Also Traders can Trade Monero for USD, EUR and other Fiat currencies using our P2P Fiat exchange

Nothing up yet, I'll have to check it out when I get back. Looking forward to seeing your XMR support. Guess I'll have to setup I2p.