So whaddaya'all think, a blue chip like NEOBEE, or not quite?
Having been in communication with these guys a bit I can say that they are definitely not NEO & BEE types. These guys definitely know what they are doing and they have proven that they can deliver since they have already done so. Unlike many offerings, their technical skills and abilities are pretty well proven. The hard part will be execution and scaling the business. It's great to see experts bringing innovation to market that all miners will have access to. I am cautiously optimistic, and look forward to watching this come together. Let's not confuse "technical ability" with "ability to successfully operate a business that is Bitcoin-profitable" or even "ability to not realise you have many millions of Dollars worth of Bitcoin in a 150kb file and could disappear without a trace". I like where this offering is going, but the 1 page "business strategy" is worthless. Given how reliant this company is on paying backend costs in fiat, they would need to present a great deal of business acumen coupled with a really solid and detailed strategy to demonstrate a glimmer of hope that investing in this will be more profitable than just holding your Bitcoin over the same period. Additionally, don't confuse the possibility of them being fiat profitable with them being Bitcoin profitable - the chance of the former may be very high indeed, but just like very nearly every mining operation that has ever existed, the chance of the latter is slim to none. There's also minimal information as to who the operators are and whether they have a credible and long-standing WoT presence (far from infallible, but at least a step in the right direction). Why is this important? Well, for one thing, shutting down a business is trivial, abandoning it doubly so. Being an identifiable and amicable person means nothing (see: Neo&Bee). Having a registered business means nothing (see: AMC/VMC and many others). Trust is a product of provable engagements over time, coupled with an ongoing demonstration of business acumen by the operator(s) (which could be done, for example, by said operator(s) being involved in discussions of other businesses, and by providing advice and/or criticism they demonstrate that they at least have the knowledge to do better). Thus far there is little evidence of either of that here. I'm certainly not calling this a scam, but I am saying that the counterparty risk is massive and disproportional, and there is little evidence that this will make you more Bitcoin than you invest (although it may very well end up being fiat profitable). |
|
|
|
I need some help!
I can't download the Linux wallet from the Monero website. The download stops after a few seconds. Does anybody else have this problem?
Works fine here:
--2014-06-17 16:18:40-- http://monero.cc/downloads/monero.linux.x64.latest.tar.bz2
Resolving monero.cc (monero.cc)... 162.159.240.211, 198.41.249.210
Connecting to monero.cc (monero.cc)|162.159.240.211|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38778176 (37M) [application/octet-stream]
Saving to: `monero.linux.x64.latest.tar.bz2'
100%[============================================================>] 38 778 176 2,95M/s in 15s
2014-06-17 16:18:58 (2,41 MB/s) - `monero.linux.x64.latest.tar.bz2' saved [38778176/38778176]
|
|
|
|
I'd like to open a debate. Xeon Phi.
What do you think of Xeon Phi performance-wise? Do you see them being adopted by professionnel miners, or even not-so-casual miners? Why? How? Which consequences on price, distribution...
As an added question: will Monero become successfull enough to generate an interest in FPGA? How would FPGA compete with Xeon Phi (or AMD competitor)?
kiyominer already ported cpuminer to the Xeon Phi (sha256 only) and performance wasn't mind-blowing for the cost. I think the Phi has its uses, but not for mining. |
|
|
|
Getting a strange error, hope someone can chime in   Started happening after upgrading to the new wallet version *Win 8 64 DDOS thing made that disappear quick...anyone? Just a bug in the program from compiling. A guy named Tom compiled it, guessing you're using one of the binaries? It's nothing to worry about. If it bugs you, restart the daemon and it might make it appear a little less often. His problem is that it isn't starting:) ivanlabrie - delete your p2pstate.bin file, I believe on Windows it is in %AppData%/bitmonero |
|
|
|
holly shit,
the XMR deamon is totally memory leak, that why when it start, my computer are about to freezing...
Note that this deamon has just started 30 minutes
As Keyboard-Mash pointed out, no memory leak, that's by design (loading the entire blockchain into RAM). We are gradually working on an embedded database version that will solve this. |
|
|
|
So I sent 1 XMR from my wallet to poloniex two days ago, and it has not shown up.
I sent 5.25 XMR to Bittrex 14 June, and also don`t see it on my balance  used transfer 0 ... command Are either of you guys using a GUI wallet? I have a sneaky suspicion that some of the GUI wallets are not enforcing the minimum fees, and transactions are thus never getting mined. |
|
|
|
I've been searching and can't find a solution here. Anyone have any idea as to why upon synching I get the below errors? In particular, why is there "ric" after the /Users/ directory? I'm on a Mac and that is not my user name, so the /Users/ric directory does not exist. (I've removed the wallet.bin file and restarted everything, new seed and all generated, but this didn't seem to help.) I started by double clicking on bitmonerod and then once synched, simplewallet, which were downloaded from Github. (I was unable to install via the command line instructions.) Thanks IAS 2014-Jun-15 14:54:28.481185 [P2P8][sock 22] Some problems at write: Broken pipe:32
2014-Jun-15 14:55:35.798590 [P2P3][87.246.145.171:18080 OUT] SYNCHRONIZED OK
2014-Jun-15 14:55:37.316479 [P2P4][134.249.161.21:18080 OUT] SYNCHRONIZED OK
2014-Jun-15 14:55:37.389800 [P2P3][113.190.13.120:18080 OUT] SYNCHRONIZED OK
2014-Jun-15 14:55:37.459267 [P2P3][86.25.118.21:18080 OUT] SYNCHRONIZED OK
2014-Jun-15 14:55:40.417736 [P2P4][101.164.234.118:18080 OUT] SYNCHRONIZED OK
2014-Jun-15 14:55:43.603074 [P2P6][184.190.220.14:18080 OUT] SYNCHRONIZED OK
2014-Jun-15 14:56:01.198940 [P2P0][199.188.178.180:18080 OUT] SYNCHRONIZED OK
2014-Jun-15 14:57:51.320218 [P2P6][sock 15] Some problems at write: Broken pipe:32
2014-Jun-15 14:58:49.917326 [P2P8][sock 22] Some problems at write: Broken pipe:32
2014-Jun-15 14:59:13.308392 [P2P1]ERROR /Users/ric/Desktop/Temp/bitmonero-core/contrib/epee/include/net/abstract_tcp_server2.inl:307 send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(100), shutting down connection
2014-Jun-15 14:59:13.420894 [P2P1]ERROR /Users/ric/Desktop/Temp/bitmonero-core/contrib/epee/include/net/levin_protocol_handler_async.h:638 [88.193.177.21:18080 OUT]Failed to do_send()
2014-Jun-15 14:59:14.102139 [P2P0]ERROR /Users/ric/Desktop/Temp/bitmonero-core/contrib/epee/include/net/abstract_tcp_server2.inl:307 send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(100), shutting down connection
2014-Jun-15 14:59:14.102228 [P2P0]ERROR /Users/ric/Desktop/Temp/bitmonero-core/contrib/epee/include/net/levin_protocol_handler_async.h:638 [88.193.177.21:18080 OUT]Failed to do_send()
2014-Jun-15 14:59:14.109085 [P2P0]ERROR /Users/ric/Desktop/Temp/bitmonero-core/contrib/epee/include/net/abstract_tcp_server2.inl:307 send que size is more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT(100), shutting down connection
I get the same error, but for me it's "tom" instead of ric... the mystery thickens... LOL! Are you serious? Well, hopefully it is nothing as the other poster said. Have you tried moving coins in and out? Thx, IAS Much mystery... ...such Scooby Doo: tewinget (Tom) built the Windows binaries, and I (Riccardo) built the OS X binaries. Obviously when you execute compiled code you don't have the source code *on your system*, but it has to still be able to reference where the error is occurring. You can safely ignore both those "ABSTRACT_SERVER_SEND_QUE_MAX_COUNT " errors as well as the path it refers to, as that just happened to be the build path at the time:) |
|
|
|
^The bug is well known to developers and they'll fix it, but it's not a high priority now. Basically your daemon is flooding other pears (and your) connection and those pears are disconnecting you. When you see a few of those in a line and then they stop for a while it's fine, but when you see huge amount (obviously you are monitoring your daemon) your best option is to exit the daemon (use "exit" or "q" in order to save the blockchain first) and start it again. This way you'll stop flooding the other pears connection (and yours too).
Not a high priority now? So it's ok for pools to restart daemons several times a day initiating disconnects? I am silent about bandwidth usage. If you're restarting your pool daemon several times a day please log it when it fails so we can isolate the issue. |
|
|
|
question: where else 4 Mx power network? I do not see many big pools.
Solo mining - never have to worry about a DDoS or a pool going down. Update your code once a week (at this early stage) to make sure you're on the latest build, and you're golden. ./bitmonerod --start-mining 49VNLa9K5ecJo13bwKYt5HCmA8GkgLwpyFjgGKG6qmp8dqoXww8TKPU2PJaLfAAtoZGgtHfJ1nYY8G2 YaewycB4f72yFT6u --mining-threads 6Easy as that! |
|
|
|
DDos is making people divert their hashrate somewhere else and helping more or less some newly launched pools get more hr/s which is not so bad afterall, except the fact that the ethics behind this sucks. Likely being done by someone who has a botnet mining somewhere else. Total hash goes down, botnet profits go up. Just shows one of the weaknesses of cpu only coins. Thank goodness it's not a CPU only coin, then! |
|
|
|
|
Thanks for the block time graph - that's awesome!
The API is looking solid; in the future once we've added viewkey and per-transaction key output to simplewallet I would imagine that you'll be able to add this to the API (although I suspect such lookups may be database intensive as you can't pre-cache every possible viewkey). Also, a pushtx-style API call might be nice for systems that want to be able to transact using your API.
|
|
|
|
we will also use a ''Cooling tent alike'' station for the rig  (which we will pay for) exciting stuff could you perhaps use a "series of magnets" to make an electro-generator which will power this mining rigs? I'll consider investing privately if this is the case They're using my patented Infinite Power technology to power the rigs:  |
|
|
|
I would argue that my 2 XMR bid was altruistic compared to your 250 XMR bid...I'm like a modern-day Ghandi, but with more curves (of the ECDSA kind, of course)  Meh... Altruistic in that you were essentially sponsoring a "pizza giveaway", but really, my wallet mind was set on the initiative standing for a "monero giveaway".  I'll be happy to pay you a pizza just for the entertainment that I get here, but I confess that I'd be happiest if the pizza auction had earned me the winning ticket to the 'let's spread some monero around' initiative!  On to more important matters: I hear there's an (open source) GUI wallet coming soon? Cheers, ~ Myagui At this time I can neither confirm nor deny that any work is being done one a GUI wallet. Just kidding, it is a work-in-progress, but we're a ways off from anything usable and solid:) |
|
|
|
is fluffypony a core dev for monero?
Indeed:)Nope. He is a well known pizza-snatcher! Beware!
~ Myagui
I would argue that my 2 XMR bid was altruistic compared to your 250 XMR bid...I'm like a modern-day Ghandi, but with more curves (of the ECDSA kind, of course) |
|
|
|
Hi, I have problem with the GUI Wallet , i cant syncronice
" 2014-Jun-12 14:03:36.198170 Starting...
2014-Jun-12 14:03:36.200170 bitmonero v0.8.8.1(0.1-g328a52a)
2014-Jun-12 14:03:36.200170 Module folder: C:\MONERO\monero.win.x64.experimental.0526\bitmonerod.exe
2014-Jun-12 14:03:36.278175 Initializing p2p server...
2014-Jun-12 14:03:36.282175 ERROR c:\temp\monero\git-experimental\bitmonero-0.8.8update-x64\src\p2p\net_node.inl:82 Exception at [node_server::init_config], what=input stream error
2014-Jun-12 14:03:36.283175 ERROR c:\temp\monero\git-experimental\bitmonero-0.8.8update-x64\src\p2p\net_node.inl:204 Failed to init config.
2014-Jun-12 14:03:36.283175 ERROR ..\..\src\daemon\daemon.cpp:148 Failed to initialize p2p server.
2014-Jun-12 14:03:36.283175 Mining has been stopped, 0 finished "
Can anyone Help me please ??
Ty
That's a VERY old binary - you're going to have to upgrade to the latest version in the OP. Unfortunately we can't provide assistance with the GUI wallets, you're going to have to chat to their authors about it. |
|
|
|
Hey guys,
I installed the new 11 june win64 binaries(just copy pasted over my old ones, like I mostly do) and I try to start bitmonerod to sync the network, but it seems like it never syncs, and on top of that, it SRSLY hang my network bandwith, like 90%. what is wrong?
Can you pastebin the output from the daemon? im sry u mean the .txt file? its mostly this"Sync data returned unknown top block: 81531 -> 81902" and keeps going on.... the real problem is it hangs my network! I was successfully using the last edition like 12 hours ago! and I cant find the old version of exe anymore because OP updated it... :/ That means it's catching up - it WILL use all the available bandwidth till its caught up, there's no rate-limiting on it. Remember: Monero is still alpha-level software and is not ready for widespread use or in situations where bandwidth is limited. A lightweight SPV-style client will only happen in the future once we've made everything a lot more robust and stable and workable:) |
|
|
|
|
Show Posts
