[XMR] Monero Speculation

[TrueCryptonaire]

I wont comment on the probably of failure because I do not feel qualified to quantify it.

I will say that the longer the community continues to grow and development progress continues to be made the greater the chance of success.

Look up all the coins that were launched with a bitcointalk announcement last year around the same time as Monero.  Monero is doing better that 99% of them. Many thousands of coins have been launched over the last year. How many of those has a community as strong as ours?

Of those with a strong community how many are had a premine, instamine or fastmine? How many allow for private transactions at the protocol level without and form of centralized mixing?

Most coins now seem to be designed with a very short PoW period followed by a conversion to PoS to make the developers BTC quickly. Unfortunately this model does not have the proper incentives for lasting development or growing a community.

Monero is built to last. Lots of progress has been made but XMR prices are still lower than they were last summer. This is a wonderful thing for potential community members looking at Monero. New community members can buy Monero at prices lower than many early adopters did a year ago! However this period is unlikely to last much longer as emission is slowing and demand will soon far outweigh supply from the miners.

I think it is possible that the next month or two (before translations and worldwide marketing plans are ramped up and while less than 50% of XMR has been mined) may be the last opportunity to buy Monero at anywhere near these price levels.

Of course this is just my opinion and I could be completely wrong. I look at many coins quite carefully. There are none that I am nearly excited about as Monero.

I tend to agree with you.
The emission looks now great and the chart and supply of coins in exchanges is pretty scarce which makes the coin potentially very explosive even if we get a moderate amount of new money into Monero.

However, if Monero takes off, it is cheap buy even for 0.50 BTC.

Cheap at .5 BTC? So you expect XMR to reach BTC parity?

Even more.
I am waiting here once Risto makes calculations on how many XMR can each person own in the world in our generation even if the coin is shared equally (very unlike scenario - usually there are a few big guys, the elite, and the rest are small peasants).

[newb4now]

I wont comment on the probably of failure because I do not feel qualified to quantify it.

I will say that the longer the community continues to grow and development progress continues to be made the greater the chance of success.

Look up all the coins that were launched with a bitcointalk announcement last year around the same time as Monero.  Monero is doing better that 99% of them. Many thousands of coins have been launched over the last year. How many of those has a community as strong as ours?

Of those with a strong community how many are had a premine, instamine or fastmine? How many allow for private transactions at the protocol level without and form of centralized mixing?

Most coins now seem to be designed with a very short PoW period followed by a conversion to PoS to make the developers BTC quickly. Unfortunately this model does not have the proper incentives for lasting development or growing a community.

Monero is built to last. Lots of progress has been made but XMR prices are still lower than they were last summer. This is a wonderful thing for potential community members looking at Monero. New community members can buy Monero at prices lower than many early adopters did a year ago! However this period is unlikely to last much longer as emission is slowing and demand will soon far outweigh supply from the miners.

I think it is possible that the next month or two (before translations and worldwide marketing plans are ramped up and while less than 50% of XMR has been mined) may be the last opportunity to buy Monero at anywhere near these price levels.

Of course this is just my opinion and I could be completely wrong. I look at many coins quite carefully. There are none that I am nearly excited about as Monero.

I tend to agree with you.
The emission looks now great and the chart and supply of coins in exchanges is pretty scarce which makes the coin potentially very explosive even if we get a moderate amount of new money into Monero.

However, if Monero takes off, it is cheap buy even for 0.50 BTC.

Cheap at .5 BTC? So you expect XMR to reach BTC parity?

Even more.
I am waiting here once Risto makes calculations on how many XMR can each person own in the world in our generation even if the coin is shared equally (very unlike scenario - usually there are a few big guys, the elite, and the rest are small peasants).

Obviously there will never be enough Monero for everyone in the world to on an entire coin but everyone could own a fraction of one coin.

Of course I don't think this is a realistic goal for any coin including BTC. It is 2015 and there are still people who do not have a cell phone or an email address.

For people that do not care about privacy BTC will be enough. I still think the market for Monero will be very large. Once LMDB and the official GUI are released interest could grow very quickly among non techie users, which is a much bigger market than the largely privacy focused tech savvy crowd we have now

