The good news is I am also seeing improved mining performance.  |
|
|
|
|
Running the latest code, I was getting a SEGFAULT on start up (whilst checking the Genesis block).
I had to revert PoWHash() to the original scrypt() call to get it to work. PoWHashScratchPad() seems to work fine with the new scryptscratchpad().
|
|
|
|
Is there any way to get an estimate of network hashrate? The apparent network hashrate for block 1725 was ~1.996 KH/s. (2^32 * d) / s d is block difficulty s is number of seconds it took to find the block |
|
|
|
If you're in favour of a fresh restart, vote for
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv
If you're in favour of putting existing balances into Block 1, vote for
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6
100 blocks (about 10 hours) to go. Still undecided. Can an alert be posted to the client or no? |
|
|
|
If you're in favour of a fresh restart, vote for
MVTE5E3xHqWM1haufsveX8o8bgwodUF9Jv
If you're in favour of putting existing balances into Block 1, vote for
MVTE7E3QD83ZLHivvBeNh8ZK1Eg313AEm6
100 blocks (about 10 hours) to go. Still undecided. |
|
|
|
|
I'm getting a segfault with the latest code.
|
|
|
|
That sounds pretty sophisticated for such a new coin - could someone really be taking all that effort before it is even listed on an exchange? I'll add that after spending a few hours looking into it, I don't think it's caused by your code. IMO, it's possible it could happen by chance, due to a smaller network and peers that are not running NTP. |
|
|
|
|
In the early 20th century Thomas Edison staged the electrocution of a number of animals (including an elephant) with the aim of discrediting alternating current. His term for that grisly process was getting "Westinghoused", in reference to his main competitor.
As time went on, AC became the standard anyway, Westinghouse succeeded and his efforts were in vain.
My reason for bringing this up is, I was just thinking today that Bitcoin may very well have a Topsy the elephant moment of it's own, due to vested interests.
Somehow I don't think the guys behind Credit Default Swaps and LIBOR rigging will just go quietly into the night.
And then there's another problem, which is even if Bitcoin gains wider acceptance, a cartel of bankers may attempt to dominate the market before it gets so big that it's out of their reach.
This is total speculation, but I imagine that there is more than one multi-billionaire that realizes Bitcoin may turn out to be worth far more than it's current price, yet balks at having to buy unless it's heavily discounted.
(This post was partially inspired by fake Bitcoin news and shenanigans in the Securities sub-forum).
It is my hope that no one takes anything I have written too seriously.
And please, feel free to speculate further along these lines.
|
|
|
|
|
Since network hashrate is only statistically inferred it could just be blind luck.
|
|
|
|
well that sucks having it say i have coins getting block after block only to find out later i get nothing for my efforts  Do they show up as orphans when you type "listtransactions" in the debug console? |
|
|
|
I'm getting tired of restarting the miner on my machines all the time when it hangs on a block.
That sounds like it could be a symptom of timejacking. https://en.bitcoin.it/wiki/Weaknesses#Forcing_clock_drift_against_a_target_nodeSpecifically this (the article is from 2011, so I'm not sure if bitcoin and derivatives are still susceptible): The network time is used to validate new blocks. As a precaution, nodes reject any block timestamp that is greater than 2 hours from the current network time. Block timestamps that are earlier than the median time of the past 11 blocks are also rejected. This validation puts upper and lower bounds on the acceptable range of block timestamps.
The attacker would then create a new block with a timestamp set 190 minutes ahead of the real time. (The amount of time required to generate a block would depend on the attacker's share of the network's total power, but it could be done 10 times a week on average by someone with a relatively small 1% share.)
The target node would reject this new block (because the timestamp is 260 minutes past its own slowed-down network time) and continue using the previous chain. However the miners would accept the block (because it's no more than 120 minutes past their own sped-up network time).
The target would now be isolated from the network's normal transaction processing. As network processing continues, each new block created by the miners would appear to be invalid (because it would bear a timestamp 140 minutes past the target's network time). The target would immediately drop invalid blocks (in CheckBlock()) without bothering to request and re-check the blocks' ancestors. The attack could continue indefinitely until either an unaffected node or the target itself creates a block, clocks are reset, or operators intervene. Source: http://culubas.blogspot.ca/2011/05/timejacking-bitcoin_802.html |
|
|
|
my coins are gone and the transaction history has disappeared from my wallet.
The transaction history is kept in the block chain. Considering that these are immature coins, your local copy of the block data would have to be almost fully synchronized before they show up. yup my wallet.dat was not deleted and my wallet was 100 synced all night long before i updated so i dunno what happened. how do i go from waiting for confirmations for 3 transactions to updating the wallet to no transactions and no coins ? They might be orphans. http://blockchain.info/orphaned-blocks |
|
|
|
my coins are gone and the transaction history has disappeared from my wallet.
The transaction history is kept in the block chain. Considering that these are immature coins, your local copy of the block data would have to be almost fully synchronized before they show up. |
|
|
|
and yeah i ditched my roaming folder and it acted the same way.
I hope you saved your wallet.dat file. |
|
|
|
hp9 gives me the following compile error on centos6 (the previous version compiled ok):
"In function `CKey::Verify(uint256, std::vector<unsigned char, std::allocator<unsigned char> > const&)':
/root/primecoin-0.1.2-hp9/src/key.cpp:376: undefined reference to `ECDSA_verify'
obj/key.o: In function `CKey::SetCompressedPubKey(bool)':
/root/primecoin-0.1.2-hp9/src/key.cpp:125: undefined reference to `EC_KEY_set_conv_form'"
Is it a fresh install of CentOS? If so, you'll need this step: Step 2b. Compiling OpenSSL (for CentOS users) This step is only required if you're using CentOS. Red Hat has removed support for elliptic curve cryptography from the OpenSSL it supplies. Code: cd rm -rf openssl-1.0.1e.tar.gz openssl-1.0.1e wget http://ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/openssl-1.0.1e.tar.gztar xzvf openssl-1.0.1e.tar.gz cd openssl-1.0.1e ./config shared --prefix=/usr/local --libdir=lib make sudo make install |
|
|
|
anyone get multi-threading in linux to work? I can compile/run, but then cannot connect to the server via the daemon command. Very odd
ok it seems like deleting my .memorycoin folder fixed this. However, only 1 CPU core is being used ? Are you using the multithread branch from github? |
|
|
|
why the hashespersec = 0?
Here is a small patch for this. Immediately after line 4873 of main.cpp, add this line: nHashesDone++; Re-run the make file and you should now have a non-zero hashespersec. |
|
|
|
still only see 1 core being used it's worse than that, it looks like I also cannot contact the server when this is running in daemon mode. note: this is on Linux Did you redo the addnode step(s) or are the nodes in your memorycoin.conf? |
|
|
|
based on cointype it downloads from the correct chain, nodes etc.
Something is up with git (ddos messing with it?), download the zip version for now and you should be okay.
This should work also: git clone -b mcinit https://github.com/memorycoin/memorycoin.git |
|
|
|
|
Show Posts
