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

[smooth]

What metrics do you use to estimate BTC growth?

Price for one thing, given the model that price is highly correlated with two different metrics of growth: https://bitcointalk.org/index.php?topic=366214.msg5919365#msg5919365

Also, you can see the number of tranasctions here (which was my original source for comparing with XMR). Little to no growth in 2014 at all.  http://blockchain.info/charts/n-transactions

Perhaps BTC will experience another surge of growth at some point, and that wouldn't surprise me at all. But the current (temporary?) plateau is an opportunity for other coins to avoid being left too far behind.

[1714003817]

1714003817

[g0re79]

Its nice to find at least one thread which is not polluted by trolls, complainers and FUDers. Everything seems to go well with my favourite coin

[Jungian]

Is there a Monero forum that's being used at the moment? I don't feel like reading though the same debates again and again

[smooth]

Is there a Monero forum that's being used at the moment? I don't feel like reading though the same debates again and again

There is no official Monero-specific forum. Further, we really enjoy being out with the broader community (bitcointalk, reddit, twitter, IRC, etc.).

When the new web presence is ready there will be more ways to communicate that are Monero-specific but we will always want to remain engaged with the "outside world" and take care not to retreat to a comfortable echo chamber where only yes men need apply.

[superplus]

could monero support multisig?
i think its a requirement for open bazaar

[smooth]

could monero support multisig?
i think its a requirement for open bazaar

Monero will definitely support mutlisig.

[dawie]

Thanks, any further comments from core team members would be great.  I don't see why every Bitcoin user must be forced to use a privacy protocol for every transaction to provide a sufficient anonymity set.  Even a small percentage of Bitcoin users may be a larger absolute number than the entire user base of a privacy coin.  Also, isn't the primary issue the absolute number of people one is mixing with in a transaction (e.g., 50), rather than the total number of users of a privacy protocol or privacy coin?  It seems the total user base only needs to be above some reasonable absolute number to provide sufficient privacy.  The number of total users of a coin seems most important because of network effects that can determine whether a coin will survive against competitors, rather than its effect on privacy.

The anonymity set is more reduced than that. Let me give you an example: say you want to transfer 123.456 Bitcoin. No matter what method you use, if someone can observe you sent 123.456 Bitcoin from your address and 123.456 Bitcoin appeared in another address within an hour or two they can make certain conclusions. These inferences can be cryptographically proven, and this is called "reducing the anonymity set". Eventually the anonymity set can be reduced to the point where you can ascertain undoubtedly prove a certain address sent a transaction regardless of the intermingling and intermixing that occurred.

Now in order to make this really difficult, you have to start with a VERY large anonymity set. In other words, there need to be to very many people potentially involved in a transaction that any reduction is practically meaningless. Mixing typically requires point-in-time availability of people or nodes, and the higher the mix the longer it takes (since you have to go through "rounds" of mixing). Darkcoin gets around this, I believe, by "premixing" your coins. The downside to their approach (and to most of the other approaches I've seen) is that you have massive address churn in your wallet, and any practical use will require you to back your wallet.dat up constantly. Secure and anonymous cold storage is thus observable to anyone with a blockchain explorer (when it really shouldn't be).

One of the solutions Monero and other mixing systems employ to blind amount correlation is it splits inputs (and outputs) by powers of 10, so the earlier example would mean inputs of 100, 20, 3, 0.4, 0.05, and 0.006. Now because of the way Monero works (ring signatures!) you specify you want to mix with, say, 50 other people. So it takes that first input (100) and goes and finds all the unspent transaction outputs (ie. those not spent with a mixin of 0) that have ever occurred in the past and have a value of 100. As you can imagine, this is a pretty huge set, and is growing every day. It can then pick 50 of those at random, add your signature to the ring, and voila. Now it does the same for the other 5 inputs. This means that the total anonymity set here is massive - 51 * 6 = 306 people that could have possibly been involved in the transaction. Most importantly, because all of these are stealthed transactions (Monero uses stealth addresses permanently) some of those outputs you mix with could even have been created by you previously! Thus the potential anonymity set grows and grows even if the userbase stays stagnant - a feature that is not shared by any of the Bitcoin-derived anonymity solutions.

Finally, because Monero uses stealth addresses, you never need to backup anything more than a 300 byte password-encrypted keys file (or just write down the 24 word mnemonic seed you get when you first create a wallet). That 300 byte file will never change no matter how many transactions you do. You back it up once and you are safe from data loss forever.

Well said +1

Agreed.  Thx is an xlt ELI5 explanation of the power of Monero's ring sigs in obfuscating transaction traceability to render spying agencies impotent in their Orwellian endeavors. 

[Globb0]

Whirlwind missives (Updated 09/12)!


Jun 2nd 2014

1.   New Logo + branding pack
2.   Repository redesign
3.   Begin website enhancements
4.   live discussions join us on Freenode: #monero for general chat, #monero-dev
5.   MRO changes to XMR to satisfy ISO 4217

Dev diary

1.   Added missing RPC methods
2.   0.8.8 changes to prevent dust attack on block reward
3.   Begun work on documenting the code and providing architecture overviews
4.   Understanding and examining the cryptonote protocols
5.   POW hashing optimisation to improve syncing times and pool verify times
6.   Lucasjones miner optimisation work


Jun 10th

1.   New feature announced deterministic wallets based on mnemonic seed
2.   XMR listed for voting on Mintpal
3.   RPC based Qt GUI wallet

Dev diary

1.   Further RPC work on simplewallet
2.   Added new seed notes
3.   Further code review and implement Doxygen for commenting and code understanding


Jun 18th

1.   Hit number one on mintpal voting list
2.   Begin peer review cryptonote whitepaper
3.   Initial work done on transaction splitting
4.   GUI wallet a lot of work to be done yet and Monero core issues to be resolved first

Dev diary

1.   TX pool handling fix to address high number of orphans
2.   Auto split is now ready for test


June 27th

1.   XMR added to 2 exchanges BTER and Mintpal
2.   White paper review continues http://monero.cc/downloads/whitepaper_annotated.pdf
3.   Bug fix restoring a deterministic wallet and old transactions
4.   Stabilising Monero, pools, merchants and exchanges
5.   Auto splitting ready for release

Dev diary

1.   Slow_hash huge changes to add AES-NI
2.   Major daemon overhaul in progress; windows support to follow
3.   Simple wallet split to Simplewallet (CLI) and RPCwallet (standalone RPC daemon)


July 6th

1.   CryptoNote peer review continues
2.   Auto splitting is now in the main code base

Dev diary

1.   RPC wallet ready for test


July 13th

1.   GUI’s received and bounties paid. Won’t be directly integrated yet
2.   CryptoNote white paper review is coming to close
3.   Begun work to re-implement the mnemonic word list in other languages

Dev diary

1.   Core major work begin to Implement an embedded database
2.   I2P focus moves from libi2pcpp to i2pd. Focus on persistent connections


July 20th

1.   Begun reviewing the implementation of CryptoNote following the white paper review
2.   Embedded database work in progress the hope is to reduce ram requirements
3.   Information security specialist joins the team
4.   German word list complete now moving onto Portuguese

Dev diary

1.   Abstraction of the blockchain storage functions completing (enabler for performance testing)
2.   Daemonising Monero work is largely completed
3.   RPC wallet can now run multiple instances (where machines need to run multiple wallets)
4.   DNS seed nodes work begun that will later replace hardcoded seed nodes
5.   Exchange’s poll get_payments fix for multiple payment IDs is testing


July 23rd

1.   Monero trading pairs added to Poloniex
2.   BSD 3-clause license changes
3.   README build instructions improved
4.   Developer training for Git usage

Dev diary

1.   RPC enhancements a new Get_info
2.   get_bulk_payments developed and ready


August 3rd

1.   Launched fireside chats
2.   Begun tracking downloads 41,425 in the first 3 recorded weeks from 15/06
3.   XMR pairs rise to 5830 XMR of volume after first 12 days
4.   Monero added to coinSource Trust Index with a score of  6 out of 7 stars
5.   Build process streamlined