[TrueCryptonaire]

The thing is Monero is owned by people who do not really care to sell unless they want to play a little pinball game like me. 

Personally I am not interested in selling any coins in 1 digit and even two digits I will think carefully if I start implementing SSS. When Monero is traded in hundreds, I might make a SSS plan from there. Knowing my standard of living and willingness for fancy life, I think I will not need that many coins to sell. I could easily live happily in a farm in nowhere growing my own food.

[newb4now]

What do you predict the XMR price will be once LMDB and the official GUI are released?

How close is LMDB to being tagged for official release? I have heard it has been very close for several months and doing well in testing

[TrueCryptonaire]

Perhaps it will rise the price for a couple per centages due to the fact that the risk has lowered.
However, I am not expecting a lot of movement in the price as the GUI has priced already in the coin. If those projects fails completely (which will not happen since we have a good enough GUI called mymonero), it might affect on the price negatively.

[dEBRUYNE]

I wont comment on the probably of failure because I do not feel qualified to quantify it.

I will say that the longer the community continues to grow and development progress continues to be made the greater the chance of success.

Look up all the coins that were launched with a bitcointalk announcement last year around the same time as Monero.  Monero is doing better that 99% of them. Many thousands of coins have been launched over the last year. How many of those has a community as strong as ours?

Of those with a strong community how many are had a premine, instamine or fastmine? How many allow for private transactions at the protocol level without and form of centralized mixing?

Most coins now seem to be designed with a very short PoW period followed by a conversion to PoS to make the developers BTC quickly. Unfortunately this model does not have the proper incentives for lasting development or growing a community.

Monero is built to last. Lots of progress has been made but XMR prices are still lower than they were last summer. This is a wonderful thing for potential community members looking at Monero. New community members can buy Monero at prices lower than many early adopters did a year ago! However this period is unlikely to last much longer as emission is slowing and demand will soon far outweigh supply from the miners.

I think it is possible that the next month or two (before translations and worldwide marketing plans are ramped up and while less than 50% of XMR has been mined) may be the last opportunity to buy Monero at anywhere near these price levels.

Of course this is just my opinion and I could be completely wrong. I look at many coins quite carefully. There are none that I am nearly excited about as Monero.

I tend to agree with you.
The emission looks now great and the chart and supply of coins in exchanges is pretty scarce which makes the coin potentially very explosive even if we get a moderate amount of new money into Monero.

However, if Monero takes off, it is cheap buy even for 0.50 BTC.

Cheap at .5 BTC? So you expect XMR to reach BTC parity?

If XMR moves into the (at least) 20 trillion dollar "offshore private wealth storage" market before bitcoin does, then it can be as big or bigger than bitcoin.

I see no evidence that bitcoin has made any real advances into this area. Otherwise, it wouldn't have such a tiny market cap. The market is "up for grabs."

Bitcoin is the best candidate for this market if you are looking at hashing power and development activity. But XMR offers banking privacy which is something that you have (to some degree) in Switzerland and the Cayman Islands, yet bitcoin lacks it.

  

Thanks for the reply! I've used the Cayman Islands as a way of describing the relationship of XMR to BTC. I had no idea it was worth 20 trillion!

It's actually way more than that, the average person has no access to Cayman Islands, Monero is readly available, functional and at reach

And you aren't subject to political swings or untangling yourself from the fine print with Monero. Anyone who has seen Blow or Wolf of Wall Street should know that Panama and Sweden were safe havens until they weren't. The solutions are sometimes riskier than the problems.

Cayman Islands won't be a safehaven for long anymore -> http://www.armstrongeconomics.com/archives/33889

[smooth]

What do you predict the XMR price will be once LMDB and the official GUI are released?

How close is LMDB to being tagged for official release? I have heard it has been very close for several months and doing well in testing

One key milestone is improving the meager performance of the first db implementation so the orphan rate doesn't shoot up and also so the node doesn't become impractical to use on low-end systems (which was part of the motivation for the database in the first place).

Good news! The excellent optimization work by Noodle Doodle (in some cases faster than the original in-memory version!) has been completed and a pull request was submitted moments ago: https://github.com/monero-project/bitmonero/pull/337

