Author

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

hero member
Activity: 938
Merit: 1001
Would someone help me compile? I am Ubuntu 14.04 64bit, Fresh install. I get no errors until make. Then I get:

Code:

...


I am folowing the instructions from here -> http://boolberry.com/howto.html

My guess is you don't have enough memory, try adding a swap

Good call. I tried with swap but got same error. I will setup a VM on my desktop with more RAM (4GB).
hero member
Activity: 938
Merit: 1001
DEV,I had a problem
I have some E3 cpus,the hashrate at 270K/S in windows 7 and 360K/S in ubuntu 13.10
but in the win 7 PXE(one server with PXE some client without harddisk) I got only 100K/S using 8 threads of my E3 1230V2
anything wrong?

Mining is faster on Linux than on Windows for cryptonote coins. I think Boolberry is the same (even thought it uses a different algo).

I believe crypto_zoidberg introduced some optimizations for AVX/AES that server CPUs usually do not have. Someone ellse mentioned this issue earlier. Crypto_ziodberg would have to answer in order to be certain.
sr. member
Activity: 462
Merit: 250
and 3 threads on the i5-3570k on my desktop.

Why not 4?


It's my daily use desktop, leaving a thread free so it doesn't slow me down.
sr. member
Activity: 253
Merit: 250
Let's Boolberry
DEV,I had a problem
I have some E3 cpus,the hashrate at 270K/S in windows 7 and 360K/S in ubuntu 13.10
but in the win 7 PXE(one server with PXE some client without harddisk) I got only 100K/S using 8 threads of my E3 1230V2
anything wrong?
sr. member
Activity: 309
Merit: 250
confused developer
hero member
Activity: 938
Merit: 1001
Would someone help me compile? I am Ubuntu 14.04 64bit, Fresh install. I get no errors until make. Then I get:

Code:
[ 46%] [ 47%] [ 47%] Building CXX object src/CMakeFiles/rpc.dir/rpc/core_rpc_server.cpp.o
Building CXX object src/CMakeFiles/wallet.dir/wallet/wallet2.cpp.o
Building CXX object src/CMakeFiles/wallet.dir/wallet/wallet_rpc_server.cpp.o
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [tests/gtest/CMakeFiles/gtest.dir/src/gtest-all.cc.o] Error 4
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [tests/gtest/CMakeFiles/gtest.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
virtual memory exhausted: Cannot allocate memory
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/common.dir/common/command_line.cpp.o] Error 4
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [src/CMakeFiles/common.dir/common/util.cpp.o] Error 1
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/checkpoints.cpp.o] Error 4
make[3]: *** Waiting for unfinished jobs....
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/currency_basic_impl.cpp.o] Error 4
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/tx_pool.cpp.o] Error 4
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/account.cpp.o] Error 4
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/currency_format_utils.cpp.o] Error 4
virtual memory exhausted: Cannot allocate memory
make[3]: *** [src/CMakeFiles/wallet.dir/wallet/wallet_rpc_server.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/currency_core.cpp.o] Error 4
virtual memory exhausted: Cannot allocate memory
make[3]: *** [src/CMakeFiles/wallet.dir/wallet/wallet2.cpp.o] Error 1
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [src/CMakeFiles/wallet.dir/all] Error 2
virtual memory exhausted: Cannot allocate memory
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/miner.cpp.o] Error 1
Linking C static library libminiupnpc.a
make[3]: Leaving directory `/root/boolberry/build/release'
[ 47%] Built target upnpc-static
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/common.dir/common/base58.cpp.o] Error 4
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [src/CMakeFiles/common.dir/all] Error 2
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/currency_core.dir/currency_core/blockchain_storage.cpp.o] Error 4
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [src/CMakeFiles/currency_core.dir/all] Error 2
Linking CXX executable crypto-tests
Linking CXX static library libcrypto.a
make[3]: Leaving directory `/root/boolberry/build/release'
[ 47%] Built target crypto
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[3]: *** [src/CMakeFiles/rpc.dir/rpc/core_rpc_server.cpp.o] Error 4
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [src/CMakeFiles/rpc.dir/all] Error 2
make[3]: Leaving directory `/root/boolberry/build/release'
[ 47%] Built target crypto-tests
make[2]: Leaving directory `/root/boolberry/build/release'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/boolberry/build/release'
make: *** [build-release] Error 2

