[BBR] Boolberry: Privacy and Security - Guaranteed Since 2014 - page 177.

newb4now

hero member

Activity: 686

Merit: 500

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

Quote from: smooth on September 13, 2015, 09:26:48 PM

Quote from: newb4now on September 13, 2015, 08:38:25 PM

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 13, 2015, 09:26:48 PM

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

I sounds like you have put a lot of thought into this. Thank you for your careful planning. I am really excited about the future of boolberry

languagehasmeaning

sr. member

Activity: 336

Merit: 250

I love boolberry but I now have a new favorite thread:

https://bitcointalksearch.org/topic/lets-play-a-game-of-chess-1148538
(come join if you like chess)

Back on topic..... I would love to hear feedback from those testing the new db code from github.

Do we have any data about how many people have tested it and any trouble (if any) they have ran into?

I thought the cointopay.com boolberry acceptance news was a good thing. Has anyone used the service yet?

crypto_zoidberg

hero member

Activity: 976

Merit: 646

Quote from: smooth on September 13, 2015, 09:26:48 PM

Quote from: newb4now on September 13, 2015, 08:38:25 PM

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 13, 2015, 09:26:48 PM

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

clintar2

full member

Activity: 202

Merit: 104

Quote from: smooth on September 13, 2015, 09:26:48 PM

Quote from: newb4now on September 13, 2015, 08:38:25 PM

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)
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

Yeah, #5 is probably the main reason I'd like to see everything changed to db. I might try to tackle that based on cz's main blocks changes.

newb4now

hero member

Activity: 686

Merit: 500

Quote from: smooth on September 13, 2015, 09:26:48 PM

Quote from: newb4now on September 13, 2015, 08:38:25 PM

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)
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

Thanks for your detailed and impartial response! I found it very helpful

boolberry

sr. member

Activity: 378

Merit: 250

Cross post from [DASH/XDN/XMR/SDC] Comparison thread. Someone asked about BBR
https://bitcointalksearch.org/topic/dashxdnxmrsdc-comparison-between-the-most-known-anonymous-coins-must-read-985039

Quote from: boolberry on September 15, 2015, 11:02:29 PM

Quote from: owm123 on August 30, 2015, 03:20:19 AM

How does boolbery compare to dash, xdn, xmr and sdc?BBR also aims at being anonymous coin.

Of the coins you mentioned BBR is closest to XMR and XDN (they are PoW CryptoNote). Here are a few of its important distinctions:
On mixin issue and its relation to privacy:
http://boolberry.com/files/Boolberry_Solves_CryptoNote_Flaws.pdf

On blockchain bloat:
http://boolberry.org/files/Boolberry_Reduces_Blockchain_Bloat.pdf

The BBR emission schedule is much slower than those two coins as well. Most XDN coins were mined in the first year. XMR just passed 50% (pre tail) emission.

Development continues. This is the current focus:
https://twitter.com/BBRcurrency/status/642419677411479552

AEON and DSH are two other CryptoNote coins that deserve some attention for different reasons.

languagehasmeaning

sr. member

Activity: 336

Merit: 250

Quote from: clintar2 on September 14, 2015, 04:50:00 AM

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

Quote from: clintar2 on September 13, 2015, 11:44:38 PM

Is the other instance you refer to if the saved blockchain is more recent that the lmdb database (which I'm not sure how that would happen in practice unless you copied a newer blockchain.bin where there's an older db), or are you talking about something else?

Just in general that the process isn't transnational the way an ACID database commit normally would be so things can go wrong in various ways. Without carefully auditing the ordering of events and the behavior of various operating systems it is hard to be 100% sure what failure modes are possible.

For example, another failure that occasionally happens on Windows (for all cryptonotes) is the blockchain.bin file gets corrupted during save since there isn't a really good way to replace a file atomically (on Linux you can rename-replace, which mostly works). This would leave you with a valid database but an invalid blockchain.bin. Of course this would probably be no worse than the previous (no db) case, but would be worse than the full db case. This is fixable, but somewhat annoying to fix, especially if all the data is going to end up in a database eventually anyway (I have no idea as to your plans).

BTW, in case my comments were not clear I do think this is nice work by crypto_zoidberg and clintar.

Ok, thanks for the input. Just wondered if there was something I should be looking into I hadn't thought of. I don't really know the plans, either. Just was contributing what I came up with as a work-around. I agree having everything in the database does take care if these issues, too. Pretty slick how cz implemented the db, though, huh? At least I thought so. Anyone have any suggestions for things they want to see in the codebase?

I would love to see support for multisig transactions! Is that a realistic goal?

clintar2

full member

Activity: 202

Merit: 104

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

Quote from: clintar2 on September 13, 2015, 11:44:38 PM

Is the other instance you refer to if the saved blockchain is more recent that the lmdb database (which I'm not sure how that would happen in practice unless you copied a newer blockchain.bin where there's an older db), or are you talking about something else?

Just in general that the process isn't transnational the way an ACID database commit normally would be so things can go wrong in various ways. Without carefully auditing the ordering of events and the behavior of various operating systems it is hard to be 100% sure what failure modes are possible.

For example, another failure that occasionally happens on Windows (for all cryptonotes) is the blockchain.bin file gets corrupted during save since there isn't a really good way to replace a file atomically (on Linux you can rename-replace, which mostly works). This would leave you with a valid database but an invalid blockchain.bin. Of course this would probably be no worse than the previous (no db) case, but would be worse than the full db case. This is fixable, but somewhat annoying to fix, especially if all the data is going to end up in a database eventually anyway (I have no idea as to your plans).

BTW, in case my comments were not clear I do think this is nice work by crypto_zoidberg and clintar.

Ok, thanks for the input. Just wondered if there was something I should be looking into I hadn't thought of. I don't really know the plans, either. Just was contributing what I came up with as a work-around. I agree having everything in the database does take care if these issues, too. Pretty slick how cz implemented the db, though, huh? At least I thought so. Anyone have any suggestions for things they want to see in the codebase?

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: clintar2 on September 13, 2015, 11:44:38 PM

Is the other instance you refer to if the saved blockchain is more recent that the lmdb database (which I'm not sure how that would happen in practice unless you copied a newer blockchain.bin where there's an older db), or are you talking about something else?

Just in general that the process isn't transactional the way an ACID database commit normally would be so things can go wrong in various ways. Without carefully auditing the ordering of events and the behavior of various operating systems it is hard to be 100% sure what failure modes are possible.

For example, another failure that occasionally happens on Windows (for all cryptonotes) is the blockchain.bin file gets corrupted during save since there isn't a really good way to replace a file atomically (on Linux you can rename-replace, which mostly works). This would leave you with a valid database but an invalid blockchain.bin. Of course this would probably be no worse than the previous (no db) case, but would be worse than the full db case. This is fixable, but somewhat annoying to fix, especially if all the data is going to end up in a database eventually anyway (I have no idea as to your plans).

BTW, in case my comments were not clear I do think this is nice work by crypto_zoidberg and clintar.

clintar2

full member

Activity: 202

Merit: 104

Quote from: smooth on September 13, 2015, 09:26:48 PM

Quote from: newb4now on September 13, 2015, 08:38:25 PM

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)

#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.

Is the other instance you refer to if the saved blockchain is more recent that the lmdb database (which I'm not sure how that would happen in practice unless you copied a newer blockchain.bin where there's an older db), or are you talking about something else?

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: newb4now on September 13, 2015, 08:38:25 PM

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)
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

newb4now

hero member

Activity: 686

Merit: 500

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

I know the mixin rules, pruning, difficulty algorithm and emission calendar are all different

languagehasmeaning

sr. member

Activity: 336

Merit: 250

Can someone update the OP and replace twitter.com/boolberryBBR (has not tweeted in a long time) with twitter.com/bbrcurrency (active account)?

languagehasmeaning

sr. member

Activity: 336

Merit: 250

Quote from: clintar2 on September 11, 2015, 03:26:28 PM

Quote from: languagehasmeaning on September 10, 2015, 12:20:03 AM

...snip...
I really appreciate your advice but don't really feel comfortable with this type of experimentation.

Is there anyone here who has already installed the GUI on Ubuntu? Could you provide me instructions step by step?

I know you got this sorted out, but If you ever want to build the gui yourself, you don't need to change the file. Following http://boolberry.com/howto.html#build_gui you just

Code:

mkdir -p build/release; cd build/release
cmake -D BUILD_GUI=TRUE -D CMAKE_PREFIX_PATH=/home/user/Qt/5.3/gcc_64 -D CMAKE_BUILD_TYPE=Release ../..
make qt-boolb

That would put the binary in build/release/src as qt-boolb. What I do is go into that directory and run

Code:

cp -r ../../../src/gui/qt-daemon/html .

then you can run

Code:

./qt-boolb

Quote from: crypto_zoidberg on September 11, 2015, 02:38:23 PM

Hi Folk!

We (Clintar and me) made some db code, which seems to work fine. (we made some tests on clintar's backend).
This code take part of blockchain data (blockchain.bin) and store it in leveldb database. Is things gonna be ok we'll move the rest of data into leveldb database.

Anyone who interested to reduce memory usage in Boolberry daemon, could try to use code from "db" branch for test.

Thanks for any feedback.

Zoidberg

PS: Many thanks to Clintar for helping, supporting and even coding Boolberry!

Just for information's sake, when testing this out, memory usage can remain high since it caches the database for speed, until system gets squeezed for memory (like say compiling the daemon again with -j4). The daemon will let go if there is memory contention. I've seen it get down to like 160 MB used.

P.S. My previous clintar account got banned because I forgot my password and tried to log in using my security question I think. I could never get a mod to answer at the email address it told me to send to, so I'm clintar2 now, I guess.

Thanks again. I am learning slowly. From the instructions you cited this was the confusing part:

1. Download Qt Installer from website: http://qt-project.org/downloads, add executable attribute to it, and run, follow instructions.
2. Install additional tools:

sudo apt-get install libgl1-mesa-dev libdrm-dev

For newcomers it may help to define exactly how to "add executable attribute to it and run"

I am sure these things will become easy for me in time. Right now I still have to Google everything or ask questions. I am paranoid about messing something up

bbreconomy

member

Activity: 75

Merit: 10

Quote from: bitcoinrocks on September 11, 2015, 04:10:28 PM

Anybody looking to sell BBR?

This honestly seems like the worst possible time to sell BBR. CryptoZoidberg is visibly active again and there is new db code to test.

Last summer fall around the time of the SuperNet announcement and huge price increase might have been a good time to sell BBR. Today will important development progress being made and prices and extremely low levels I see no reason why anyone would want to sell

bitcoinrocks

legendary

Activity: 1372

Merit: 1000

Anybody looking to sell BBR?

AnonCoinTwitter

full member

Activity: 158

Merit: 100

Quote from: boolberry on September 11, 2015, 03:38:21 PM

Quote from: crypto_zoidberg on September 11, 2015, 02:38:23 PM

Hi Folk!

We (Clintar and me) made some db code, which seems to work fine. (we made some tests on clintar's backend).
This code take part of blockchain data (blockchain.bin) and store it in leveldb database. Is things gonna be ok we'll move the rest of data into leveldb database.

Anyone who interested to reduce memory usage in Boolberry daemon, could try to use code from "db" branch for test.

Thanks for any feedback.

Zoidberg

PS: Many thanks to Clintar for helping, supporting and even coding Boolberry!

exciting news!

I just shared it on Twitter:
https://twitter.com/BBRcurrency/status/642419677411479552

I have been more active lately reaching out to potential merchants. Some (such as a few vpns) and purism today seem interested to learn more:
https://twitter.com/Puri_sm/status/642201280736161793

If more people could contact privacy focused companies that would make it much easier to increase adoption

I retweeted you.

This is one of the most exciting privacy focused coins in crypto. My followers were originally more focused on zerocoin but based on long development delays I think many of them will now look to cryptonote as the best available tech on the market right now

boolberry

sr. member

Activity: 378

Merit: 250

Quote from: crypto_zoidberg on September 11, 2015, 02:38:23 PM

Hi Folk!

We (Clintar and me) made some db code, which seems to work fine. (we made some tests on clintar's backend).
This code take part of blockchain data (blockchain.bin) and store it in leveldb database. Is things gonna be ok we'll move the rest of data into leveldb database.

Anyone who interested to reduce memory usage in Boolberry daemon, could try to use code from "db" branch for test.

Thanks for any feedback.

Zoidberg

PS: Many thanks to Clintar for helping, supporting and even coding Boolberry!

exciting news!

I just shared it on Twitter:
https://twitter.com/BBRcurrency/status/642419677411479552

I have been more active lately reaching out to potential merchants. Some (such as a few vpns) and purism today seem interested to learn more:
https://twitter.com/Puri_sm/status/642201280736161793

If more people could contact privacy focused companies that would make it much easier to increase adoption

clintar2

full member

Activity: 202

Merit: 104

Quote from: languagehasmeaning on September 10, 2015, 12:20:03 AM

...snip...
I really appreciate your advice but don't really feel comfortable with this type of experimentation.

Is there anyone here who has already installed the GUI on Ubuntu? Could you provide me instructions step by step?

I know you got this sorted out, but If you ever want to build the gui yourself, you don't need to change the file. Following http://boolberry.com/howto.html#build_gui you just

Code:

mkdir -p build/release; cd build/release
cmake -D BUILD_GUI=TRUE -D CMAKE_PREFIX_PATH=/home/user/Qt/5.3/gcc_64 -D CMAKE_BUILD_TYPE=Release ../..
make qt-boolb

That would put the binary in build/release/src as qt-boolb. What I do is go into that directory and run

Code:

cp -r ../../../src/gui/qt-daemon/html .

then you can run

Code:

./qt-boolb

Quote from: crypto_zoidberg on September 11, 2015, 02:38:23 PM

Hi Folk!

We (Clintar and me) made some db code, which seems to work fine. (we made some tests on clintar's backend).
This code take part of blockchain data (blockchain.bin) and store it in leveldb database. Is things gonna be ok we'll move the rest of data into leveldb database.

Anyone who interested to reduce memory usage in Boolberry daemon, could try to use code from "db" branch for test.

Thanks for any feedback.

Zoidberg

PS: Many thanks to Clintar for helping, supporting and even coding Boolberry!

Just for information's sake, when testing this out, memory usage can remain high since it caches the database for speed, until system gets squeezed for memory (like say compiling the daemon again with -j4). The daemon will let go if there is memory contention. I've seen it get down to like 160 MB used.

P.S. My previous clintar account got banned because I forgot my password and tried to log in using my security question I think. I could never get a mod to answer at the email address it told me to send to, so I'm clintar2 now, I guess.

shojayxt

legendary

Activity: 896

Merit: 1001

Quote from: crypto_zoidberg on September 11, 2015, 02:38:23 PM

Hi Folk!

We (Clintar and me) made some db code, which seems to work fine. (we made some tests on clintar's backend).
This code take part of blockchain data (blockchain.bin) and store it in leveldb database. Is things gonna be ok we'll move the rest of data into leveldb database.

Anyone who interested to reduce memory usage in Boolberry daemon, could try to use code from "db" branch for test.

Thanks for any feedback.

Zoidberg

PS: Many thanks to Clintar for helping, supporting and even coding Boolberry!

Great news! Will test it out.

Topic: [BBR] Boolberry: Privacy and Security - Guaranteed Since 2014 - page 177. (Read 1210749 times)