The clarification is much appreciated. My understanding is that BBR ring sig pruning linearly reduces blockchain bloat, but is not the holy grail of transaction pruning required for logarithmic bloat reduction of the kind found in XCN's mini-blockchain. To be clear, ring sig pruning prevents a little bit of bloat, while transaction pruning removes substantial accumulated bloat. Also, 'dust' is the atomic unit of 'bloat.' Did I get that right? What do I win?  Spot on. Linear reductions are easy. Logarithmic are significantly harder. For your efforts you get a whale. In CryptoNote coins ring signature is 60-90% of transaction size. With pruning ring signatures you get 60-90% smaller blockchain, compared with other cryptonote coins, you win only this here.
Yes, that is a correct example of linear. You get a whale too! PS. In your next botnet / cryptocurrency / library project please do Star Wars references, they're a great deal more palatable than the Futurama references. And then that way you can say "I love you" and I can say "I know"  You angry and blind. You trying to insult me, just because you have nothing to say in substance. I have my own reasons of being anonymous, and people who i work with know exactly why, and this have no relations with your fantasy about botnets. Sorry for off-topic. |
|
|
|
Now when the Networkhashrate is lower, i want to mine solo again.
The problem is that the hashrate from daemon is more that 2 times lower than the hashrate from the minerd on my computer.
CZ why it is such a big different?
I guess because Otila and Wolf made a lot of optimizations on minerd that i was not merged yet into daemon. Are you going to mine CPU or GPU ? |
|
|
|
Which pool has biggest hashrate???
I've answered you in the chanel - use clintar's cncoin.farm. |
|
|
|
chainradar seems to be the best explorer for all CN coins right now.
The monero explorer is not actually working. It is out of sync. The ChainRadar explorer is working for both coins. The CryptoStats author is rarely online. Thanks. I wasn't aware of chainradar until now. On another note, just installed the latest BBR wallet for OSX. tested on yosemite, mavericks, and mountain lion. One-click install process. All working smoothly. Very intuitive UI, and the alias auto-completion is a nice touch. Monero wallet by comparison is a headache to setup. By default seems to spit out errors on the terminal. It mostly Bitcrea merit - he has clear vision that things must be easy and nice. And still we have a lot of work to do on GUI(and not only). |
|
|
|
Sorry - I've updated my original post to more correctly note the second presentation is about ring signature pruning, not blockchain pruning, as was discussed at length earlier in this thread. Mea culpa for the uncareful phrasing.  The clarification is much appreciated. My understanding is that BBR ring sig pruning linearly reduces blockchain bloat, but is not the holy grail of transaction pruning required for logarithmic bloat reduction of the kind found in XCN's mini-blockchain. To be clear, ring sig pruning prevents a little bit of bloat, while transaction pruning removes substantial accumulated bloat. Also, 'dust' is the atomic unit of 'bloat.' Did I get that right? What do I win? In CryptoNote coins ring signature is 60-90% of transaction size. With pruning ring signatures you get 60-90% smaller blockchain, compared with other cryptonote coins, you win only this here. XCN is very interesting project, unfortunately i can't see possibility to build account tree on CryptoNote base(as well as utxo) due to anonymity/unlinkability. |
|
|
|
The pool I setup from the repository send updates in less then 100ms but it looks there is other bug anyway. Shares submitted right after the block/scratchpad update are rejected by the test pool. The pool_warn.log is: Bad hash from miner XXX@10.0.2.2
scratchpadHeight.height=63856, job.height=63858
Looks like the pool validates the share with the old scratchpad. P.S. Checked the source - that's the case. Pool's scratchpad is updated through getFullScratchpad RPC call. It takes 3 seconds on my system. At the same time miner's scratchpad updated instantly by ADDENDUM in new block data. So valid shares are rejected by the pool if sent in less then 3 seconds after the new block. Any idea how to fix this in the pool source? Need to implement the same incremental pool's scratchpad update as it used by minerd, via addendums. Or, as other workaround - export scratchpad via file on disk, but it still workaround. Normally need to implement addendums reading. |
|
|
|
Yeah, perfect emission curve should track adoption, but this seems to be impossible in real world.
After all, even if bitcoin emission curve is not perfectly "fair", and not exactly track adoption, it is still more fair than faster emission models, isn't it?
For what it is, if Bitcoin's curve were faster, it would probably be worse. That is, Bitcoin being the first and not understood or recognized as valuable at all for quite a while. It took almost 2 years just to get to the 10,000 BTC = 1 pizza stage. By that time it was already about 20% mined which definitely seems kind of silly. Today, new coins obviously get at least some adoption a lot faster than Bitcoin did. I don't know if this means that faster-than-Bitcoin curves are better for new coins. Maybe they should all be a lot slower. XCN might be on to something with their 10-year half life. Or maybe something like Bitcoin's curve is just right for a coin like XMR or BBR. Or maybe Bitcoins curve is right for Bitcoin and new coins should be faster. Or maybe the idea of any fixed curve set in stone from the start is really not the best way to go at all. (But then if not, what should replace it?) There is a lot we don't know about how these coins work, or even if they can work at all long term. Hard to to disagree with that. |
|
|
|
I guess in global view, comapred to XMR we have more honest distribution, at least because we have more fair emission curve:
I'm not sure why one curve would be any more fair than the other. Does XCN have a more fair emission curve because it has a 10-year half life? Would 20-years be even better? To me "fair" means that the rules are clearly defined and those same rules apply to everyone. Different emissions curves might have practical advantages and disadvantages, but fairness is not among them. I agree about clearly defined rules, it's definately an indispensable part of fair distribution. But also i think that faster emission makes less interest for late joining the currency - in long term view, so i think Bitcoin emission curve is closer to be fair. Closer perhaps but it is still quite easy to argue that it is "unfair" if this is your definition of unfair. Bitcoin is about 75% mined and most people on the planet have no idea it even exists. Even most people in developed countries with good access to information and access to computers have barely heard of it if at all. Now I don't happen to think that is "unfair" as I said earlier, but if your definition of fairness includes wide access to large amounts of newly issued coins to late adopters the Bitcoin's curve is also grossly unfair. The thing is, you can't really know this in advance. When Bitcoin was created, nobody had any idea if it would ever be remotely successful or how long it would take. Likewise for newer cryptocurrencies. So if you are using the model of a fixed curve defined in advance and trying to make this curve track adoption (even in some loose sense )you almost can't help but miss the mark. And as you said, there are also practical advantages and disadvantages. But let this out of scope, say you launching new coin at this moment, what emission curve would you select for this ?
I don't know. There are all sorts of considerations, and I'm sure you have considered many of them. From a strategic point of view I might try something that is deliberately outside of the range already crowded with existing coins. I give the XCN guys credit for thinking a bit outside the box and trying that. Yeah, perfect emission curve should track adoption, but this seems to be impossible in real world. After all, even if bitcoin emission curve is not perfectly "fair", and not exactly track adoption, it is still more fair than faster emission models, isn't it? Anyway, i don't want to flame - i've got your opinion, and it's reasonable, i'm personally stay with my point of view on this. Agree about XCN, interesting project. |
|
|
|
I guess in global view, comapred to XMR we have more honest distribution, at least because we have more fair emission curve:
I'm not sure why one curve would be any more fair than the other. Does XCN have a more fair emission curve because it has a 10-year half life? Would 20-years be even better? To me "fair" means that the rules are clearly defined and those same rules apply to everyone. Different emissions curves might have practical advantages and disadvantages, but fairness is not among them. I agree about clearly defined rules, it's definately an indispensable part of fair distribution. But also i think that faster emission makes less interest for late joining the currency - in long term view, so i think Bitcoin emission curve is closer to be fair. And as you said, there are also practical advantages and disadvantages. But let this out of scope, say you launching new coin at this moment, what emission curve would you select for this ? |
|
|
|
I think the name is not the key point, the point is the mining issues, it kills this coin, in the early time, there's private GPU tool for mining when most of us are using cpu, it's unfair for most people, and it last for maybe two months, until MBK made the stratum pool and updated the opensource GPU tool the situation of distribution changed a little. Compared to Monero, GPU mining tool appeared early, and it was also efficient at the beginning, so it's not just the name make the difference between BBR and MRO, but the distribution
I guess in global view, comapred to XMR we have more honest distribution, at least because we have more fair emission curve:  And Monero also have issues with unfair distribution(but this is not current developers fault), due to hash optimizations, someone mined bitmonero in first days with about 10x times faster implementation(correct me if i wrong with numbers), read this dga post. |
|
|
|
I'll keep CLI working, sure. Also i could add recent transfer to cli wallet also, it's not really difficult now, if it make sense.
great to read, more functionality on the cli wallet is always welcome I think the name is not the key point, the point is the mining issues, it kills this coin, in the early time, there's private GPU tool for mining when most of us are using cpu, it's unfair for most people, and it last for maybe two months, until MBK made the stratum pool and updated the opensource GPU tool the situation of distribution changed a little. Compared to Monero, GPU mining tool appeared early, and it was also efficient at the beginning, so it's not just the name make the difference between BBR and MRO, but the distribution
I totally agree that mining is a bigger issue than the name, most people thinking just changing the name will help are not considering what a private gpu miner dumping all his thousands coins per day is doing to bbr value. There are no private GPU miner anymore, Wolf's open source GPU miner is much faster than cbuchners's. It's just a fact. |
|
|
|
I'll keep CLI working, sure. Also i could add recent transfer to cli wallet also, it's not really difficult now, if it make sense. I really like the GUI improvements but I hope the CLI is not forsaken for us small minority that prefer command line.. Latest wallet additions are Booltiful ! Keep up the good work.  Don't get too attached to the name BitcoinFX lol this eager, crypto_zoidberg your people want a new name  |
|
|
|
Good news!We have new release 0.2.0.32(b91e9ab) with some improvements, mostly on GUI:1. Implemented recent transfers history. Now after reopening your wallet you see your recent transfers, even with addresses that you used to transfer (or alias if address was registered).  Notice: This will start work from new build only, transfers that was made in older GUI version won't be seen. Also, if you gonna lost your wallet data file (some_wallet.bbr) recent transfers recipient addresses will be lost. 2. Implemented unconfirmed transaction state. Now, when you sent your transaction, you could see it as "unconfirmed" in recent transfers list:  Even is you close your wallet, and reopen it again, unconfirmed transfer won't be lost - so now you cold track your transaction confirmation. Also made a lot of cosmetic improvement on appearance based on Bitcrea design adjustments. Wellcome to try new version: http://boolberry.com/downloads.html
|
|
|
|
Seems that it's Monero building cult around Zoiberg |
|
|
|
Thanks for kind words. ......
BBR's innovations and changes, while untested by time and success, are more than cosmetic. Removing dust and the resulting bloat is a big step. Aliases are nice to have available. Two minute blocks may be a better choice than one minute. Wild Keccak may prove more ASIC resistant than Cryptonight. BBR was first with a GUI wallet as well.
......
I just want to mention, from my point of view most important, major core changes in BBR is: 1. Advanced transaction identification --> precisely this option allow BBR to have n-times smaller recent blockchain compared to monery/bytecoin (assuming the same transactions amount) 2. Transactions with guaranteed anonymity --> this option solve CryptoNote issue and will allow BBR to have subset of transactions with completely guaranteed unlinkability of transactions. 3. New different approach to PoW to solve problem of slow hash/slow synchronization and improve ASIC protection. Removing dust, aliases, signed alerts - i could name it "minor changes" (but still it is not cosmetic as monero propagandists try to show it). Even each of this feature have concreate purpose (dust removed since it make smaller bc, alerts needed for fast notification in case of critical problems, aliases - for aliases, and basement for colored coins) What i want to say - could be different view on solving these problems, different solutions - for example smooth mentioned that they aware about 2. problem and working on some different approach. And if they get better solution i would be happy to use it. But calling these changes "cosmetic" shows complete misunderstanding of CryptoNote technology and ideas. |
|
|
|
When I was choosing between the two, I personally felt that both the block interval and coin generation schedule were better in BBR. But unfortunately all the other things were worse, with legitimacy on the top of the list.
Why only pick one, and not both? Since CryptoNote is very new, both coins have a chance to be the sector leader. BBR may get stuck being Pepsi to XMR's Coke, or become the dominant CN coin if there is an XMR catastrophe. Those are both winning outcomes. BBR may be the next BetaMax (better tech killed by QWERTY effect) but that's why I only spent 10% as much on them. But BBR isn't even the next BetaMax, what the hell are you talking about? This is so frustrating! BBR's changes are only to make it separate from monero and to build a cult around zoidberg. BBR's changes are questionable at best, this is Litecoin all over again, the fact that people can't see this just shows how many idiots are in Crypto! I get it, I used to be one of those idiots, and I lost a lot for it, but I feel that I am different now, losing hundreds of Bitcoin changes you, makes you research well and apply logic. I've saw many sad things said about my work, but this is the first time i was blamed in building cult |
|
|
|
I think that XMR should change its algorithm.
My XMR blockchain was 6 days behind the network: 8600 blocks unsync-ed. It took me 40 minutes sync-ing the blockchain from 1h33 - 2h25 PM
That's a hash rate of 4/sec. Doubtful the PoW algorithm had much to do with this. What device is it? PoW is not the only difference between BBR and XMR. Another is many more transactions on XMR. Or you may simply have been connected to slower peers. Same laptop: Dell Inspiron 15 - Intel Core i5 - 4200U 1.6 Ghz - 6 GB RAM. XMR is always much slower than BBR on my laptop. I open XMR wallet more often than BBR one: every day or every 3-4 days. XMR daemon is slow all the time. It is strange that BBR can sync the blockchain much much faster than XMR I have an idea. It might be frequency scaling. You will get poor performance with the quick bursts of CPU activity of verification but not mining. If this proves to be true we can probably at least optionally bypass scaling during resyncs. I'm interested in both the log data cryptozeidberg asked for as well as single thread mining speed. Agree, also was thinking about this, that's why i asked for logs from blockchain storage, also it shows both time intervals - whole block processing time, and PoW calcalation time, so we could see how much time is spended for Pow and and how much transactions. |
|
|
|
If you really respect my work, bother to explain and prove that Wild Keccak is broken. Have you found the way to hack it ?
Because if haven't - it's just a lie, once again.
"once again" - are you implying that I've lied about BBR before? You'd do well to think through your words before writing. It wasn't addressed personally to you, sorry if it sounds like it was, but i've saw many times when from Monero team was said wrong or confusing things about BBR. |
|
|
|
Another difference is block interval - Monero have twice more blocks per day.
When I was choosing between the two, I personally felt that both the block interval and coin generation schedule were better in BBR. But unfortunately all the other things were worse, with legitimacy on the top of the list. I expect that answer will be criticize - nevertheless i would like to ask what you mean by "legitimacy" ? and by "other things" ? I realize that you already chosen Monero and invested in it - so i'm just interested to know investor's vision, and may be to learn my own errors. |
|
|
|
|
Show Posts
