Monero is irrelevant but the shills and despeate are still here

[sofu]

While bagholders are shilling Monero the smart people are buying Vanilla 

[ArticMine]

For those interested in selling XMR short Poloniex does offer margin trading. https://www.poloniex.com/marginTrading#btc_xmr One can borrow XMR at very attractive rates as TrueCryptonaire has pointed out and sell the XMR for XBT.

Disclaimer: This is not investment advice. Short selling and margin trading can lead to losses far in excess of the initial investment and should only be attempted by experienced sophisticated investors after receiving appropriate professional advice.

[newb4now]

While bagholders are shilling Monero the smart people are buying Vanilla 

I prefer a coin with a cryptographically proven protocol and and a large experienced dev team instead of putting my trust in one unknown developer with nobody else to take over when/if he decides to leave

[iCEBREAKER]

bagholders are shilling Monero

I prefer a coin with a cryptographically proven protocol and and a large experienced dev team instead of putting my trust in one unknown developer with nobody else to take over when/if he decides to leave

Good points.  Let's elaborate on them:

Monero uses a cryptographically proven protocol and sports a large experienced active dev team.

Monero: 1034 commits (not including work on developer forks that isn't merged yet).

Monero core and community innovations over the past year:
1. Electrum seed wallets
2. Optimized (and documented) proof-of-work algorithm
3. Database implementation with negligible memory requirements
4. 32-bit support and fixes, including embedded platforms like RPi2
5. 5+ third party GUI wallets
6. Merchant framework
7. MyMonero web wallet with client-side javascript cryptography and private keys never sent to the server
8. GUI skeleton
9. Portable compact blockchain format.
10. Integrated addresses (no more payment IDs for routine transactions!)
11. Several MRL white papers analyzing and improving anonymity.
12. High level Python implementation of crypto for research
13. Watch only (view key) wallets.

In progress:
1. Smart mining
2. Non-retarded APIs
3. Improved difficulty retargeting
4. Improved privacy of transaction amounts
5. Multisig compatible with ring sigs
6. Rolling hard fork deployment scheme

[iCEBREAKER]

Poloniex surely set itself back by taking a chance on an unfinished coin (or instigating the hype via the "team")

Monero is finished in that it does what is says on the box: provide secure, private, and untraceable transfers of value.

It's "unfinished" only in the sense that Bitcoin and civilization are unfinished experiments in progress.

Are you shorting XMR?  No?  Why not?

People will lend you their XMR for practically nothing, so you have no reason not to, besides cowardice and lack of conviction.

[BagHolder010]

lol I went to google to search iCEBREAKER true identity since I heard he scammed others before in a company he worked at or owned and I found this https://bitcointalk.org/index.php?topic=755840.90;wap2

Looks like Monero fake forum activity is here since way back in 2014, and looks like Fluffy and Smooth didn't know what to do after copy pasting Byte lol because they still don't know how to create a GUI wallet for themselves or create anything meaningful for our beloved Crypto World.

[iCEBREAKER]

looks like Fluffy and Smooth didn't know what to do after copy pasting Byte lol because they still don't know how to create a GUI wallet

The Official GUI wallet exists in skeleton form.  Progress will increase after DB is done.

Fluffy and Smooth are only 2 of XMR's ~29 devs.  You must have missed NoodleDoodle's massive latest commit:

https://github.com/monero-project/bitmonero/pull/337

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 (Huh).
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(Huh) 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).

...and smooth's brief summary of XMR advancements over BCN:

Monero: 1034 commits (not including work on developer forks that isn't merged yet).

Monero core and community innovations over the past year:
1. Electrum seed wallets
2. Optimized (and documented) proof-of-work algorithm
3. Database implementation with negligible memory requirements
4. 32-bit support and fixes, including embedded platforms like RPi2
5. 5+ third party GUI wallets
6. Merchant framework
7. MyMonero web wallet with client-side javascript cryptography and private keys never sent to the server
8. GUI skeleton
9. Portable compact blockchain format.
10. Integrated addresses (no more payment IDs for routine transactions!)
11. Several MRL white papers analyzing and improving anonymity.
12. High level Python implementation of crypto for research
13. Watch only (view key) wallets.

In progress:
1. Smart mining
2. Non-retarded APIs
3. Improved difficulty retargeting
4. Improved privacy of transaction amounts
5. Multisig compatible with ring sigs
6. Rolling hard fork deployment scheme

[BagHolder010]

29 Devs and nothing still? o.O  I know one guy who did far beyond that of course you know who...someone who needs to go to jail LOL

29 cry*p*to into forums type of devs.

[newb4now]

looks like Fluffy and Smooth didn't know what to do after copy pasting Byte lol because they still don't know how to create a GUI wallet

The Official GUI wallet exists in skeleton form.  Progress will increase after DB is done.

Fluffy and Smooth are only 2 of XMR's ~29 devs.  You must have missed NoodleDoodle's massive latest commit:

https://github.com/monero-project/bitmonero/pull/337

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 (Huh).
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(Huh) 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).

...and smooth's brief summary of XMR advancements over BCN:

Monero: 1034 commits (not including work on developer forks that isn't merged yet).

Monero core and community innovations over the past year:
1. Electrum seed wallets
2. Optimized (and documented) proof-of-work algorithm
3. Database implementation with negligible memory requirements
4. 32-bit support and fixes, including embedded platforms like RPi2
5. 5+ third party GUI wallets
6. Merchant framework
7. MyMonero web wallet with client-side javascript cryptography and private keys never sent to the server
8. GUI skeleton
9. Portable compact blockchain format.
10. Integrated addresses (no more payment IDs for routine transactions!)
11. Several MRL white papers analyzing and improving anonymity.
12. High level Python implementation of crypto for research
13. Watch only (view key) wallets.

In progress:
1. Smart mining
2. Non-retarded APIs
3. Improved difficulty retargeting
4. Improved privacy of transaction amounts
5. Multisig compatible with ring sigs
6. Rolling hard fork deployment scheme

It does appear that some some botnets have mined Monero in the past (just like they have mined BTC and other coins). As block rewards decrease this will be less and less of an issue. Smart mining in particular will be very helpful

The amount of work done over the last year has been outstanding. The Development team is aware of Monero strengths and weaknesses.  Current limitations are being dealt with one by one and Monero continues to get stronger

[aleix]

Some Monero supporters are great at PR and fudding other coins, thats true.

But what markets support are real development, innovation, not spamming bitcointalk with lame threads or fudding campaings to other coins. Thats the reason Monero is (after the non-stop spamming and fudding campaigs) the n8 at coinmarketcap (under doge or bytecoin LOL).

(excuse my grammar and vocabulary mistakes, english is my third language)

[iCEBREAKER]

Some Monero supporters are great at PR and fudding other coins, thats true.

But what markets support are real development, innovation, not spamming bitcointalk with lame threads or fudding campaings to other coins.

XMR's PR efforts haven't really started.  We're waiting for the DB and GUI to be done first.

How are the advancements listed in smooth's summary and NoodleDoodle's latest commit (both of which are quoted in the post above yours) not real development and innovation?

[aleix]

I appreciate your true commitment to your coin and your community, but your non-stop fudding in Dash thread is despicable. You should understand that show some respect (even if you don't like something or you think something is wrong) is a basic issue for a civilizated alt-community to grow.

Is ok to disagree, is ok to say it loud, fudding campaigs like yours with Dash community is really bad for all the alt eco-system. Karma is a bitch, remember that.

I don't like Monero because Monero lack of tecnical innovations and because people like you and your kind of toxic behavior.  You should think about that.

(excuse my grammar and vocabulary mistakes, english is my third language)

[iCEBREAKER]

I appreciate your true commitment to your coin and your community, but your non-stop fudding in Dash thread is despicable. You should understand that show some respect (even if you don't like something or you think something is wrong) is a basic issue for a civilizated alt-community to grow.

Is ok to disagree, is ok to say it loud, fudding campaigs like yours with Dash community is really bad for all the alt eco-system. Karma is a bitch, remember that.

I don't like Monero because Monero lack of tecnical innovations and because people like you and your kind of toxic behavior.  You should think about that.

I appreciate your commitment to white knighting for Dash, regardless of my feelings about that coin.

I'd also appreciate it if you would answer (or at least not completely ignore) my question:

How are the advancements listed in smooth's summary and NoodleDoodle's latest commit (both of which are quoted in the post above yours) not real development and innovation?

We're not going to stop telling the truth about Dash's instamine, shoddy technology, and scammy HYIP-like aspects.

You are correct about karma; that's why we Monero Mustangs always say "If you see fraud and don't shout fraud, you are a fraud."

Sorry, but XMR and Dash are never going to make nice and be friends.  Because Dash is Digital Trash, and its community is a cargo cult.

"DARKCOIN": { HYIP - scam - InstaMined: [500k/1st hr, 2MM/1st day] - Broken Privacy - Broken Security - Broken Masternodes -  Trusted 3rd Paries - Stolen Name - No Fundamentals - BusFactor=1 }

// Duffield, Moncada, & Co should GO TO JAIL for fraud.

[Johnny Mnemonic]

Thanks for starting another Monero thread! We don't need to market the coin when the haters do it for us 

[hodlmybtc]

A couple days ago I wondered where all the trolls went, maybe because XMR bottomed out?

[solid12345]

looks like Fluffy and Smooth didn't know what to do after copy pasting Byte lol because they still don't know how to create a GUI wallet

The Official GUI wallet exists in skeleton form.  Progress will increase after DB is done.

Sorry but to me it is absolutely embarrassing that Monero devs can't roll out a GUI wallet. It's bad enough most crypto wallets look like a visual basic app from the Windows 95 days, but one of the "leading" coins can't even roll that out in over a years time? I would think it would be a 2-day job at most based on what many other shitcoin developers manage to churn out every week. If they think it is some kind of "statement" to be concentrating on the backend first it's a really lame one.

[iCEBREAKER]

looks like Fluffy and Smooth didn't know what to do after copy pasting Byte lol because they still don't know how to create a GUI wallet

The Official GUI wallet exists in skeleton form.  Progress will increase after DB is done.

Sorry but to me it is absolutely embarrassing that Monero devs can't roll out a GUI wallet. It's bad enough most crypto wallets look like a visual basic app from the Windows 95 days, but one of the "leading" coins can't even roll that out in over a years time? I would think it would be a 2-day job at most based on what many other shitcoin developers manage to churn out every week. If they think it is some kind of "statement" to be concentrating on the backend first it's a really lame one.

Monero devs can and are rolling out a GUI wallet.

But the refactoring and DB needed to be done first.  Do you understand what the phrase "software dependencies" means?

https://moneroeconomy.com/faq/en/why-monero-not-user-friendly-most-other-cryptocurrencies-why-there-no-official-gui-wallet

[Johnny Mnemonic]

looks like Fluffy and Smooth didn't know what to do after copy pasting Byte lol because they still don't know how to create a GUI wallet

The Official GUI wallet exists in skeleton form.  Progress will increase after DB is done.

Sorry but to me it is absolutely embarrassing that Monero devs can't roll out a GUI wallet. It's bad enough most crypto wallets look like a visual basic app from the Windows 95 days, but one of the "leading" coins can't even roll that out in over a years time? I would think it would be a 2-day job at most based on what many other shitcoin developers manage to churn out every week. If they think it is some kind of "statement" to be concentrating on the backend first it's a really lame one.

I agree that a simple GUI should be in place, but it's more for all-in-one accessibility than anything else. We know perfectly well more users will go to third party SPV/web wallets that suit their specific needs than will depend on the core GUI. What percentage of Bitcoin users do you think still use the QT GUI?

Nevertheless, a core GUI should be there, but it's hardly "embarrassing" that one isn't.

[generalizethis]

looks like Fluffy and Smooth didn't know what to do after copy pasting Byte lol because they still don't know how to create a GUI wallet

The Official GUI wallet exists in skeleton form.  Progress will increase after DB is done.

Sorry but to me it is absolutely embarrassing that Monero devs can't roll out a GUI wallet. It's bad enough most crypto wallets look like a visual basic app from the Windows 95 days, but one of the "leading" coins can't even roll that out in over a years time? I would think it would be a 2-day job at most based on what many other shitcoin developers manage to churn out every week. If they think it is some kind of "statement" to be concentrating on the backend first it's a really lame one.

Well at least you know if it were a scam, the Devs would have rolled out some simple GUI to gather the most sheep in the shortest amount of time. Instead they are creating an enterprise level (scalable) GUI, so sorry if it takes more time to create than a Fast and Furious sequel.  

Of course all this already known to anyone willing to do their homework: https://forum.getmonero.org/1/news-announcements-and-editorials/190/editorial-why-is-the-official-gui-wallet-not-released-yet

[HCLivess]

I am getting an increasing feeling that there is only one person with tor involved in XMR, which would make it the biggest scam in the history of mankind