Dev diary

1.   Windows build script to simplify windows builds
2.   QOS developed and ready, peripherals to be completed
3.   Embedded database is proving complex, work continues
4.   Issues resolved from logs, blockheight parameter and query_key
5.   DNS seeder code available for review


August 10th

1.   First look at the gui in the first fireside chat was positively received
2.   Monero price ticker released
3.   Test environment secured and ready for continuous integration process

Dev diary

1.   Abstracted BlockchainDB functions coming together
2.   CMakelist overhauled
3.   Unit test review/creation has begun
4.   Planning migration to new servers for blockchain and client download


August 16th

1.   GUI test release available
2.   Monero broke 600 subscribers to our sub-reddit
3.   Open source Monero stratum proxy released
4.   Finalising QoS bandwith control

Dev diary

1.   Mingw64 / msys2 largely complete
2.   Wallet code under refactoring
3.   Abstraction and refactoring Blockchain functions ready for some performance testing
4.   QoS ready awaiting testing and then release


September 15th

1.The Monero Research Lab is an open collective academic group continuing to make papers towards the analysis and improvement of the underlying core
2. Second #Monero-Dev Fireside (Fri September 19th, 2014, at 10:00 EST)
3. Merchandise available http://www.zazzle.com/monerogear* coin team gets 15% commission
4. URS released, a Monero project written in Go that allows you to sign messages using ring signatures as part of a group
5. New tagged release, 0.8.8.4, now available for download
6. GUI work delayed due to addressing some core issues following recent events. Progress continuing
7. Monero added to Coin Swap https://coin-swap.net/market/XMR/BTC

Dev diary

1. Development branch on hold, will be brought back into sync following emergency measures implemented
2. FreeBSD Compatability: Monero now works on FreeBSD out the box
3. New Makefile target, release-static, that builds statically linked binaries for redistribution.
4. Wallet: per-kb fees are nearly complete, and will be deployed to testnet within the next week or so
5. Blockchain: Work delayed by  blockchain attacks. Getting back on track with DB work
6. Core: Devs note, all non-critical "errors" and warnings have been moved to log-level 1


October 6th

1. New official Monero forum. Come find us! @ https://forum.monero.cc
2. Working hard in the background on the codebase
3. Mnemonics system overhauled and added new word lists in Japanese, Portuguese, and Spanish
4. MoneroPulse added; a loosely distributed checkpoint alert system
5. Backup distribution system in place for recovery
6. Research Lab released Research Bulletin, MRL-0003 – around ring signatures
7. Monero now at number 2 on Cryptsy voting list

Dev Diary

1. File check pointing added;  checkpoints are always enforced regular checking
2. DNS check pointing added
3. Working hard on improving the build system so builds are easier and less problematic
4. PoW algorithm annotated in the code and documented by dga


October 13th

1. Back-porting features and fixes added to the current codebase.
2. The GUI is progressing We hope to update the preview binaries in the next week or two
3. per-kb fees in testing. we expect positive testing results
5. Further tweaks to mnemonic system

Dev Diary

1. Further work on build environment ultimately to reduce build issues further down the line
2. Core: documentation continues, with Doxygen comments
3. DNS check pointing and configuration in test
4. mnemonic lists now support a variable trim length


October 20th

1. Focussing on some of the core issues that have been lagging
2. Blockchain database implementation. Lightning Memory-Mapped Database, LMDB ready for limited testing by next week.
3. Additional implementations will be built to compare performance
4. Implementing DNSSEC trust anchors with the assistance of NLnet Labs. it prepares us for more widespread, secure use of the OpenAlias standard
5. Reworking build environment to conform to Kitware recommendations, especially due to poorly implemented CMake in original reference code

Dev Diary

1. Per-kb fee testing is going well on testnet
2. Downloadable RAW blockchain for import your daemon will fully verify the downloaded blockchain
3. Unit tests have been fixed, change is expected to be merged in the next week.
4. Core tests are currently being worked on to bring them up to a 100% working state for regression testing


October 27th

1. Initial database implementation very nearly ready for broader testing
2. Per-kb fees functionality  added to simplewallet, hope to deploy that for general testing within the week
3. Build system is starting to come together in its final form

Dev Diary

1. CMake is looking a lot cleaner and easier to grok. It also fixes cross-compile
2. Offloaded MoneroPulse checkpoint checks to a separate thread to reduce locking and looking to do this elsewhere in the core now
3. Account: multilang wordlists are now inherent to the wallet/account. we have opted to use RapidJSON instead of eppe's JSON


November 2nd

1. LMDB's is syncing! if you would like to give it a spin you can
2. Per-kb fees are ready to go
3. New CMake there are a few final nigglies on Windows and FreeBSD

Dev diary

1. LMDB implementation is complete, and is undergoing testing for drastic rollbacks and edge cases
2. Switchover to the new fee structure is hoped to happen next week


November 17th

1. On-going Windows static build issues are preventing us from tagging and releasing Monero 0.8.8.5
2. Note: the only trustworthy, official binaries are those release by the core team
3. Monero Research Lab had a meet-up in Salt Lake City for some debate sessions
4. Bolckchain DB testing all looking good

Dev Diary

1. CMake lingering issues exist with static mingw-w64 builds
2. Several bug fixes to the multi-language mnemonic system


November 24th

1. My Monero announced, the first Monero hosted account service. A web wallet for Monero go to https://mymonero.com
2. Significant progress has been made to fixing the last few Windows build issues

Dev Diary

1. Msys2 now successfully compiles. final testing of new builds will happen this week
2. Expect a mass merge of PRs previously waiting this week. Now CMake changes will have to comply with the new, cleaner CMake.


December 8th

1. Monero 0.8.8.6 released - Lots of the recent fixes and changes are bundled in. Remeber to only download from a trusted source
2. Smart mining introduced - Should help all users support the network. Work needed yet on detail and to support more platforms

External (new added section for external projects and services under development)

1. MyMonero - currently fixing some bugs around displaying on different devices and data manipulation
2. A new implementation project for the i2p protocol in C++. Monero will use this later for its connection to the i2p network

Dev Diary

1. Build: tests are now disabled when building the build-release, build-debug, or release-static targets.
2. Account: lots of fixes to multi-lang mnemonics, although UTF-8 on Windows still seems to be a bit shaky.


Another whirlwind session draws to a close on this cold winters day.  


Globb0

Last Updated: 09/12

[smfuser]

Another proposal I've seen is Greg Maxwell's CoinSwap:

https://bitcointalk.org/index.php?topic=321228

Looking at it real quick .. it also seems like it relies on interested parties and is very slow .. involving multiple tx's that need to confirm before another is sent out .. so you'd have to wait for a long time for these types of tx's to complete (Monero being under ten minutes to completion .. at low speed; coinswap looks like it could take more than double that at top speeds). I'll read more on it, from what I've seen things gmaxwell comes up with are pretty good ideas.

Anoncoin is doing some fantastic things, I believe they're in the middle of trying to work a Zerocoin protocol into their coin (which is a bitcoin or litecoin fork .. I don't remember) .. along with implementing a cpp version of I2P, but are you asking about anon options in bitcoin itself or bitcoin protocol? I have my own grievances with ZC .. but as it doesn't exist yet I feel they're unjustified .. so I'm eagerly awaiting the release.

Thanks, although I'm interested generally in privacy technologies, I was asking specifically about the best known privacy protocols (even if not yet implemented) that work with Bitcoin as is, without requiring changes to the Bitcoin protocol (which I think will be difficult and slow), because such methods might be adopted rapidly by a substantial percentage of existing Bitcoin users with the right implementation.  Proponents of CoinShuffle have suggested that it be incorporated into user-friendly wallets that would allow typical users to mix coins automatically with virtually no effort.  I mentioned CoinSwap as another example that doesn't require Bitcoin protocol changes (not to suggest it was the best choice).

