.........
Updated the system and prompted a new question.
ubuntu 14.04-64 boost1.68 GCC5.5
Linking CXX executable connectivity_tool
lto1: error: bad value (knl) for -march= switch
lto-wrapper: /usr/bin/c++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[3]: *** [src/connectivity_tool] Error 1
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [src/CMakeFiles/connectivity_tool.dir/all] Error 2
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'll take care about this, but for now, to build daemon and wallet you can use: make -j daemon simplewallet This will build what you need. (If you building GUI then make -j daemon simplewallet Boolberry) Let me know if that worked for you. root@iZhp3a3slnxeawyllt1n1zZ:~/boolberry# make -j daemon simplewallet make: *** No rule to make target `daemon'. Stop. You supposed to compile from build folder, which is "/root/boolberry/build" on your machine I guess. cd /root/boolberry/build
make -j daemon simplewallet
|
|
|
|
.........
Updated the system and prompted a new question.
ubuntu 14.04-64 boost1.68 GCC5.5
Linking CXX executable connectivity_tool
lto1: error: bad value (knl) for -march= switch
lto-wrapper: /usr/bin/c++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[3]: *** [src/connectivity_tool] Error 1
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [src/CMakeFiles/connectivity_tool.dir/all] Error 2
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'll take care about this, but for now, to build daemon and wallet you can use: make -j daemon simplewallet This will build what you need. (If you building GUI then make -j daemon simplewallet Boolberry) Let me know if that worked for you. |
|
|
|
.....
Thank you！
After updating boost1.58, there are new problems in the compilation.
What problems? Can you send logs? Prompt for new questions: [ 51%] Building CXX object src/CMakeFiles/wallet.dir/wallet/wallet2.cpp.o In file included from /root/boolberry/contrib/epee/include/misc_log_ex.h:54:0, from /root/boolberry/contrib/epee/include/include_base_utils.h:31, from /root/boolberry/src/wallet/wallet2.cpp:10: /root/boolberry/contrib/epee/include/os_defenitions.h:34:5: warning: "_WIN32" is not defined [-Wundef] #if _WIN32 || _WIN64 ^ /root/boolberry/contrib/epee/include/os_defenitions.h:34:15: warning: "_WIN64" is not defined [-Wundef] #if _WIN32 || _WIN64 ^ In file included from /root/boolberry/contrib/epee/include/net/http_client.h:42:0, from /root/boolberry/src/wallet/core_default_rpc_proxy.h:8, from /root/boolberry/src/wallet/wallet2.h:23, from /root/boolberry/src/wallet/wallet2.cpp:13: /root/boolberry/contrib/epee/include/gzip_encoding.h: In constructor ‘epee::net_utils::content_encoding_gzip::content_encoding_gzip(epee::net_utils::i_target_handler*, bool, int)’: /root/boolberry/contrib/epee/include/gzip_encoding.h:59:8: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] int ret = 0; ^ In file included from /usr/local/include/boost/integer.hpp:23:0, from /usr/local/include/boost/archive/basic_binary_oprimitive.hpp:41, from /usr/local/include/boost/archive/binary_oarchive_impl.hpp:22, from /usr/local/include/boost/archive/binary_oarchive.hpp:21, from /root/boolberry/src/wallet/wallet2.cpp:6: /usr/local/include/boost/variant/get.hpp: In instantiation of ‘typename boost::add_reference<const U>::type boost::strict_get(const boost::variant<T0, TN ...>&) [with U = const currency::txout_to_key&; T0 = currency::txout_to_script; TN = {currency::txout_to_scripthash, currency::txout_to_key}; typename boost::add_reference<const U>::type = const currency::txout_to_key&]’: /usr/local/include/boost/variant/get.hpp:299:33: required from ‘typename boost::add_reference<const U>::type boost::get(const boost::variant<T0, TN ...>&) [with U = const currency::txout_to_key&; T0 = currency::txout_to_script; TN = {currency::txout_to_scripthash, currency::txout_to_key}; typename boost::add_reference<const U>::type = const currency::txout_to_key&]’ /root/boolberry/src/wallet/wallet2.cpp:1103:75: required from here /usr/local/include/boost/variant/get.hpp:229:5: error: static assertion failed: boost::variant does not contain specified type U, call to boost::get<U>(const boost::variant<T...>&) will always throw boost::bad_get exception BOOST_STATIC_ASSERT_MSG( ^ 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 make[2]: Leaving directory `/root/boolberry/build/release' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/boolberry/ Dear skygonga! Can you provide which boost version are you using, which OS and which compiler? ubuntu 14.04-64 boost1.58 Dear friend, you are using old boost version, as i told you before - you need to update to newer one, at least boost 1.64. And you'd better update your compiler as well, default gcc on 14.04 is outdated. |
|
|
|
Why there are than one blockchain? Do they work together? How can i see that it is safe?
Not really sure what you meant... can you clarify? |
|
|
|
any news about launch?
Can't say about the launch of main net, but i'm definately going to relaunch testnet in next 2 days. BOOM, I'll take it! Any details on updates within the wallet that will be pushed? Mostly it's a new difficulty adjustment + WildKeccak with 500MB scratchpad/light scratchpad. |
|
|
|
.....
Thank you！
After updating boost1.58, there are new problems in the compilation.
What problems? Can you send logs? Prompt for new questions: [ 51%] Building CXX object src/CMakeFiles/wallet.dir/wallet/wallet2.cpp.o In file included from /root/boolberry/contrib/epee/include/misc_log_ex.h:54:0, from /root/boolberry/contrib/epee/include/include_base_utils.h:31, from /root/boolberry/src/wallet/wallet2.cpp:10: /root/boolberry/contrib/epee/include/os_defenitions.h:34:5: warning: "_WIN32" is not defined [-Wundef] #if _WIN32 || _WIN64 ^ /root/boolberry/contrib/epee/include/os_defenitions.h:34:15: warning: "_WIN64" is not defined [-Wundef] #if _WIN32 || _WIN64 ^ In file included from /root/boolberry/contrib/epee/include/net/http_client.h:42:0, from /root/boolberry/src/wallet/core_default_rpc_proxy.h:8, from /root/boolberry/src/wallet/wallet2.h:23, from /root/boolberry/src/wallet/wallet2.cpp:13: /root/boolberry/contrib/epee/include/gzip_encoding.h: In constructor ‘epee::net_utils::content_encoding_gzip::content_encoding_gzip(epee::net_utils::i_target_handler*, bool, int)’: /root/boolberry/contrib/epee/include/gzip_encoding.h:59:8: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] int ret = 0; ^ In file included from /usr/local/include/boost/integer.hpp:23:0, from /usr/local/include/boost/archive/basic_binary_oprimitive.hpp:41, from /usr/local/include/boost/archive/binary_oarchive_impl.hpp:22, from /usr/local/include/boost/archive/binary_oarchive.hpp:21, from /root/boolberry/src/wallet/wallet2.cpp:6: /usr/local/include/boost/variant/get.hpp: In instantiation of ‘typename boost::add_reference<const U>::type boost::strict_get(const boost::variant<T0, TN ...>&) [with U = const currency::txout_to_key&; T0 = currency::txout_to_script; TN = {currency::txout_to_scripthash, currency::txout_to_key}; typename boost::add_reference<const U>::type = const currency::txout_to_key&]’: /usr/local/include/boost/variant/get.hpp:299:33: required from ‘typename boost::add_reference<const U>::type boost::get(const boost::variant<T0, TN ...>&) [with U = const currency::txout_to_key&; T0 = currency::txout_to_script; TN = {currency::txout_to_scripthash, currency::txout_to_key}; typename boost::add_reference<const U>::type = const currency::txout_to_key&]’ /root/boolberry/src/wallet/wallet2.cpp:1103:75: required from here /usr/local/include/boost/variant/get.hpp:229:5: error: static assertion failed: boost::variant does not contain specified type U, call to boost::get<U>(const boost::variant<T...>&) will always throw boost::bad_get exception BOOST_STATIC_ASSERT_MSG( ^ 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 make[2]: Leaving directory `/root/boolberry/build/release' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/boolberry/ Dear skygonga! Can you provide which boost version are you using, which OS and which compiler? |
|
|
|
any news about launch?
Can't say about the launch of main net, but i'm definately going to relaunch testnet in next 2 days. |
|
|
|
.....
Thank you！
After updating boost1.58, there are new problems in the compilation.
What problems? Can you send logs? |
|
|
|
Linking C static library libz.a
make[3]: Leaving directory `/root/boolberry/build/release'
[ 26%] Built target zlibstatic
make[3]: Entering directory `/root/boolberry/build/release'
Scanning dependencies of target common
make[3]: Leaving directory `/root/boolberry/build/release'
make[3]: Entering directory `/root/boolberry/build/release'
[ 26%] Building CXX object src/CMakeFiles/common.dir/common/base58.cpp.o
In file included from /root/boolberry/contrib/epee/include/misc_log_ex.h:54:0,
from /root/boolberry/contrib/epee/include/include_base_utils.h:31,
from /root/boolberry/src/common/util.h:12,
from /root/boolberry/src/common/base58.cpp:14:
/root/boolberry/contrib/epee/include/os_defenitions.h:34:5: warning: "_WIN32" is not defined [-Wundef]
#if _WIN32 || _WIN64
^
/root/boolberry/contrib/epee/include/os_defenitions.h:34:15: warning: "_WIN64" is not defined [-Wundef]
#if _WIN32 || _WIN64
^
In file included from /root/boolberry/contrib/epee/include/misc_log_ex.h:63:0,
from /root/boolberry/contrib/epee/include/include_base_utils.h:31,
from /root/boolberry/src/common/util.h:12,
from /root/boolberry/src/common/base58.cpp:14:
/root/boolberry/contrib/epee/include/misc_os_dependent.h:114:35: fatal error: boost/core/demangle.hpp: No such file or directory
#include <boost/core/demangle.hpp>
^
compilation terminated.
make[3]: *** [src/CMakeFiles/common.dir/common/base58.cpp.o] Error 1
make[3]: Leaving directory `/root/boolberry/build/release'
make[2]: *** [src/CMakeFiles/common.dir/all] Error 2
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
root@iZhp3a3slnxeawyllt1n1zZ:~/boolberry#
V0.3.0.90 Compile error! The previous version can be compiled normally!
What boost version are you using? You probably have to install/build on fresh boost version. |
|
|
|
Hey, guys! While Zano mainnet is getting ready we keep improving Boolberry, and quite a few changes were made recently. Here I would like to highlight the most important of them for you: General: * log library was updated to the version which supports log channels (taken from Zano) * added anti-deadlock mechanism, which could track potential traps and save us a lot of time in case of multithreading problems * fixed a bug with possible http flood (thanks to anonimal for pointing to this) * implemented secure and compact Boolberry->Zano coinswap mechanism GUI: * we ported GUI library from old unsupported QT WebKit to stable and smooth QTWebEngine (special thanks to our contributor Alexandra (aldobryn on github) ) * added Unicode support for wallet file path, now it can easily be located in your favorite folder CLI wallet (simplewallet): * simplewallet was greatly improved to be able to work with modern exchanges: ** offline mode implemented for cold wallet support ** exchange API for cold-signing was reviewed and updated ** fixed a bug with incorrect coins handling for watch-only wallets * simplewallet got new commands: ** viewkey -- shows your view keypair ** spendkey -- shows your spend keypair ** recent_blocks -- prints income/outgo per-block summary for last N block containing your txs (it's useful, try it!) ** show_dust -- as you may expect shows how much dust (tiny unspent outputs) you have ** print_ki -- prints key image info * sweep_below command and RPC was improved to work better when lots of small outputs are present in the wallet Today we're releasing a new build: Boolberry 0.3.0.90 containing all these improvements: https://github.com/cryptozoidberg/boolberry/releases/tag/v0.3.0.90Thank you for your support and feedback! Boolberry team Thank you.  On your next build.. could you make the fonts bigger plz. thx  Sure, can you send exact screenshot and point which fonts you would like to see bigger ? And what platform you have(macos, linux, windows)? And what DPI/resolution? |
|
|
|
Hey, guys! While Zano mainnet is getting ready we keep improving Boolberry, and quite a few changes were made recently. Here I would like to highlight the most important of them for you: General: * log library was updated to the version which supports log channels (taken from Zano) * added anti-deadlock mechanism, which could track potential traps and save us a lot of time in case of multithreading problems * fixed a bug with possible http flood (thanks to anonimal for pointing to this) * implemented secure and compact Boolberry->Zano coinswap mechanism GUI: * we ported GUI library from old unsupported QT WebKit to stable and smooth QTWebEngine (special thanks to our contributor Alexandra (aldobryn on github) ) * added Unicode support for wallet file path, now it can easily be located in your favorite folder CLI wallet (simplewallet): * simplewallet was greatly improved to be able to work with modern exchanges: ** offline mode implemented for cold wallet support ** exchange API for cold-signing was reviewed and updated ** fixed a bug with incorrect coins handling for watch-only wallets * simplewallet got new commands: ** viewkey -- shows your view keypair ** spendkey -- shows your spend keypair ** recent_blocks -- prints income/outgo per-block summary for last N block containing your txs (it's useful, try it!) ** show_dust -- as you may expect shows how much dust (tiny unspent outputs) you have ** print_ki -- prints key image info * sweep_below command and RPC was improved to work better when lots of small outputs are present in the wallet Today we're releasing a new build: Boolberry 0.3.0.90 containing all these improvements: https://github.com/cryptozoidberg/boolberry/releases/tag/v0.3.0.90Thank you for your support and feedback! Boolberry team 👍🤘 |
|
|
|
Who is running 184.97.109.238? I really need to get logs from this machine!
Please owner contact me!
|
|
|
|
|
IMPORTANT NOTICE: Since our team is working on different projects(like pools, block explorers and so on) we renamed github account name from “zano-project” to “hyle-team”(hyle.io is company name), so you have to update all your local repositories links. Sorry for the inconvenience!
This is not related to Boolbery itself, only to zano-related projects.
|
|
|
|
How many repetitive coin project that we need?
Btw, my friend own zano.com domain name.
He hold this domain name for 1 big fintech project.
He and his group even reg trademark the "zano" name.
Hope it not gonna get conflict with this project.
Since you're both share similar name.
They already spend hundred of k to develop 1 fintech mobile application that they were ready to launch at any time.
I will show him this thread.
hundred k? not even sure what you wanted to say by this
IMPORTANT NOTICE: Since our team is working on different projects(like pools, block explorers and so on) we renamed github account name from “zano-project” to “hyle-team”(hyle.io is company name), so you have to update all your local repositories links. Sorry for the inconvenience!
|
|
|
|
For example, a miner with 50% hashrate mines only half of the expected mining reward. A miner with 90% of the total hashrate would mine only a tenth part of the normal expected mining reward. I believe it would dezentralize and stabilize the hashrate, but I cannot say, if it is technically solvable.
No, it's not technically solvable. You have the right idea, but you're touching upon the deep problem of forming a consensus which is the core of keeping cryptocurrencies out of central control. POW achieves this goal only if you're the largest coin for the type of equipment being used for the coin, so that miners are forced to not attack the coin so that their equipment remains profitable and worth something. Hashrate is automatically stable because they don't have something else to mine. In effect, the miner's equipment investment becomes their stake in the coin. If they attack, their stake loses value. Keeping the staked equipment / non-staked equipment ratio above 50% is the source of POW security which is how good POS systems works. There's no way to stop 51% of the miners from colluding to take value from the other 49%. So POS and POW work by making the miners put up a stake and have that stake at risk if they hurt the coin, so it does not matter if they collude because it does them no good. I'm working on a coin design to use this and other ideas. Most POW+POS are centralized instead of putting the stake at risk. Have the same opinion about "echnically solvable". zawy, thanks for your notes and examples, I've reviewed it and as you mentioned I have similar ideas in my mind. My concern about making shorter window and faster adjustment response by prioritizing very last blocks is that this can cause fluctuations of difficulty. I'll make next simulations experimenting with this and I think the final version will be some trade-off between fast adjustment and smooth difficulty line. And talking about PoW/PoS hybrids, what you think about Zano implementation?
..........
It calculated as combination of original adjustment functions for two different periods:
D = (D720(historical_data) + D200(historical_data))/2
Where:
- D720 - function which calculates difficulty based on 720 blocks window with 60 / 60 cuts
- D200 - function which calculates difficulty based on 200 blocks window with 5 / 5 cuts
..........
Re-ran simulation with this formula: D = (D720(historical_data) + D200(historical_data) + D40(historical_data))/3 Where: - D720 - function which calculates difficulty based on 720 blocks window with 60 / 60 cuts - D200 - function which calculates difficulty based on 200 blocks window with 5 / 5 cuts - D40 - function which calculates difficulty based on 40 blocks window with 1 / 1 cuts  Adjustment is faster now, but fluctuations now more noticeable, but not so bad |
|
|
|
Small instances should have an advantage, for example a miner with 50% of the hashrate has a disadvantage of 50%, a miner with 90% of all hashrate has a disadvantage of 90%, a miner with 1% of all hashpower has a disadvantage of 1%. Very small miners do not have any disadvantage in this case.
Can you clarify what you mean by "advantage" here? What I am doing is trying to protect relatively small miners, against big miners which can do these greedy mining policies. But actually it's not about big or small miners, it's about fast and stable adaptation to conditions I guess. |
|
|
|
Hi folks!
I've been doing some research on difficulty adjustments function and want to share results and ideas, analysis and critics are very welcome.
Motivation.
Some miners were doing one of the typical "greedy mining" strategies - abruptly raised hashrate, keep mining until difficulty get adjusted, and then dropped all hashrate, leaving a network stuck with one blocks/hour or even worse. For miners/pools this strategy is profitable because it let them get "cheap" blocks(mined with low difficulty), but this is definitely a problem for cryptocurrency - in such situation transactions confirmations takes hours, and other fair miners are quitting because mining on high difficulty is getting unprofitable.
I want to remind that at the early days Boolberry was suffered from this, and I've decided to take this historical data as "real-life" example for testing new difficulty adjustment.
Analysis.
1. Boolberry blocks history was reviewed and picked up a representative period, where hashrate was raised and dropped in this typical manner. Then, using difficulty associated with the blocks and their timestamps estimated hashrate was derived. Here what I've got:
That was a first week of June 2014, and as it seen on marked areas - there was a hard time for the network, blocks were coming once per hour and i had to ask loyal miners to make some blocks even though it was unprofitable. Ok, drama is over
Then, using this hashrate numbers associated with time became possible to calculate estimate blocks flow with timestamps and difficulty values progression, and this simulation had been run for bunch different variations of adjustment functions.
At this graph showed original cryptonote adjustment function(the blue one), couple variations with “adjustment window”, and currently preferred version(green one):
It calculated as combination of original adjustment functions for two different periods:
D = (D720(historical_data) + D200(historical_data))/2
Where:
- D720 - function which calculates difficulty based on 720 blocks window with 60 / 60 cuts
- D200 - function which calculates difficulty based on 200 blocks window with 5 / 5 cuts
Conclusions.
As seen on the curve this adjustment algorithm adaptation is definitely better by correction of D200, at the same time this still protected from timestamps manipulations due to the heavy influence of D720.
This function still a draft, we gonna make more simulations to check possible fluctuations, performance problems. Simulation is pretty naive, it doesn’t do absolutely realistic conditions, but it gives a pretty clear picture of adjustment function behaviour.
Would love to see some feedback&critics.
|
|
|
|
|
Show Posts