I am folowing the instructions from here -> http://boolberry.com/howto.html
legendary
Activity: 1022
Merit: 1000
Quote
Blockchain-based hash: unlike Bytecoin PoW hash, which works on 2MB scratchpad and takes avr 400 ms, new hash will work on blockchain random data to provide operation speed. It gives faster synchronization with network and immunity from DoS attacks.

So how usefull is that innovation really and how vulnerable is it in comparison to traditional approaches? Cant the supposedly random data from the blockchain be precalculated because, well its already there and not changing much with every new block?

Im no techie, so pls have mercy on me Wink
With traditional approach, increasing scratchpad leads to increasing time for hash calculation, since hash have to cover all scratchpad memory, to avoid precalculations. Slow PoW hash can lead to pretty big amount of problems, such as weastimg resources with calculating fake PoW, long synchronization, e.t.c. At the other hand, even pretty big fixed scratchpad (2mb for example) doesn't grant that hardware will not move to this area(remember litecoin, they was counted on it, but now they explaining that ASICs is not so bad).

Research of other PoW approaches, based on asymmetric memory consuming algorithms (ethereum dagger, Cuckoo Cycle) showed me that there always some risk that algorithm could be reinvented and PoW may become unsuitable(for ex reinvented algo may request few memory).

I've just tried to make a step back and look for another way, i want to have one hash operation fast and strong, but i want to have mining process memory hard, because it seems to be great protection from ASIC.

I chose scratchpad memory increasing speed that gives enough protection(and even with extra margin for future) but at the same time make able to implement SPV client or mobile version without any problems.
It's pretty new approach as i know, well, we'll see how things go.

Feel free to contact me if you have any questions.

Thx, so I probably got it wrong, but how random is the blockchain data? How is it used in the hash algo?
member
Activity: 140
Merit: 12
I found a block!!

I have about 500kh/s but 200kh/s of that is not 24/7.

woohoo!  Smiley
full member
Activity: 126
Merit: 100
Boolberry (BBR) has been added to the 'The Big List Of Alternative Cryptocurrencies And Their Trading Symbols' - http://altcoinherald.com/altcoin-lists/list-alternative-cryptocurrency-trading-symbols/  Grin

Good luck!
sr. member
Activity: 336
Merit: 250
and 3 threads on the i5-3570k on my desktop.

Why not 4?
sr. member
Activity: 462
Merit: 250
Quote
Blockchain-based hash: unlike Bytecoin PoW hash, which works on 2MB scratchpad and takes avr 400 ms, new hash will work on blockchain random data to provide operation speed. It gives faster synchronization with network and immunity from DoS attacks.

So how usefull is that innovation really and how vulnerable is it in comparison to traditional approaches? Cant the supposedly random data from the blockchain be precalculated because, well its already there and not changing much with every new block?

Im no techie, so pls have mercy on me Wink
With traditional approach, increasing scratchpad leads to increasing time for hash calculation, since hash have to cover all scratchpad memory, to avoid precalculations. Slow PoW hash can lead to pretty big amount of problems, such as weastimg resources with calculating fake PoW, long synchronization, e.t.c. At the other hand, even pretty big fixed scratchpad (2mb for example) doesn't grant that hardware will not move to this area(remember litecoin, they was counted on it, but now they explaining that ASICs is not so bad).

Research of other PoW approaches, based on asymmetric memory consuming algorithms (ethereum dagger, Cuckoo Cycle) showed me that there always some risk that algorithm could be reinvented and PoW may become unsuitable(for ex reinvented algo may request few memory).

I've just tried to make a step back and look for another way, i want to have one hash operation fast and strong, but i want to have mining process memory hard, because it seems to be great protection from ASIC.

I chose scratchpad memory increasing speed that gives enough protection(and even with extra margin for future) but at the same time make able to implement SPV client or mobile version without any problems.
It's pretty new approach as i know, well, we'll see how things go.

Feel free to contact me if you have any questions.

So, is this the advantage it has over MRO?  Just started digging into this cryptonote tech in the past day, so this is all pretty much greek to me still.
sr. member
Activity: 462
Merit: 250
Use the official tool
INTER-CPU, 30 core. 6 hours nothing
Normal right

