here is syncing fine, maybe because i started from the beginning?
I started from the beginning too. Right now I'm fully synced and saving the blockchain for the first time. |
|
|
|
I'm having trouble with bitmonerod on Win7/64 - it hangs on initializing the P2P server. From bitmonerod.log: 2014-Dec-09 09:45:42.550851 bitmonero v0.8.8.6-release
2014-Dec-09 09:45:42.550851 Module folder: C:\Users\****\AppData\Roaming\bitmonero\bitmonerod.exe
2014-Dec-09 09:45:42.551851 Initializing P2P server... It stayed like this for about 15 minutes before I gave up waiting. In this meanwhile, bitmonerod uses about 4 MB of RAM and has no CPU usage. Any clues? Seems it does start at some point, after two long delays. Here's some logging: 2014-Dec-09 09:53:43.764375 bitmonero v0.8.8.6-release 2014-Dec-09 09:53:43.765375 Module folder: C:\Users\****\AppData\Roaming\bitmonero\bitmonerod.exe 2014-Dec-09 09:53:43.765375 Initializing P2P server... 2014-Dec-09 10:11:32.114481 Binding on 0.0.0.0:18080 2014-Dec-09 10:11:32.115481 Net service bound to 0.0.0.0:18080 2014-Dec-09 10:11:32.116481 Attempting to add IGD port mapping. 2014-Dec-09 10:11:36.124710 No IGD was found. 2014-Dec-09 10:11:36.124710 P2P server initialized OK 2014-Dec-09 10:11:36.125710 Initializing protocol... 2014-Dec-09 10:11:36.125710 Protocol initialized OK 2014-Dec-09 10:11:36.125710 Initializing core RPC server... 2014-Dec-09 10:11:36.125710 Binding on 127.0.0.1:18081 2014-Dec-09 10:11:36.125710 Core RPC server initialized OK on port: 18081 2014-Dec-09 10:11:36.126710 Initializing core... 2014-Dec-09 10:11:36.126710 Loading blockchain... 2014-Dec-09 10:11:36.126710 Can't load blockchain storage from file, generating genesis block. 2014-Dec-09 10:11:36.275719 Blockchain initialized. last block: 0, d888.h10.m11.s36 time ago, current difficulty: 1 2014-Dec-09 10:31:49.936136 Core initialized OK 2014-Dec-09 10:31:49.937136 Starting core RPC server... 2014-Dec-09 10:31:49.938136 Run net_service loop( 2 threads)... 2014-Dec-09 10:31:49.939136 [SRV_MAIN]Core RPC server started ok 2014-Dec-09 10:31:49.939136 [SRV_MAIN]Starting P2P net loop... 2014-Dec-09 10:31:49.940137 [SRV_MAIN]Run net_service loop( 10 threads)... 2014-Dec-09 10:31:50.940194 [P2P7] .......... started syncing .......... |
|
|
|
I'm having trouble with bitmonerod on Win7/64 - it hangs on initializing the P2P server. From bitmonerod.log: 2014-Dec-09 09:45:42.550851 bitmonero v0.8.8.6-release
2014-Dec-09 09:45:42.550851 Module folder: C:\Users\****\AppData\Roaming\bitmonero\bitmonerod.exe
2014-Dec-09 09:45:42.551851 Initializing P2P server... It stayed like this for about 15 minutes before I gave up waiting. In this meanwhile, bitmonerod uses about 4 MB of RAM and has no CPU usage. Any clues? |
|
|
|
xulescu: There shouldn't be a virgin coin premium for monero if our beliefs about fungibility are correct. If not, then the value proposition for monero is questionable.
You are right, of course. I referred to the lack of counter-parties. You need to pay somebody to acquire XMR. You might prefer to pay your electricity utility over others. |
|
|
|
I think you're not getting it - you don't adopt a kid if you don't have time to feed it and take care of it
Mining is not a adopting a kid, it is running a computer. Approached in a low-maintenance manner, it can be very similar to running a file server that doesn't require much attention for months or years. The break even electricity rate for Monero GPU mining is not even that low (haven't worked it out recently but maybe 10 cents/kwh). Yes I cringe when I see people posting about how "the difficulty is too damn high" because mining isn't profitable for them at 30 eurocents/kwh, but in locations with low rates you will still be profitable or accumulate coins at a small loss with little to no maintenance effort. Very true, it's not - and I'm not saying people CANNOT mine in an extremely low maintenance manner, I'm saying if they're going to do that, they may as well take some cash out of their wallet, burn a small percent, and use the rest to buy XMR, because that's basically what they're doing. Virgin coin premium |
|
|
|
Please price, raise a little bit faster. I'm waiting for too long in this coin. Price here, sure, how high would you like me to go 0.01 BTC would be good for starters. Roger that, let me prepare and spark up. A noticeable effect should be visible within 30 minutes. |
|
|
|
You're connected to a peer who is still on the block 202612 attack fork. I'm surprised to see that fork still exists at all. I suppose some people just don't update their clients at all. Nonetheless, there is no harm to you and you can safely ignore it. |
|
|
|
|
Here is my take on the Botnet Argument. I generally agree with smooth and iCEBREAKER.
I believe botnets are healthy for Monero and represent a desirable balancing factor in the whole network security and coin distribution incentives debate.
The security argument is that botnets make the network antifragile. From the point of view of the network, there are more entities and more CPUs doing PoW. From the very beginning Monero attempted to be a CPU-only coin ("one CPU one vote") and largely managed to do so. It is currently at the point where (1) enthusiasts and benefactors can mine on their CPUs and GPUs (they never mine at profitability, they gain utility from securing the network at a loss), where (2) unsecured computers can mine for botnet operators with about 5-20x lower hash rate per unit, and where (3) professional mining enterprise is crowded out by the first two groups.
Botnets effectively externalize part of the network security to the owners of the unsecured computers. They gain by learning the hard way (and would have been infected by some botnet at some point anyway). The network gains by using their computers. The internet at large becomes more secure. The only party that is losing are the professional miners. They can't just throw more money at Monero to get even more money back. Thus all the network is mined by parties that are, financially, at a loss. I believe this is a very healthy place to be, because it doesn't encourage the race to the bottom ("mining wars") in the hands of a few professional miners (I'm not saying is stops the race, but doesn't further encourage it. It's a balancing factor). Moreover, botnets are not zero-cost either and, because of everyone's incentives to keep botnets away, they cannot scale as well as professional mining. Thus, the network is more decentralized than in their absence. A final point to make here is that whether botnets should or should not be stopped is a normative matter, and therefore subject to moral judgements. I think we should reason about incentives and not necessarily morals.
The coin distribution argument is that it doesn't matter who does the mining, since the emission rate is the same anyway. At the same time, it does matter who sells the mining output. This is a market that can be cornered; indeed, that's exactly what a pump and dump implies. Given that botnets decentralize the sellers of mining output compared to professional miners, the Monero emission is harder to corner and harder to pump and dump. This is also a healthy place to be.
TL;DR: Botnets make the network more secure and keep professional miners out. This way, the Monero emission market is harder to corner and harder to pump and dump. The downside is that the ride will be more painful. This is also a good thing.
|
|
|
|
Hello!
How can i start to play?)
If you want to join right now head over to the Gold auction and secure a dividend-paying chunk of this limited resource. Otherwise you will have to wait and lose precious stone. https://bitcointalk.org/index.php?topic=831625 |
|
|
|
There is something wrong with the charts
I'm not sure but I think the scales may be misleading? Pick two points t1 < t2 at some distance apart such that, for example, cap(t1) = cap(t2) and price(t1) < price(t2), or, for example, price(t1) = price(t2) and cap(t1) > cap(t2). These pairs are not hard to find visually in the DRK and XC charts, but they do not exist in the XMR chart. If it holds that cap(t) = price(t) * emission(t) for any t, then in both cases above it follows that emission(t1) > emission(t2) for some t1 < t2. In other words, emission somehow decreased in time. That's why I wonder, did coins disappear by protocol?? Market cap is measured in USD, price in BTC. Oh /facepalm |
|
|
|
There is something wrong with the charts
I'm not sure but I think the scales may be misleading? Pick two points t1 < t2 at some distance apart such that, for example, cap(t1) = cap(t2) and price(t1) < price(t2), or, for example, price(t1) = price(t2) and cap(t1) > cap(t2). These pairs are not hard to find visually in the DRK and XC charts, but they do not exist in the XMR chart. If it holds that cap(t) = price(t) * emission(t) for any t, then in both cases above it follows that emission(t1) > emission(t2) for some t1 < t2. In other words, emission somehow decreased in time. That's why I wonder, did coins disappear by protocol?? |
|
|
|
...
There is something wrong with the charts Monero chart looks as expected, where the market cap grows compared to the price in time because the number of coins emitted increases in time.  Darkcoin chart, in the right half of the chart, displays the market cap shrinking faster than the price. Did the total emission decrease??  XCurrency chart. Same comment, valid for the entirely of the chart. Did XCs disappear from circulation??  |
|
|
|
Could somebody please help me to resolve this issue ? I was out of town & away from my home PC so I didn't updated my blockchain for almost 3 months, Last week when I came back I downloaded the latest wallet from the OP & also the blockchain (2.3 GB .bin file) from the link provided in the OP. After that when I ran bitmonerod.exe my blockchain was still about 40-45 days behind so, left it overnight running & in the morning it was done with synchronization. But then when I run simplewallet.exe, it gives me a weird message, 2014-Oct-23 11:04:45.414355 bitmonero wallet v0.8.8.4-771b531 2014-Oct-23 11:04:53.208800 Loaded wallet keys file, with public address: ----------------------------------------------------------------------------------------------------------------- 2014-Oct-23 11:04:53.208800 file not found: xmr, starting with empty blockchain 2014-Oct-23 11:04:53.208800 Opened wallet: ----------------------------------------------------------------------------------------------------------------- 2014-Oct-23 11:04:53.599823 Starting refresh... 2014-Oct-23 11:04:53.681828 Failed to invoke http request to http://localhost:18081/getblocks.bin, wrong response code: 500 2014-Oct-23 11:04:53.681828 ERROR ..\..\src\wallet\wallet2.cpp:282 !r. THROW EXCEPTION: error::no_connection_to_daemon 2014-Oct-23 11:04:53.703829 ..\..\src\wallet\wallet2.cpp:282:struct tools::error::no_connection_to_daemon: no connection to daemon, request = getblocks.bin 2014-Oct-23 11:04:53.709829 Another try pull_blocks (try_count=0)... 2014-Oct-23 11:04:53.749831 Failed to invoke http request to http://localhost:18081/getblocks.bin, wrong response code: 500 2014-Oct-23 11:04:53.750831 ERROR ..\..\src\wallet\wallet2.cpp:282 !r. THROW EXCEPTION: error::no_connection_to_daemon 2014-Oct-23 11:04:53.750831 ..\..\src\wallet\wallet2.cpp:282:struct tools::error::no_connection_to_daemon: no connection to daemon, request = getblocks.bin 2014-Oct-23 11:04:53.750831 Another try pull_blocks (try_count=1)... 2014-Oct-23 11:04:53.771833 Failed to invoke http request to http://localhost:18081/getblocks.bin, wrong response code: 500 2014-Oct-23 11:04:53.771833 ERROR ..\..\src\wallet\wallet2.cpp:282 !r. THROW EXCEPTION: error::no_connection_to_daemon 2014-Oct-23 11:04:53.772833 ..\..\src\wallet\wallet2.cpp:282:struct tools::error::no_connection_to_daemon: no connection to daemon, request = getblocks.bin 2014-Oct-23 11:04:53.772833 Another try pull_blocks (try_count=2)... 2014-Oct-23 11:04:53.794834 Failed to invoke http request to http://localhost:18081/getblocks.bin, wrong response code: 500 2014-Oct-23 11:04:53.794834 ERROR ..\..\src\wallet\wallet2.cpp:282 !r. THROW EXCEPTION: error::no_connection_to_daemon 2014-Oct-23 11:04:53.794834 ..\..\src\wallet\wallet2.cpp:282:struct tools::error::no_connection_to_daemon: no connection to daemon, request = getblocks.bin 2014-Oct-23 11:04:53.794834 ERROR ..\..\src\wallet\wallet2.cpp:358 pull_blocks failed, try_count=3 2014-Oct-23 11:04:53.803834 Error: refresh failed: no connection to daemon. Please, make sure daemon is running. Blocks received: 0 At the same time bitmonerod.log reads the following, 2014-Oct-23 11:02:31.377688 [P2P1][188.2.54.196:18080 OUT]Sync data returned unknown top block: 272598 -> 272778 [180 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Oct-23 11:03:24.909750 [P2P3][85.69.78.14:18080 OUT] SYNCHRONIZED OK
2014-Oct-23 11:04:53.646826 [RPC0]ERROR c:\users\ric_000\desktop\bitmonero\src\rpc\core_rpc_server.h:68 Failed to on_get_blocks()
2014-Oct-23 11:04:53.710829 [RPC0]ERROR c:\users\ric_000\desktop\bitmonero\src\rpc\core_rpc_server.h:68 Failed to on_get_blocks()
2014-Oct-23 11:04:53.750831 [RPC1]ERROR c:\users\ric_000\desktop\bitmonero\src\rpc\core_rpc_server.h:68 Failed to on_get_blocks()
2014-Oct-23 11:04:53.772833 [RPC0]ERROR c:\users\ric_000\desktop\bitmonero\src\rpc\core_rpc_server.h:68 Failed to on_get_blocks()
Anybody ? I don't know what causes the issue, but I've had it too when loading the [wallet.bin].key file without the [wallet.bin] file. 0. Close both the daemon and the client 1. Backup your [wallet.bin].key file securely2. Delete your [wallet.bin] file 3. Start daemon, wait for sync 4. Start client, load your [wallet.bin].key 5. Type in client "refresh", and EITHER .... 5a. .... everything works, you are done OR .... 5b. .... type in client "save", then "exit" and then restart client and you should be done In my case, I got that error when I loaded a wallet from [wallet.bin].key without the [wallet.bin] file. Typing "save" makes the client create the [wallet.bin] file, and after a restart it worked fine. Let us know if you have further questions or if it fixed your problem! |
|
|
|
... all winners pay the same amount per lot (the price of the highest non-winning bid).
Emphasizing this important difference from the last auction for clarity. Might you explain why the difference is important? It discourages strategic bidding and encourages people to bid what they actually think the gold is worth. Of course, you can't force people to bid that way, just create the incentives. An example of the difference would be that lets say I think the gold is worth 1 XMR. So I bid 1 XMR for all 10k. No one else thinks it is worth more than 0.5 so that is the highest losing bid. Under the old rules I pay 1 XMR, which penalizes me for bidding my actual belief (I could have bid 0.5 or 0.51 and still won). Under the new rules I pay 0.5, which does not penalize me. For some references, see http://www.eecs.harvard.edu/~parkes/cs286r/spring07/papers/myerson.pdfhttp://arxiv.org/pdf/0906.1019v1.pdfSorry for the hijack, this is the last post I make on the topic. |
|
|
|
... all winners pay the same amount per lot (the price of the highest non-winning bid).
Emphasizing this important difference from the last auction for clarity. |
|
|
|
I'll never understand why people make accounts on this forum just to troll. what the hell does he gain from this?
0.$$ |
|
|
|
|
In my understanding, it doesn't work like that. You get the same rate on the first 2000 CKG no matter if you have 2k or 200k of them.
|
|
|
|
|
For future auctions, make the price be the first nonwinning bid. This way you get a pure multi-VCG auction with nice preference revelation properties.
|
|
|
|
|
Show Posts