Additional testing will be needed and there are still a few loose ends but this is a major step toward the database being pushed out as a tagged build.

Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool ().
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).

Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.

LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5

ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.

[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
   This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.

[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
   a. 0 = Compute long hash per block (may take a while depending on CPU)
   b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
   a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
   b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
   Fast    - Write meta-data but defer data flush.
   Fastest - Defer meta-data and data flush.
   Sync    - Flush data after nblocks_per_sync and wait.
   Async   - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
        Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
   Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
   For berkeley-db only. Auto remove logs if enabled.

**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
   At the moment, you need a full resync to use this optimized version.

[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.

Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block

**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop,  Quad-core / 8-threads 2600k  (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop,   Dual-core / 4-threads U4200  (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).

lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop,  Quad-core / 8-threads 2600k  (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).

berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k  (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months() into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).

berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).

[newb4now]

What do you predict the XMR price will be once LMDB and the official GUI are released?

How close is LMDB to being tagged for official release? I have heard it has been very close for several months and doing well in testing

One key milestone is improving the meager performance of the first db implementation so the orphan rate doesn't shoot up and also so the node doesn't become impractical to use on low-end systems (which was part of the motivation for the database in the first place).

Good news! The excellent optimization work by Noodle Doodle (in some cases faster than the original in-memory version!) has been completed and a pull request was submitted moments ago: https://github.com/monero-project/bitmonero/pull/337

Additional testing will be needed and there are still a few loose ends but this is a major step toward the database being pushed out as a tagged build.

Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool ().
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).

Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.

LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5

ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.

[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
   This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.

[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
   a. 0 = Compute long hash per block (may take a while depending on CPU)
   b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
   a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
   b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
   Fast    - Write meta-data but defer data flush.
   Fastest - Defer meta-data and data flush.
   Sync    - Flush data after nblocks_per_sync and wait.
   Async   - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
        Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
   Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
   For berkeley-db only. Auto remove logs if enabled.

**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
   At the moment, you need a full resync to use this optimized version.

[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.

Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block

**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop,  Quad-core / 8-threads 2600k  (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop,   Dual-core / 4-threads U4200  (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).

lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop,  Quad-core / 8-threads 2600k  (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).

berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k  (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months() into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).

berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).

Wow, thanks for the update Smooth

Those are major performance improvements

Nice work Noodle Doodle!

[TrueCryptonaire]

I just bought a couple hundred Moneros.
My stack is growing as I consider the current price a bargain.

[arnuschky]

What do you predict the XMR price will be once LMDB and the official GUI are released?

How close is LMDB to being tagged for official release? I have heard it has been very close for several months and doing well in testing

One key milestone is improving the meager performance of the first db implementation so the orphan rate doesn't shoot up and also so the node doesn't become impractical to use on low-end systems (which was part of the motivation for the database in the first place).

Good news! The excellent optimization work by Noodle Doodle (in some cases faster than the original in-memory version!) has been completed and a pull request was submitted moments ago: https://github.com/monero-project/bitmonero/pull/337

Additional testing will be needed and there are still a few loose ends but this is a major step toward the database being pushed out as a tagged build.

Congratulations, and thanks to everyone involved, especially NoodleDoodle. Great to hear that Monero is moving forward! 

Is there any news of the GUI? Haven't heard about this in months, but admittedly, I didn't follow this thread as close as I used to do... 

[findftp]

The thing is Monero is owned by people who do not really care to sell unless they want to play a little pinball game like me.  

Personally I am not interested in selling any coins in 1 digit and even two digits I will think carefully if I start implementing SSS. When Monero is traded in hundreds, I might make a SSS plan from there. Knowing my standard of living and willingness for fancy life, I think I will not need that many coins to sell. I could easily live happily in a farm in nowhere growing my own food.

But dude, why the fuck do you need all the wealth of the world when you only have a farm and grow your own food?
You're planning to hire people to grow your food and clean your farm?

[newb4now]

I just bought a couple hundred Moneros.
My stack is growing as I consider the current price a bargain.

I still find it amazing how low the prices are now compared to the peak last year despite all the progress since that time. 500 XMR for 1BTC seems almost too good to be true.

I wonder if most early BTC adopters are still in denial about the importance of fungibility. XMR seems like the best possible hedge for their BTC holdings. If only a small number of BTC early adopters put a few % of their wealth into Monero prices will climb extremely fast.

So far rpietila seems the most vocal of this group. I know a few BTC core developers have made some positive comments about Monero and cryptonote. What will it take for the cascade of interest from this group to begin?

[equipoise]

Good news! The excellent optimization work by Noodle Doodle (in some cases faster than the original in-memory version!) has been completed and a pull request was submitted moments ago: https://github.com/monero-project/bitmonero/pull/337

Additional testing will be needed and there are still a few loose ends but this is a major step toward the database being pushed out as a tagged build.

Great. That's the one I was waiting for to start my full nodes again. My blockchain is about a month old and the sync was much slower compared to the in-memory version.

[TrueCryptonaire]

The thing is Monero is owned by people who do not really care to sell unless they want to play a little pinball game like me.  

Personally I am not interested in selling any coins in 1 digit and even two digits I will think carefully if I start implementing SSS. When Monero is traded in hundreds, I might make a SSS plan from there. Knowing my standard of living and willingness for fancy life, I think I will not need that many coins to sell. I could easily live happily in a farm in nowhere growing my own food.

But dude, why the fuck do you need all the wealth of the world when you only have a farm and grow your own food?
You're planning to hire people to grow your food and clean your farm?

Investing and supporting local economy is important.
Keeping money in circulation helps the unemployed to get jobs and create to them some wealth also.

I plan to invest money into companies (startups) - and I wish I could do it directly with Moneros - not to convert it to fiat first.
Also buying a whole block of flats is one of my bigger dreams (which I probably will do even if Monero fails).

[newb4now]

The thing is Monero is owned by people who do not really care to sell unless they want to play a little pinball game like me.  

Personally I am not interested in selling any coins in 1 digit and even two digits I will think carefully if I start implementing SSS. When Monero is traded in hundreds, I might make a SSS plan from there. Knowing my standard of living and willingness for fancy life, I think I will not need that many coins to sell. I could easily live happily in a farm in nowhere growing my own food.

But dude, why the fuck do you need all the wealth of the world when you only have a farm and grow your own food?
You're planning to hire people to grow your food and clean your farm?

Investing and supporting local economy is important.
Keeping money in circulation helps the unemployed to get jobs and create to them some wealth also.

I plan to invest money into companies (startups) - and I wish I could do it directly with Moneros - not to convert it to fiat first.
Also buying a whole block of flats is one of my bigger dreams (which I probably will do even if Monero fails).

Help your tenants seek jobs that will pay in Monero and then they can pay you rent in XMR

[pönde]

Hey looks like moneroinvest.com is updated. 

Yet it seems to be dealig with monero only by its name. What about in near future? Will it soon have some functionality with monero?

[TrueCryptonaire]

Hey looks like moneroinvest.com is updated. 

Yet it seems to be dealig with monero only by its name. What about in near future? Will it soon have some functionality with monero?

http://moneroinvestment.com/

[Bassica]

Hey looks like moneroinvest.com is updated.  

Yet it seems to be dealig with monero only by its name. What about in near future? Will it soon have some functionality with monero?

http://moneroinvestment.com/

Interesting. Who owns this site?

Found one mistake:

"At the time of this writing in May 2015 Monero is at the very begging of its story."

Also I would cut up the story into more paragraphs, it's a bit of a long read (as in all in one) and not very attractive to the eye.

edit:
and another one, 'The central argument regarding Monere value add as an investment is that the value proposal presented above is plausible, '

[pönde]

Hey looks like moneroinvest.com is updated. 

Yet it seems to be dealig with monero only by its name. What about in near future? Will it soon have some functionality with monero?

http://moneroinvestment.com/

Thanks. That site was new for me.

But what about moneroinvest.com site. Will it be for example possible to buy metals by Monero in near future from there?

[nioc]

Interesting. Who owns this site?

I believe it is RP