I think Monero/CryptoNote certainly offers advantages over a Bitcoin only solution, and the person I mentioned recognized that Monero was technically superior, but he believed that CoinShuffle is good enough (unlike CoinJoin), in light of Bitcoin's incumbent position, to greatly affect his view of the competitive prospects for any privacy altcoin.  I'd like to understand what is the best one can do with Bitcoin alone, whether that is CoinShuffle or something else, and how that will compare to better alternatives like Monero.

[dEBRUYNE]

Missive timeline overview

An overview of the missives so far.


Jun 2nd 2014

1.   New Logo + branding pack
2.   Repository redesign
3.   Begin website enhancements
4.   live discussions join us on Freenode: #monero for general chat, #monero-dev
5.   MRO changes to XMR to satisfy ISO 4217

Dev diary

1.   Added missing RPC methods
2.   0.8.8 changes to prevent dust attack on block reward
3.   Begun work on documenting the code and providing architecture overviews
4.   Understanding and examining the cryptonote protocols
5.   POW hashing optimisation to improve syncing times and pool verify times
6.   Lucasjones miner optimisation work


Jun 10th

1.   New feature announced deterministic wallets based on mnemonic seed
2.   XMR listed for voting on Mintpal
3.   RPC based Qt GUI wallet

Dev diary

1.   Further RPC work on simplewallet
2.   Added new seed notes
3.   Further code review and implement Doxygen for commenting and code understanding


Jun 18th

1.   Hit number one on mintpal voting list
2.   Begin peer review cryptonote whitepaper
3.   Initial work done on transaction splitting
4.   GUI wallet a lot of work to be done yet and Monero core issues to be resolved first

Dev diary

1.   TX pool handling fix to address high number of orphans
2.   Auto split is now ready for test


June 27th

1.   XMR added to 2 exchanges BTER and Mintpal
2.   White paper review continues http://monero.cc/downloads/whitepaper_annotated.pdf
3.   Bug fix restoring a deterministic wallet and old transactions
4.   Stabilising Monero, pools, merchants and exchanges
5.   Auto splitting ready for release

Dev diary

1.   Slow_hash huge changes to add AES-NI
2.   Major daemon overhaul in progress; windows support to follow
3.   Simple wallet split to Simplewallet (CLI) and RPCwallet (standalone RPC daemon)


July 6th

1.   CryptoNote peer review continues
2.   Auto splitting is now in the main code base

Dev diary

1.   RPC wallet ready for test


July 13th

1.   GUI’s received and bounties paid. Won’t be directly integrated yet
2.   CryptoNote white paper review is coming to close
3.   Begun work to re-implement the mnemonic word list in other languages

Dev diary

1.   Core major work begin to Implement an embedded database
2.   I2P focus moves from libi2pcpp to i2pd. Focus on persistent connections


July 20th

1.   Begun reviewing the implementation of CryptoNote following the white paper review
2.   Embedded database work in progress the hope is to reduce ram requirements
3.   Information security specialist joins the team
4.   German word list complete now moving onto Portuguese

Dev diary

1.   Abstraction of the blockchain storage functions completing (enabler for performance testing)
2.   Daemonising Monero work is largely completed
3.   RPC wallet can now run multiple instances (where machines need to run multiple wallets)
4.   DNS seed nodes work begun that will later replace hardcoded seed nodes
5.   Exchange’s poll get_payments fix for multiple payment IDs is testing


July 23rd

1.   Monero trading pairs added to Poloniex
2.   BSD 3-clause license changes
3.   README build instructions improved
4.   Developer training for Git usage

Dev diary

1.   RPC enhancements a new Get_info
2.   get_bulk_payments developed and ready


August 3rd

1.   Launched fireside chats
2.   Begun tracking downloads 41,425 in the first 3 recorded weeks from 15/06
3.   XMR pairs rise to 5830 XMR of volume after first 12 days
4.   Monero added to coinSource Trust Index with a score of  6 out of 7 stars
5.   Build process streamlined

Dev diary

1.   Windows build script to simplify windows builds
2.   QOS developed and ready, peripherals to be completed
3.   Embedded database is proving complex, work continues
4.   Issues resolved from logs, blockheight parameter and query_key
5.   DNS seeder code available for review


August 10th

1.   First look at the gui in the first fireside chat was positively received
2.   Monero price ticker released
3.   Test environment secured and ready for continuous integration process

Dev diary

1.   Abstracted BlockchainDB functions coming together
2.   CMakelist overhauled
3.   Unit test review/creation has begun
4.   Planning migration to new servers for blockchain and client download


August 16th

1.   GUI test release available
2.   Monero broke 600 subscribers to our sub-reddit
3.   Open source Monero stratum proxy released
4.   Finalising QoS bandwith control

Dev diary

1.   Mingw64 / msys2 largely complete
2.   Wallet code under refactoring
3.   Abstraction and refactoring Blockchain functions ready for some performance testing
4.   QoS ready awaiting testing and then release
 
A good looking velocity I think. For the people looking for a roadmap you can see a few things that are in test or ready for further testing and integration so there is some visibility there for the near term items.


Cheers,
Phil

Nice overview! You can also buy monero on hitbtc.com by the way. We should get monero added to btc38, one of the biggest chinese exchanges which trades altcoins.

[dEBRUYNE]

Posted in another topic, also relates to monero:

https://www.youtube.com/watch?v=ggB0Wh_g33M&feature=youtu.be&t=24m30s

Antonopoulos about people switch to anonymous currencies if NY regs stick.

[GBattaglia]

Looking forward to Monero's future. 

[smfuser]

Thanks, any further comments from core team members would be great.  I don't see why every Bitcoin user must be forced to use a privacy protocol for every transaction to provide a sufficient anonymity set.  Even a small percentage of Bitcoin users may be a larger absolute number than the entire user base of a privacy coin.  Also, isn't the primary issue the absolute number of people one is mixing with in a transaction (e.g., 50), rather than the total number of users of a privacy protocol or privacy coin?  It seems the total user base only needs to be above some reasonable absolute number to provide sufficient privacy.  The number of total users of a coin seems most important because of network effects that can determine whether a coin will survive against competitors, rather than its effect on privacy.

The anonymity set is more reduced than that. Let me give you an example: say you want to transfer 123.456 Bitcoin. No matter what method you use, if someone can observe you sent 123.456 Bitcoin from your address and 123.456 Bitcoin appeared in another address within an hour or two they can make certain conclusions. These inferences can be cryptographically proven, and this is called "reducing the anonymity set". Eventually the anonymity set can be reduced to the point where you can ascertain undoubtedly prove a certain address sent a transaction regardless of the intermingling and intermixing that occurred.

Now in order to make this really difficult, you have to start with a VERY large anonymity set. In other words, there need to be to very many people potentially involved in a transaction that any reduction is practically meaningless. Mixing typically requires point-in-time availability of people or nodes, and the higher the mix the longer it takes (since you have to go through "rounds" of mixing). Darkcoin gets around this, I believe, by "premixing" your coins. The downside to their approach (and to most of the other approaches I've seen) is that you have massive address churn in your wallet, and any practical use will require you to back your wallet.dat up constantly. Secure and anonymous cold storage is thus observable to anyone with a blockchain explorer (when it really shouldn't be).

One of the solutions Monero and other mixing systems employ to blind amount correlation is it splits inputs (and outputs) by powers of 10, so the earlier example would mean inputs of 100, 20, 3, 0.4, 0.05, and 0.006. Now because of the way Monero works (ring signatures!) you specify you want to mix with, say, 50 other people. So it takes that first input (100) and goes and finds all the unspent transaction outputs (ie. those not spent with a mixin of 0) that have ever occurred in the past and have a value of 100. As you can imagine, this is a pretty huge set, and is growing every day. It can then pick 50 of those at random, add your signature to the ring, and voila. Now it does the same for the other 5 inputs. This means that the total anonymity set here is massive - 51 * 6 = 306 people that could have possibly been involved in the transaction. Most importantly, because all of these are stealthed transactions (Monero uses stealth addresses permanently) some of those outputs you mix with could even have been created by you previously! Thus the potential anonymity set grows and grows even if the userbase stays stagnant - a feature that is not shared by any of the Bitcoin-derived anonymity solutions.

Finally, because Monero uses stealth addresses, you never need to backup anything more than a 300 byte password-encrypted keys file (or just write down the 24 word mnemonic seed you get when you first create a wallet). That 300 byte file will never change no matter how many transactions you do. You back it up once and you are safe from data loss forever.

Thank you for the detailed reply.  I think I was already aware of the issues you described.  If I understand correctly, sending exact amounts (from one source address to one ultimate destination address) can result in inadequate privacy even if every Bitcoin user mixes, so the real problem is that flawed privacy protocol, not the lack of universal usage.  With the right method, it seems one should be able to enjoy good privacy even if only a small percentage of Bitcoin users (e.g., 10% of current users) were participating.  Of course, the Bitcoin user base may grow by orders of magnitude, so even much smaller percentages in the future could represent a larger anonymity set.

The ability to mix with past outputs is certainly an advantage of Monero, but I assume that a Bitcoin-based privacy offering could provide automatic transaction splitting, stealth addresses, automated periodic mixing, and deterministic wallets to eliminate the need for continual backups.

Have you looked at CoinShuffle and CoinSwap and do you have an opinion about what are the best known options for privacy that can work with the current Bitcoin protocol?

[smfuser]

Thanks, any further comments from core team members would be great.  I don't see why every Bitcoin user must be forced to use a privacy protocol for every transaction to provide a sufficient anonymity set.  Even a small percentage of Bitcoin users may be a larger absolute number than the entire user base of a privacy coin.

Surprisingly, this might not be true. Monero already has approximately 3% as many transactions as BTC and this number is likely to grow as improvements to XMR (especially GUI) are rolled out and more avenues for usage appear. So far aside from speculation (exchanges) we have exactly one medical practice and one gambling site.

Bitcoin's growth has stagnated a lot, which is allowing other coins to begin to catch up.

Thanks for your input.  Sorry if I wasn't clear, but I would have considered 3% (or even 10% or 20%) to be small compared to the 100% that was originally suggested as being necessary, and I was comparing the current usage of Bitcoin to the current usage of any other privacy coin.  I realize those figures may change substantially, which may change my risk assessment.  I was aware of the 3% figure, which you've mentioned previously, and it's impressive given Monero's youth, but still quite small.

I'm interested in the long-term future of Monero, and as a Monero holder I'm trying to assess risks, such as a future improved privacy offering for Bitcoin users.  If you have any comments about CoinShuffle, CoinSwap, or what you consider to be the best privacy proposals that use the current Bitcoin protocol, I'd love to hear them.

[smooth]

I'm interested in the long-term future of Monero, and as a Monero holder I'm trying to assess risks, such as a future improved privacy offering for Bitcoin users.  If you have any comments about CoinShuffle, CoinSwap, or what you consider to be the best privacy proposals that use the current Bitcoin protocol, I'd love to hear them.

My impression (as someone who has been around the Bitcoin scene since 2011) is that Bitcoin development is in fact quite stagnant, and increasingly so.

People have been proposing all sorts of things for Bitcoin, but rarely does anything new actually become commonly used. For example stealth addresses were proposed, I believe, in 2011. Only now are Bitcoin implementations starting to become available. They won't be widely used for some time, if ever.

One could do worse than betting against any new technologies becoming widely established and used with Bitcoin. In fact even a 3% target might be optimistic in general.

I would have said the same thing before getting involved with Monero, so take that for what you think it is worth, despite the obvious (present) bias.

[dawie]

I'm interested in the long-term future of Monero, and as a Monero holder I'm trying to assess risks, such as a future improved privacy offering for Bitcoin users.  If you have any comments about CoinShuffle, CoinSwap, or what you consider to be the best privacy proposals that use the current Bitcoin protocol, I'd love to hear them.

I would recommend you read this discussion about the anonymity alternatives from the perspective of cryptographers:
https://bitcoin.stackexchange.com/questions/29471/is-there-any-true-anonymous-cryptocurrencies

TL;DR: Ring signatures (i.e. Cryptonote) have a clear advantage and hence Monero is a great hedge against Bitcoin proposed anonymization efforts.

[Quanttek]

Missive timeline overview

An overview of the missives so far.

...


Cheers,
Phil

Beautiful! Thank you for doing this. It would be nice, if you could continue updating the list. Maybe every month make a new post with all the older posts included + all new missives, though it is just an idea

[xulescu]

...

...

CryptoNote vs Bitcoin-based solutions

An abstract approach

You can put all outputs in any blockchain-based coin in a DAG where outputs are objects and transactions are arrows. If the transaction involves multiple inputs and multiple outputs, then add an arrow from any input to any output (call this a clique). In any such clique you mix the inputs, which is a good thing. The problem with Bitcoin is that the size of the cliques is severely limited: normally, you only have multiple inputs with a common source and most transactions have only two outputs, one of which is a change address. This allows you to aggregate addresses under the same ownership and this ripples both backwards and forwards (the latter is more troubling since it is the antipode of forward secrecy).

CoinJoin-like solutions attempt both to directly increase the size of the cliques and to address the first part of the problem (common inputs share ownership). Stealth addresses attempt to solve the second problem (everyone sees where the money goes). You can see how instead of saying that CryptoNote is "simply" better than those, it is more accurate to say that those solutions are actually approximate partial fragments of CryptoNote. In other words, any hypothetical Bitcoin privacy solution would necessarily have both a CoinJoin-like AND a stealth address-like mechanism to be viable. Due to technical limitations in the Bitcoin protocol (that would require a hard, hard fork to implement), all CoinJoin-like solutions are complicated Rube Goldberg machines because you can only mix with inputs in your same clique and that is and can never be enough (*) and all stealth address-like mechanisms require extra back-and-forth to perform the DH exchange. CryptoNote does those two things naturally; indeed, one could argue that the main ways in which CryptoNote is not Bitcoin are precisely changes specially-made for these two purposes (plus different PoW and other "variables").

Now you ask, "OK I understand CryptoNote is the shizzle and Bitcoin-based solutions are the groupies, but I think Bitcoin's network effects, prime mover advantage and a decent privacy implementation would make alts an academic exercise." To which the answer only really depends on whether you think any alt can overtake Bitcoin at all and has not much to do with privacy. People have very strong beliefs about this question generally. My answer (and that of many if not most here) is that it is entirely possible, but not necessarily probable, since they cater different markets (light vs dark liquidity) and thus we move to a different question.

If you really care about privacy then you understand that approximate privacy is no privacy. Monero's attack surface is flat compared to a hypothetical Bitcoin solution's fractal closure. Whoever sees this will use Monero instead of the Bitcoin-solution for privacy even if the userbase for Monero is much smaller. (*) This is because CryptoNote allows mixes with the past outputs. This means you do not need other participants (which is a seriously heavy rock that all CoinJoin approaches have to carry arround). On the longer term, this means you can mix even if there are only two people left using the network; even if the last transaction was last year; and so on, even if everyone stopped using Monero after this block you could still mix ten years later.

Finally, give me a function that decides in poly-time the question "Is output X the true source of the money that reached output Y?" in a CryptoNote DAG where all ring signatures have size at least 24 and I can probably decide 3-SAT in poly-time. The constant in the reduction could go to 12 since I'm pretty sloppy with map/fold. This means deterministic linkability is NP-hard and this is a very powerful result -- if the protocol is not misused, plausible deniability will never be compromised. If anyone's interested in pursuing this thread, the next question I have in mind is "What happens if we relax 'decides' to 'PAC-decides'?" A discussion of taint could come in handy here.

[aminorex]

...

I love it when you talk dirty.

[rpietila]

May sound repetitious, but I really feel that Monero is the Bitcoin of 2010.