Quote from: owm123 on October 02, 2015, 05:44:38 AM

bbr, just like xmr, is also cryptonote. Thus, I wonder, what are technical differences between bbr and xmr?

You are right that they have a lot in common. Here are a few of the biggest technical differences:
1. Working, Official GUI
http://boolberry.com/downloads.html
Monero currently has several unofficial GUI's and a web wallet

2. Minimum mixin# solution (already implemented):
http://boolberry.com/files/Boolberry_Solves_CryptoNote_Flaws.pdf
Monero has its own plans for how to address this issue:
https://lab.getmonero.org/pubs/MRL-0004.pdf

3. Blockchain bloat solution (already implemented):
http://boolberry.org/files/Boolberry_Reduces_Blockchain_Bloat.pdf

4. Emission Schedule:
Slower than Monero

5. Similar to Monero, Boolberry is currently testing new db code:
https://github.com/cryptozoidberg/Boolberry/tree/db
feedback from smooth and crypto zoidberg:

Quote from: crypto_zoidberg on September 18, 2015, 06:07:35 AM

Quote from: smooth on September 14, 2015, 01:26:48 AM

Quote from: newb4now on September 14, 2015, 12:38:25 AM

what makes the leveldb integration at boolberry different than what monero is doing? Or it is somewhat similar?

The leveldb here is only being used to store list of blocks, not all the other in-memory stuff that makes up a node (transactions, block index, output indexes, etc.). Monero moves all that stuff to the DB.

Advantages of BBR approach:

1. Simpler to implement and get right
2. Some operations still using the in-memory data may be more efficient

Disadvantages of BBR approach:

3. Higher remaining memory usage (but with BBR's pruning and lower volume of usage, probably not too bad)

4. Some possibility of inconsistencies between the two data stores in-mem and database (clintar's fix addresses one instance of this)

Agree with this, actually this is the main reason why DB implementaton stil in branch. The way we decided to go here - is to step-by-step move parts of storage from boost serialization to leveldb - is way that let us easely reduce memory usage, but at other hand we need always have consistent state of both parts: serialized storage and leveldb.
The problem is that leveldb write changes right after every operations (there are different options, but still the idea of level db is like this). Clintar made workaround for current implementation, but this won't work if i'll move other containers to leveldb(or the workaround become be very-very complicated). So now it's only betta.
Leveldb have some kind of "snapshots", this could work but db can't be reverted to this snapshots, so it useless i guess.

The only way i see now is to move all stored data to leveldb and use batch writes to keep data consistent.

Quote from: smooth on September 14, 2015, 01:26:48 AM

5. Still requires the periodic "save blockchain" timer, which pauses many daemon functions during the saving process (though the process should be faster without needing to save the block list)

#1 is pretty significant IMO. Given that these projects are all works in progress, building the ultimate solution on the first go is not aways the best approach.

EDIT: added #5