4 votes for Bf4 (Foxpup, xmrpromotions, gotmilk_ languagehasmeaning) 1 vote for Ne1 (dre1982) 1 vote for Nf4 (jjacob) 1 vote for Rc1 (Hueristic)
|
|
|
... Currently the bears can still focus on the 0.8.8.6 "official" binaries with over 8 GB in RAM requirements. How long this will last remains to be seen.
I think you're over-estimating the effect on price that the next official binary release is likely to have. For better or worse (depends if one is accumulating or not, I suppose), I think the reality is that it's going to take an "official" GUI and/or more real services making use of XMR for there to be price movements that aren't mostly due to traders playing around. This may well be the case; however I find it very hard to believe that the market has ignored the fact that there have not been an update to the "official" binaries for well over 9 months. Edit 1: Here is an example of what I mean, from the main thread. Hello,
Seems that 8GB of memory is no more sufficent to load the blockchain on Windows... When i launch the bitmonero daemon, Windows says there's no more memory available for the process and kill it. I try to unload many things and boot windows very light, but same problem.
It's time to go to the db version ?
This is someone who posted and asked for help. The question in my mind is how many did not post and just "gave up". This kind of thing is bound to have an impact on the market. Edit 2: Windows Memory Limits http://www.ricksdailytips.com/windows-memory-limits/ Note; Windows 7 Home Basic with a limit of 8GB is actually fairly common. If I'm not mistaken, it doesn't really matter how much RAM you have in windows (say a VM). It will eat up your RAM if it is 4GB or 8GB. I believe smooth or fluffypony said this. But if I am wrong, please correct me. The next release will help with this issue. I am guessing about half of the bitcointalk community already has 8GB of RAM but I could be wrong. Of those who have less some will be willing to compile the db version now and some will not
|
|
|
All tied up now after I changed my vote. Someone needs to break the tie so our opponent can move.
3 votes Bf4 gotmilk_ ErisDiscordia newb4now
1 vote Qa3 Timelord2067
3 votes Rd2 boolberry dre1982 languagehasmeaning
The next voter should update the above with the corrected totals
|
|
|
http://coinmarketcap.com/currencies/dashcoin/Is the data here correct? To me it looks like the total supply is now correct and reflects the 10,000 to one supply reduction. Can someone confirm that all exchanges now have the updated client to reflect the correct supply? Is there somewhere else the community is more active? On IRC perhaps. Reddit seems pretty silent
|
|
|
Idk about that, I don't have the slightest idea of what I could do to help Monero personally since I'm pretty much technologically handicapped when it comes to cryptography. For the non-technical contributors, there are always things to do in terms of improving the web site, social media, creative marketing ideas, outreach to merchants, users, and opinion makers, etc. And also crowdfunding of various Monero-related projects which not only helps the projects but gives you a direct say in what projects get done. However, as a new arrival I'd suggest that you simply learn as much as you can first, then decide how you can help Monero succeed. I have made a thread here with more specific tasks (and potential deadlines) that people can add to and sign up for! Please check it out and contribute by adding new tasks, sign-up for tasks and debate/suggest other things. https://forum.getmonero.org/6/ideas/2395/task-list-to-do-listI like the to do list. I will try to think of things that I can add to and for the best way for me to help
|
|
|
We don't go and attack hit Queen. Much better is Rdc1. Just some more attacking on his pawn.
I am worried about Rdc1 Nb4 (attacking d3 and defending c5 with his rook on c8 at the same time) After Nb4 we could play pawn to d4. Lets trade some at the queenside. I am not happy everyone choose for Bf4. Black plays e5 and we have to move that bishop again. 19. Rdc1 Nb4 20. d4 c4 Is very bad for us. We will lose our e4 pawn by force with your suggestion. After we move our queen on move 21 black can play Nxe4. It should be noted that we do not have to play 20. d4 Like you I don't think 19. Bf4 is that great either. I just don't see any better options You are right that after 20. .. c4 we lose e4. What about Rd2? We make the field d1 free for our Queen. I can't see anything wrong with 19. Rd2 and might be convinced to change my vote. It comes down to whether or not we actually want to encourage our opponent to play e5 or not with 19. Bf4. Either move seems acceptable. Anyone have any good long term plans our opponent cannot easily parry? It seems like we are mostly on the defense now just trying to keep the material balance.
|
|
|
Basically: as slow and dismal as things seem now, it's going to slowly do a 180 and rock the world of cryptocurrency with an anti-crash that the world will most *definitely* notice.
Most wont know what's hit them. This is going to be a kind of change that the world has never actually experienced before. The last few days have been a great time to accumulate more coins at attractive prices. Development seems to be coming along well and coin emission keeps slowing. The new dice game, GitHub documentation and rumors of a new service for BTC > XMR trades with a minimum mixin are exciting ShapeShift started to use mixin and had to stop due to problems.
Coming soon there will be a service that allows BTC -> XMR transfers supporting mixins 3+ by default and payment IDs. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
Would a Monero fork designed with mobile users in mind, be a fair assessment?
Developed is a better word than designed, but yes I would agree with that description. I know you have multiple ideas, but focusing on usability for mobile users is one of the things that interests me most about Aeon.
|
|
|
LOL at how many times I've been quoted on the first page (not counting language in the OP). Anyway, it seems the information I posted has been of value.
Best of luck with the new thread. I will watch and answer questions when I have something to add (might even ask a few).
I think it is fair to say that you are quoted a lot because people respect you as a developer of both Monero and Aeon.
|
|
|
We don't go and attack hit Queen. Much better is Rdc1. Just some more attacking on his pawn.
I am worried about Rdc1 Nb4 (attacking d3 and defending c5 with his rook on c8 at the same time) After Nb4 we could play pawn to d4. Lets trade some at the queenside. I am not happy everyone choose for Bf4. Black plays e5 and we have to move that bishop again. 19. Rdc1 Nb4 20. d4 c4 Is very bad for us. We will lose our e4 pawn by force with your suggestion. After we move our queen on move 21 black can play Nxe4. It should be noted that we do not have to play 20. d4 Like you I don't think 19. Bf4 is that great either. I just don't see any better options
|
|
|
I just replied to a few questions in the new speculation thread and linked some good resources
|
|
|
I've been gone for a long time - is Boolberry still part of Supernet?
Crypto Zoidberg did the work a long time ago on the Boolberry end. We are waiting for SuperNet to integrate it: Maybe we should speculate on the importance of SuperNet to Boolberry. How much do you think it matters?
|
|
|
bbr, just like xmr, is also cryptonote. Thus, I wonder, what are technical differences between bbr and xmr?
You are right that they have a lot in common. Here are a few of the biggest technical differences: 1. Working, Official GUI http://boolberry.com/downloads.htmlMonero currently has several unofficial GUI's and a web wallet 2. Minimum mixin# solution (already implemented): http://boolberry.com/files/Boolberry_Solves_CryptoNote_Flaws.pdfMonero has its own plans for how to address this issue: https://lab.getmonero.org/pubs/MRL-0004.pdf![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi59.tinypic.com%2F2z5222t.jpg&t=663&c=bum_92W_M83YYw) 3. Blockchain bloat solution (already implemented): http://boolberry.org/files/Boolberry_Reduces_Blockchain_Bloat.pdf![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi59.tinypic.com%2Frqz11u.png&t=663&c=FxKaYTyNyxI19w) 4. Emission Schedule: Slower than Monero ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fboolberry.com%2Ffiles%2Femission.png&t=663&c=jH2usehhXX5BgA) 5. Similar to Monero, Boolberry is currently testing new db code: https://github.com/cryptozoidberg/Boolberry/tree/dbfeedback from smooth and crypto 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) 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.
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
|
|
|
Edited the totals to reflect my vote:
3 votes Bf4 gotmilk_ ErisDiscordia languagehasmeaning
1 vote Qa3 Timelord2067
1 vote Rdc1 dre1982
1 vote Rd2 boolberry
The next voter should update the above with the corrected totals
|
|
|
Now it is time for Team Boolberry to respond. Votes will be counted at 0:00 UTC tomorrow.
Since I was 2 hours late with the count Team Boolberry only gets 22 hours to reply this time. I doubt anyone will object based on how early we are in the game. Based on the rules in the OP if votes are counted well after 0:00 UTC technically the other team should be getting another day to respond. As the position becomes more complicated and in cases when I fail to count votes on time either team can claim this extra time if it wishes. Most days I expect to be able to count votes reasonably close to 0:00 UTC.
Definitely no need for a time extension on this move I vote cxd4 and will be shocked if the move does not capture most or all of the votes
|
|
|
One problem we have right now is that our rook on a1 is stuck defending a5. If we could move twice in a row Qa2 and Rac1 might make sense. However after we play Qa2 he can play Nb4 attacking our d3 pawn and after Qb1 to defend it our rook is still caught in the corner!
I am trying to figure out why he played h6. Ng5 and Bg5 for us did not seem like anything special to me.
I have no move suggestions yet but give me some more time to think.
I expect our opponent to move Nh5 and Bh4 in that order in the not too distant future. We have a knight on f3 and a pawn on g3. Why would you possibly expect him to play Bh4 anytime soon?
|
|
|
I like 19. Rd2. We have to move our queen and then he can take on d3 next move.
Unless we move the queen straight back to b3, defending the pawn. Still, trading a knight for two pawns isn't the best idea ever (especially when one of the pawns is a rook's pawn). You are right! For a moment in my head I forgot the c3 knight was no longer there in that line (it would obviously block a b3 queen from defending d3 if it was). I must be tired. It still sounds like we agree on Nxb5 not being the best option. 19. Rd2 looks reasonable. I will think more about it later.
|
|
|
|