Hi Folk!
Just want to notice everyone, as soon as you install third-party builds of BBR you taking not only a risk of getting unstable/broken build, u also take a risk of getting spyware/malware which can steal money (BBRs, Bitcoins, whatever u use), it's all based on trust of developer.
My strong advice - be very careful with all that you install basically, at least use virtual machines (like vmvare, paralells, virtual box) for this things.
Or, build it from sources yourself.
Zoidberg.
nice to see you a bit around Zoid  get back on irc! missing you ;-) No IRC this time, too much work guys! But i'm here, around! CZ, do you understand that if you started contributing to the project the market cap could go an easy 20x from here? I'm not sure what work you're involved in that is "too much" but I doubt any will pay you as well as contributing to BBR It sounds like your work is BBR related My work is related to BBR codebase, which means that everything i do now gonna be migrated to BBR. |
|
|
|
Hi Folk!
Just want to notice everyone, as soon as you install third-party builds of BBR you taking not only a risk of getting unstable/broken build, u also take a risk of getting spyware/malware which can steal money (BBRs, Bitcoins, whatever u use), it's all based on trust of developer.
My strong advice - be very careful with all that you install basically, at least use virtual machines (like vmvare, paralells, virtual box) for this things.
Or, build it from sources yourself.
Zoidberg.
nice to see you a bit around Zoid get back on irc! missing you ;-) No IRC this time, too much work guys! But i'm here, around! |
|
|
|
|
Hi Folk!
Just want to notice everyone, as soon as you install third-party builds of BBR you taking not only a risk of getting unstable/broken build, u also take a risk of getting spyware/malware which can steal money (BBRs, Bitcoins, whatever u use), it's all based on trust of developer.
My strong advice - be very careful with all that you install basically, at least use virtual machines (like vmvare, paralells, virtual box) for this things.
Or, build it from sources yourself.
Zoidberg.
|
|
|
|
....
Thanks for your work. Let's continue moving this way. Make commits to your repository so I and everybody else can review them. The most urgent task for me is to merge DB branch from the original repository to master. Daemon needs a lot of memory to run right now. That's not good for a decentralized system. I would prefer you to checkout DB branch and commit on top to make the review process simpler.
DB is really important task, and idea was to quickly implement basic db support in BBR using level_db, but to go forward problem is that level_db doesn't have transactions support, so we need to go with something like LMDB, which means to rewrite current code in db branch. I guess this gonna take about 1 month of hard work. (but not a hard fork! don't be confused) So if 1blockologist is about to implement something useful for BBR - implement working daemon with suitable memory consumption using LMDB would be good move. Zoidberg |
|
|
|
|
Hi folk.
FYI: i've been contacted by 1blockologist user in the skype, he claim that he want to develop BBR.
At the moment i have no idea who is that person and what he intend to do actually.
Let's see if his work gonna be helpful.
Zoidberg.
|
|
|
|
|
Hey there folk!
How's it going ?
Zoidberg
|
|
|
|
|
Hey folk!
I was talking with windjc, since at the moment i don't have time to do fulltime development, we may be need to rise some funds and hire dev for most critical tasks.
The primary tasks is to put DB into the code, and implement "dark mode" for wallet.
But db is really critical.
I can help a bit with development, but still need experienced full time C++ dev for a 2 months at least i guess.
Zoidberg
|
|
|
|
|
Seed nodes are up.
Zoidberg.
|
|
|
|
Hi Folk! Sorry for being away all this time, was really busy with preparing public betta of our second project. I've reconfigured first seed node and in process of re-configuring others nodes. http://boolberry.com/state.html is up again. Zoidberg |
|
|
|
Hi Folk!
Still have no idea, why u think need this tail emission ?
Can someone give clear and short explain of the problem?
Historically, PoW-based cryptocurrencies utilize inflation to subsidize the mining efforts that secure their blockchain. Towards the end of a cryptocurrency's emission curve (or inflation stage), it is unclear whether transaction fees will be able to effectively secure the cryptocurrency. If there is not enough incentive to mine the cryptocurrency, then miners will move on and mine other cryptocurrencies which leaves the cryptocurrency vulnerable to 51% attacks. Several cryptocurrencies with expedited emission curves, and a finite amount of money supply, have suffered from 51% attacks due to this issue (Quarkcoin to name one.) A "tail emission" is intended to combat this issue by providing incentive for miners to continue mining the cryptocurrency indefinitely. Without a "tail emission", a cryptocurrency would need to increase greatly in value and transactions per second to be able to afford sufficient protection from 51% attacks. Not having a tail emission, or another solution in place, is effectively making an "all or nothing" bet in which the cryptocurrency will end up a huge success or worthless. I would liken a "tail emission" to a "safety net", in case your PoW-base cryptocurrency falls somewhere in-between a huge success and worthless (which, in my opinion, is a likely outcome for Boolberry.) CoinHoarder, thank u for clarifying it. It make sense, especially for cc with fast emission curve. For now i think we have more important technical things to do, but this could be an option in future. As or me emission curve is very important part of cc, and now i thing it's not fair that biggest reward comes in first blocks when nobody knows what this coin about. It would be more interesting to have small reward in the beginning, then after some time - valuable reward, and then the rest of emission could be linear... something like tail emission that CoinHoarder mentioned. Zoidberg |
|
|
|
|
Hi Folk!
Still have no idea, why u think need this tail emission ?
Can someone give clear and short explain of the problem?
|
|
|
|
I'm here, no worries. Btw, i was told that Wolf complained about me on #monero chanel, well, just to put light on it, if someone interested what happend: We were looking for someone to make x11 GPU miner, both for OpenCL and CUDA, as he is well known as a good developer for such things, i offered him to do that. Here was my offer: We finally need code for both platforms(Linux&Windows) OpenCL and CUDA implementations.
It could be not perfect implementations, but it should work fine with Clintar's pool.
Ready pay 600$ for everything, including testing on pool and easy HOWTO use/build.
Zoidberg
And here is his answer: Very well. My GitHub name is wolf9466. The current Bitstamp BTC price is $227.88; I'll round up to $228. Send half to me to start, half on completion. If the BTC price changes by more than 15%, up OR down, the remaining payment is to be re-negotiated.
He was prepaid with $487 out of the $600(even more then he asked) and the deal was to have finally done both opencl and cuda miners. Since for Opencl there was not much work there(cz it was already public implementation of it), so i’ve made a deal with him to make both miners working, even without optimizations. That talk happend at 1-st of September! He hang us for more then 2 months and finaly said then he is not going to make CUDA, i have to hire some one else. Well, then i asked him to return money, since he failed to finish contract in my opinion, despite the fact that he adapt opencl version to cryptonote block size (Mostly i wanted to return money because of wasted a lot of our time actually) All our communication made in bitcointalk pm, so it's could be validated by sysadmins if someones cares. You can say that i'm wrong in some way, but according to my standarts if you applied for job and got prepayment, and then gave up - you should return prepayment, and also say "sorry for your lost time" to your employer, in case there was no other conditions. Zoidberg. |
|
|
|
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)
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.
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
|
|
|
|
|
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!
|
|
|
|
|
Hey folk!
We are looking for someone who can work out X11 GPU miner (both OpenCL and Cuda).
Need to make changes in block size (adapt for cryptonote-family block) and test it with server pool software.
We pay in Bitcoins.
Let me know if someone is familiar with this code and ready to sort out things for us.
Zoidberg.
|
|
|
|
|
Hey folk!
We are looking for someone who can work out X11 GPU miner (both OpenCL and Cuda).
Need to make changes in block size (adapt for cryptonote-family block) and test it with server pool software.
We pay in Bitcoins.
Let me know if someone is familiar with this code and ready to sort out things for us.
Zoidberg.
|
|
|
|
I downloaded the wallet and it syncs very fast. I have heard that CryptoNote has a large blockchain. How is this possible? Is it a SPV wallet?
If so what are the advantages/disadvantages?
2 times less blocks in blockchain at least. Zoidberg |
|
|
|
Is there any chance Louis'or ends up in SuperNET? if bbr is part of SN, why not Louis'or?
Technically there is no problems at all, we already have code for "telepods" Zoidberg |
|
|
|
Hello everybody! Here is the draft of emission curve for "Lui" project:  Script with formulas: http://jsfiddle.net/dubqvwje/In first 3.5 year will be emitted significant part of money, and then, after this period of 3.5 year emission will be about 0%-2% of whole money per year. First 4 months will be only PoW blocks(1 block per 4 minutes), and then started PoS bocks (at height > 60000), PoS blocks have also target time 1 block per 4 minutes, so summary will be 1 block in 2 minutes(avrg). 100 000 000 coins reserved for project support ("premine"). Public betta is coming soon! Zoidberg&Co |
|
|
|
My pool bbr.mbkpool.info had problems with payments lately. It was due to wallet getting out of sync like many times before. All miner payments for last few days have been sent. I rescheduled the wallet restart script to prevent such problems in the future.
Just noticed - cncoin.farm has 97% of total hash rate. It's a reliable pool but it doesn't look good for the coin. Please, use solo miner or some other pool if you can.
Hey, here's a git diff that fixes that if it's that the wallet seems to stop checking for updates. diff --git a/src/wallet/wallet2.cpp b/src/wallet/wallet2.cpp
index a525a86..c8d7ee4 100644
--- a/src/wallet/wallet2.cpp
+++ b/src/wallet/wallet2.cpp
@@ -436,10 +436,11 @@ void wallet2::refresh(size_t & blocks_fetched, bool& received_money)
catch (const std::exception&)
{
blocks_fetched += added_blocks;
- if(try_count < 3)
+ if(try_count < 3000)
{
LOG_PRINT_L1("Another try pull_blocks (try_count=" << try_count << ")...");
++try_count;
+ sleep(60);
}
else
{ I believe that came from Onishin in #monero-pools when he posted it there about monero's wallet doing that a while ago. Haven't had to restart because of this issue since doing this. Now not being able to make a payment because of dust and transaction being too large bites me all the time. This is not perfect solution, since wallet2 class used in differen components, and this approach could broke or frees GUI for example. Just commited more correct solution that should work for pools as well. (The real problem was cz throwing exception that killed RPC server thread) Thanks to Clintar to point to this problem Zoidberg |
|
|
|
|
Show Posts