I'm mining with 7 threads on an 8320 on my GPU mining rig, and 3 threads on the i5-3570k on my desktop.  After 24 hours found 2 blocks, so give it time.
full member
Activity: 138
Merit: 100
Use the official tool
INTER-CPU, 30 core. 6 hours nothing
Normal right
legendary
Activity: 1148
Merit: 1000
It uses AES, boolberry does not.
There was a lot to optimize, indeed, they had probably the world's slowest implementation of AES.

Smiley

Friends, want to say few words about optimized miner.
When we had a peak few days ago i suspected that some GPU hash was secretly implemented. But i've contacted with miners that was behind this peak - it was actually a big players with huge power.
As far as i know, at this moment there are no optimized or GPU miner. Scratchpad is about 2Mb already and 64bit mul in hash probably make this function is not very attrative for GPU.
But anyway, if soon as i'll see any optimized hash i'll put it into repo.
Peace!

I think an optimized miner is not so important, on the other hand a pool is important.
hero member
Activity: 976
Merit: 646
It uses AES, boolberry does not.
There was a lot to optimize, indeed, they had probably the world's slowest implementation of AES.

Smiley

Friends, want to say few words about optimized miner.
When we had a peak few days ago i suspected that some GPU miner was secretly implemented. But i've contacted with miners that was behind this peak - it was actually a big players with huge power.
As far as i know, at this moment there are no optimized or GPU miner. Scratchpad is about 2Mb already and 64bit mul in hash probably make this function is not very attrative for GPU.
But anyway, soon as i'll see any optimized hash i'll put it into repo.
Peace!
hero member
Activity: 976
Merit: 646
Quote
Blockchain-based hash: unlike Bytecoin PoW hash, which works on 2MB scratchpad and takes avr 400 ms, new hash will work on blockchain random data to provide operation speed. It gives faster synchronization with network and immunity from DoS attacks.

So how usefull is that innovation really and how vulnerable is it in comparison to traditional approaches? Cant the supposedly random data from the blockchain be precalculated because, well its already there and not changing much with every new block?

Im no techie, so pls have mercy on me Wink
With traditional approach, increasing scratchpad leads to increasing time for hash calculation, since hash have to cover all scratchpad memory, to avoid precalculations. Slow PoW hash can lead to pretty big amount of problems, such as weastimg resources with calculating fake PoW, long synchronization, e.t.c. At the other hand, even pretty big fixed scratchpad (2mb for example) doesn't grant that hardware will not move to this area(remember litecoin, they was counted on it, but now they explaining that ASICs is not so bad).

Research of other PoW approaches, based on asymmetric memory consuming algorithms (ethereum dagger, Cuckoo Cycle) showed me that there always some risk that algorithm could be reinvented and PoW may become unsuitable(for ex reinvented algo may request few memory).

I've just tried to make a step back and look for another way, i want to have one hash operation fast and strong, but i want to have mining process memory hard, because it seems to be great protection from ASIC.

I chose scratchpad memory increasing speed that gives enough protection(and even with extra margin for future) but at the same time make able to implement SPV client or mobile version without any problems.
It's pretty new approach as i know, well, we'll see how things go.

Feel free to contact me if you have any questions.
sr. member
Activity: 336
Merit: 250
there is now a cpu miner optimised for MRO (minerd)

It uses AES, boolberry does not.
There was a lot to optimize, indeed, they had probably the world's slowest implementation of AES.
I dont think an optimize miner is better
If we all rise the hash,so we rise the diff
are you guys do see the problem?

If all use the optimized miner, all still find same amount of blocks.
sr. member
Activity: 253
Merit: 250
Let's Boolberry
there is now a cpu miner optimised for MRO (minerd)

It uses AES, boolberry does not.
There was a lot to optimize, indeed, they had probably the world's slowest implementation of AES.
I dont think an optimize miner is better
If we all rise the hash,so we rise the diff
are you guys do see the problem?
sr. member
Activity: 336
Merit: 250
there is now a cpu miner optimised for MRO (minerd)

It uses AES, boolberry does not.
There was a lot to optimize, indeed, they had probably the world's slowest implementation of AES.
full member
Activity: 182
Merit: 100
there is now a cpu miner optimised for MRO (minerd)
Any chance he can work with boolb, or to see an optimized miner ?
Jump to: