You know as well as I do that this isn't really about a self-moderated thread, and I'm not going to start off with having the first thing on the thread done by deleting all the posts inside of it. I'm just not. Make of that what you will. If it (edit: aimless conversation - not you personally) gets to the point where it's driving people insane, that's a different story.

I posted on your self-moderated thread as 4 different profiles and not even once did I care if I was censored. Your keen insights won't be censored just because you're worried someone won't know you made an awesome technical point. If you can bear it, please stay around. If not and everyone else follows suit, then this will be a lonely thread where I will toss any information I can find into it about anything related to the topics.

It's a self-moderated thread, therefore by extension the discussion has simply been about self-moderation itself. I'd consider that a part of the implicit nature of the thread.

Can we move on from that or will this be an endless tantrum? You literally just said to aminorex "your IQ is higher than that" ... well ...!

Back on topic.

Current development discussion topics:

I2P C++ Integration
Code descriptions/labeling/annotations
GUI wallet: https://github.com/Neozaru/bitmonero-qt
Website progress
Pool updates

- what kinda of commits are people seeing on github?

That's a pretty good topic. What kind of database is being worked on? How does it differ from bitcoin?

I'm going to try to take same descriptions from the bitcoin wiki/wikipedia here:

https://en.bitcoin.it/wiki/Main_Page
http://en.wikipedia.org/wiki/Bitcoin

And try to retype some of them to describe Monero right in this thread when I get the chance, so that the information can be copied/pasted in the future. If someone working on the wikia reads this before I get a chance to contact you, please post here or pm me topics you'd like to see written up.

The FAQ that was started is good but some of it can be an entire topic for sure, and some of it can stay as a FAQ.


Other topics I can think of:

Transaction Auto Splitting
Deterministic Wallets

White Paper Citations:


1. http://bitcoin.org

2. https://en.bitcoin.it/wiki/Category:MixingServices - dead link

3. http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/

4. https://bt.irlbtc.com/view/279249.0

5. http://msrvideo.vo.msecnd.net/rmcvideos/192058/dl/192058.pdf

6. https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki#Speci%0Ccation.

7. https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#BackwardsCompatibility

8. https://en.bitcoin.it/wiki/Mininghardwarecomparison - dead link

9. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

10. http://luke.dashjr.org/programs/bitcoin/%0Cles/charts/branches.html - dead link

11. https://bt.irlbtc.com/view/196259.0

12. https://en.bitcoin.it/wiki/Contracts

13. https://en.bitcoin.it/wiki/Script

14. http://litecoin.org

15. Moderately hard, memory-bound functions   

16. Ad-hoc-group signatures from hi-jacked keypairs
   
17. Short linkable ring signatures revisited

18. High-speed high-security signatures
   
19. Group signatures
   
20. Exponential memory-bound functions for proof of work protocols
   
21. Proofs of partial knowledge and simplied design of witness hiding protocols
   
22. On memory-bound functions for fighting spam - another nice one
   
23. Sub-linear size traceable ring signatures without random oracles

24. Traceable ring signature
   
25. Peer review of "quantitative analysis of the full bitcoin transaction graph"
   
26. Linkable spontaneous anonymous group signature for ad hoc groups
   
27. Linkable ring signatures: Security models and new schemes (Link courtesy of binaryFate)

28. Zerocoin: Anonymous distributed e-cash from bitcoin
   
29.  Structure and anonymity of the bitcoin transaction graph
   
30. Universal electronic cash
   
31. The bitcoin transaction graph | anonymity
   
32. Stronger key derivation via sequential memory-hard functions
   
33. An analysis of anonymity in the bitcoin system
   
34. How to leak a secret
   
35. Quantitative analysis of the full bitcoin transaction graph
   
36. Analysis of hashrate-based double-spending
   
37. Rational points on certain hyperelliptic curves over finite fields
   
38. Ad hoc group signatures (Link courtesy of binaryFate)

Spot on - first we refactor in order to support arbitrary key-value stores, and then we test a bunch of them for our specific workloads before deciding on one. Initial candidates that we liked out the box were hamsterdb and rocksdb. There's been some contention as there is a slightly faster version of hamsterdb available for purchase (you get the source, but can't distribute it), and some people feel its very availability would compromise the integrity of Monero. On the other hand, rocksdb (a leveldb fork by Facebook) breaks leveldb's Windows compatibility.

So everything is staying as loose and generic as possible, and then we'll plug into as many embedded databases as we can get our hands on, and publish the results. I'm also terribly keen on having a full node pushing the blockchain on to Tahoe-LAFS and having a bunch of independent nodes "verify" that the correct blockchain is being pushed, partly for fun, but also because I can envision some interesting use-cases where applications can be built accessing the blockchain on Tahoe-LAFS instead of locally (lightweight clients, for instance).

What is great about the approach being taken is that databases will be pluggable and it will be easy for others in the community to test their favorite databases and report. There is no reason to think the official build might not eventually use a database identified by the community as the best one, or that there will be different builds for different applications (pool node, high volume non-mining node, end user wallet, etc.)

 

Maybe you misunderstand (I'm not sure).

We will likely ship and support just one database, or maybe a database and a flat file version.

Other people (for example a payment processing service, exchange, etc.) who want to make their own customized deployment might do something else, but we wouldn't be supporting that, they would.

I did a 'git clone' followed by 'make test-release' to run the Monero project's built-in test suite.  Two of the twelve tests fail: coretests and unit_tests.  I'm on Linux (Ubuntu).  Anybody else have this problem?  I have the same problem with both the latest release ('git checkout tags/v0.8.8.6') and the most recent updates (v0.8.8.6-46-g6e5797d).  Coretests takes a really long time before it fails.  Like half an hour.