Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1541. (Read 4670972 times)
August 23, 2014, 05:38:08 AM
So many FUDs around XMR but i will buy more.more FUDs = more people want to buy.
August 23, 2014, 05:22:24 AM
May sound repetitious, but I really feel that Monero is the Bitcoin of 2010.
I'll buy you a nice box of cigars if you're right.
Maybe some Siglo VI? To your taste?Siglo VI come in box of 25, so I think that is the best value I can hope for!
I'd say we need 1 XMR = $1,000, ok?
August 23, 2014, 01:47:04 AM
May sound repetitious, but I really feel that Monero is the Bitcoin of 2010.
I'll buy you a nice box of cigars if you're right.
Maybe some Siglo VI? To your taste? 
August 23, 2014, 01:13:45 AM
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.
Great explanation, I'll for sure continue to mine xmr for the future
Arguments like this should be on the webpage. August 23, 2014, 12:37:49 AM
May sound repetitious, but I really feel that Monero is the Bitcoin of 2010.
August 23, 2014, 12:06:05 AM
August 22, 2014, 11:24:33 PM
...
...
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.
August 22, 2014, 07:54:07 PM
Missive timeline overview
An overview of the missives so far.
...
Cheers,
Phil
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
August 22, 2014, 02:49:57 PM
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.
August 22, 2014, 02:43:24 PM
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.
August 22, 2014, 02:36:45 PM
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.
August 22, 2014, 01:26:34 PM
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?
August 22, 2014, 01:08:30 PM
Looking forward to Monero's future.
August 22, 2014, 01:07:37 PM
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.
Antonopoulos about people switch to anonymous currencies if NY regs stick.
August 22, 2014, 12:55:44 PM
August 22, 2014, 12:48:23 PM
Another proposal I've seen is Greg Maxwell's CoinSwap:
https://bitcointalksearch.org/topic/coinswap-transaction-graph-disjoint-trustless-trading-321228
https://bitcointalksearch.org/topic/coinswap-transaction-graph-disjoint-trustless-trading-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.
August 22, 2014, 12:32:09 PM
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
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
August 22, 2014, 11:05:39 AM
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.
August 22, 2014, 10:28:25 AM
could monero support multisig?
i think its a requirement for open bazaar
i think its a requirement for open bazaar
Monero will definitely support mutlisig.
August 22, 2014, 10:25:44 AM
could monero support multisig?
i think its a requirement for open bazaar
i think its a requirement for open bazaar
Jump to: