 Show Posts
|
|
Pages: [1] 2 »
|
|
Hello!
CG:whortonda ; FH:whortonda ; Coin:BTC
|
|
|
|
|
Can't open a support ticket, so on the off chance that C-Cex even reads this forum...
WTHC and MLM deposits for the past 2 days are not being credited. I suspect other coins are affected as well. The wallet status appears to be up to date with the correct blockchain height, but deposits do not appear.
Please provide some kind of update.
|
|
|
|
|
Thank you protonn and aatheus for providing the bootstrap. I really appreciate it!
The bootstrap imported just fine, but the wallet still will not sync despite 18 network connections (10 out / 8 in) and only being 8 days behind.
The wallet gets stuck at block 2,388,213 (which interestingly is about 2000 blocks behind the bootstrap block indicated by protonn). Debug log is more of the same, just a bunch of dropped connections. Total network traffic after one hour is only about 50KB in and out, so it's not even trying I don't think. I did a reindex just for kicks, but it did not help.
Sorry I can't be more helpful in figuring this out. Let me know if I can provide any more info.
|
|
|
|
@kavjlaeg: 9333 is the p2p port; I am using a non-standard worker port 3000. I edited my original post to clarify. Anyone is welcome to mine to my node. I can't guarantee 100% uptime, but if it becomes unresponsive I'll work to restore as soon as possible. Full disclosure: I am merge mining several coins on my node. Merge mined coins are not shared among miners, so by mining to my node you will be generating free coins for me. Second block on jtoomim fork found: https://blockchain.info/block/000000000000000001a22e8f0a4b0cc86e6a301d3b0bbc6022a7d1a67139eb5c998kB / 13.82763859 BTC Hashrate on the fork increasing as well-- 15PH for the last few hours. |
|
|
|
After the recent issue I decided to do a full re-download of the blockchain, but the new client v3.11.3.1-72cf1f3 will not seem to download from peers. I have anywhere from 8-16 active connections, both outgoing and incoming, with up-to-date protocol and client versions, but no blocks will download. I've tried the Windows QT client and building from source on Ubuntu, and both exhibit the same behavior. The debug.log is not much help, but here's an excerpt. 2017-05-02 20:20:44 Argentum version v3.11.3.1-72cf1f3 (2017-04-27 11:22:04 -0500)
2017-05-02 20:20:44 Using OpenSSL version OpenSSL 1.0.1k 8 Jan 2015
2017-05-02 20:20:44 Using BerkeleyDB version Berkeley DB 5.1.29: (October 25, 2011)
2017-05-02 20:20:44 Default data directory C:\Users\darren\AppData\Roaming\Argentum
2017-05-02 20:20:44 Using data directory f:\crypto\arg\data
2017-05-02 20:20:44 Using config file F:\crypto\arg\arg.conf
2017-05-02 20:20:44 Using at most 125 connections (2048 file descriptors available)
2017-05-02 20:20:44 Using 12 threads for script verification
2017-05-02 20:20:44 scheduler thread start
2017-05-02 20:20:44 Binding RPC on address :: port 13581 (IPv4+IPv6 bind any: 1)
2017-05-02 20:20:44 Using wallet wallet.dat
2017-05-02 20:20:44 init message: Verifying wallet...
2017-05-02 20:20:44 CDBEnv::Open: LogDir=f:\crypto\arg\data\database ErrorFile=f:\crypto\arg\data\db.log
2017-05-02 20:20:44 Bound to [::]:13580
2017-05-02 20:20:44 Bound to 0.0.0.0:13580
2017-05-02 20:20:44 Cache configuration:
2017-05-02 20:20:44 * Using 2.0MiB for block index database
2017-05-02 20:20:44 * Using 39.5MiB for chain state database
2017-05-02 20:20:44 * Using 86.5MiB for in-memory UTXO set
2017-05-02 20:20:44 init message: Loading block index...
2017-05-02 20:20:44 Opening LevelDB in f:\crypto\arg\data\blocks\index
2017-05-02 20:20:44 Opened LevelDB successfully
2017-05-02 20:20:44 Opening LevelDB in f:\crypto\arg\data\chainstate
2017-05-02 20:20:44 Opened LevelDB successfully
2017-05-02 20:20:45 LoadBlockIndexDB: last block file = 0
2017-05-02 20:20:45 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=1, size=286, heights=0...0, time=2013-05-22...2013-05-22)
2017-05-02 20:20:45 Checking all blk files are present...
2017-05-02 20:20:45 LoadBlockIndexDB: transaction index disabled
2017-05-02 20:20:45 LoadBlockIndexDB: address index disabled
2017-05-02 20:20:45 LoadBlockIndexDB: hashBestChain=88c667bc63167685e4e4da058fffdfe8e007e5abffd6855de52ad59df7bb0bb2 height=0 date=2013-05-22 05:18:08 progress=0.000000
2017-05-02 20:20:45 init message: Verifying blocks...
2017-05-02 20:20:45 block index 939ms
2017-05-02 20:20:45 init message: Loading wallet...
2017-05-02 20:20:45 nFileVersion = 3110300
2017-05-02 20:20:45 Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
2017-05-02 20:20:45 wallet 12ms
2017-05-02 20:20:45 init message: Activating best chain...
2017-05-02 20:20:45 mapBlockIndex.size() = 2001
2017-05-02 20:20:45 nBestHeight = 0
2017-05-02 20:20:45 setKeyPool.size() = 100
2017-05-02 20:20:45 mapWallet.size() = 0
2017-05-02 20:20:45 mapAddressBook.size() = 1
2017-05-02 20:20:45 init message: Loading addresses...
2017-05-02 20:20:45 Loaded 118 addresses from peers.dat 4ms
2017-05-02 20:20:45 AddLocal([2001:0:9d38:953c:3cb8:35e9:b5bd:a980]:13580,1)
2017-05-02 20:20:45 Discover: dpc - 2001:0:9d38:953c:3cb8:35e9:b5bd:a980
2017-05-02 20:20:45 dnsseed thread start
2017-05-02 20:20:45 init message: Done loading
2017-05-02 20:20:45 net thread start
2017-05-02 20:20:45 addcon thread start
2017-05-02 20:20:45 opencon thread start
2017-05-02 20:20:45 msghand thread start
2017-05-02 20:20:45 receive version message: /Argetoshi:3.11.3/: version 1070000, blocks=1796149, us=74.66.86.127:13580, peer=1
2017-05-02 20:20:45 Added time data, samples 2, offset +15 (+0 minutes)
2017-05-02 20:20:45 GUI: PaymentServer::LoadRootCAs: Loaded 48 root certificates
2017-05-02 20:20:46 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=2390164, us=74.66.86.127:57757, peer=3
2017-05-02 20:20:46 Added time data, samples 3, offset -2 (+0 minutes)
2017-05-02 20:20:47 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=2387736, us=74.66.86.127:57767, peer=5
2017-05-02 20:20:47 Added time data, samples 4, offset -1 (+0 minutes)
2017-05-02 20:20:48 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=1176819, us=74.66.86.127:57770, peer=6
2017-05-02 20:20:48 Added time data, samples 5, offset -1 (+0 minutes)
2017-05-02 20:20:48 nTimeOffset = -1 (+0 minutes)
2017-05-02 20:20:49 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=2388712, us=[2001:0:9d38:953c:3cb8:35e9:b5bd:a980]:57762, peer=4
2017-05-02 20:20:49 Added time data, samples 6, offset -2 (+0 minutes)
2017-05-02 20:20:51 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=831724, us=74.66.86.127:57789, peer=7
2017-05-02 20:20:51 Added time data, samples 7, offset -3 (+0 minutes)
2017-05-02 20:20:51 nTimeOffset = -1 (+0 minutes)
2017-05-02 20:20:56 P2P peers available. Skipped DNS seeding.
2017-05-02 20:20:56 dnsseed thread exit
2017-05-02 20:21:15 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=1796710, us=74.66.86.127:13580, peer=9
2017-05-02 20:21:15 Added time data, samples 8, offset +0 (+0 minutes)
2017-05-02 20:21:22 socket recv error An existing connection was forcibly closed by the remote host. (10054)
2017-05-02 20:22:13 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=2388712, us=74.66.86.127:13580, peer=10
2017-05-02 20:22:13 Added time data, samples 9, offset -1 (+0 minutes)
2017-05-02 20:22:13 nTimeOffset = -1 (+0 minutes)
2017-05-02 20:23:20 peer=11 using obsolete version 1050000; disconnecting
2017-05-02 20:23:20 ProcessMessages(version, 103 bytes) FAILED peer=11
2017-05-02 20:24:31 socket recv error An existing connection was forcibly closed by the remote host. (10054)
2017-05-02 20:26:19 connected to self at 192.168.1.1:59976, disconnecting
2017-05-02 20:26:19 Misbehaving: 74.66.86.127:13580 (0 -> 1)
2017-05-02 20:26:19 ProcessMessages(ping, 8 bytes) FAILED peer=15
2017-05-02 20:27:18 receive version message: /Argetoshi:3.11.3.1/: version 1070000, blocks=0, us=74.66.86.127:13580, peer=17
2017-05-02 20:27:18 Added time data, samples 10, offset -1 (+0 minutes)
2017-05-02 20:27:40 socket recv error An existing connection was forcibly closed by the remote host. (10054)
Can anyone shed any light on this? Is there a bootstrap somewhere that might get me rolling? Thank you. |
|
|
|
Greetings p2poolers, I'm the owner of the "1Hinen" address. I began renting hashpower to mine on p2pool about a month ago and noticed the smaller block sizes, and came across the discussion here after some Googling on the subject. @jtoomim, I have switched my node to your fork. I just finished downloading the sharechain and it looks like everything is working well. You can expect anywhere from 0-10Ph of rented hashpower from me depending on rental prices. Please let me know if I can do anything else to help you test your fork (or if I'm doing anything that's not helpful). Thank you for your work on this. Looking forward to finding a fat 1MB block with you.  --Darren ---------------------------------------------------------------------------------- Node: whortonda.noip.me Worker port: 3000 P2P port: 9333 Connected to: ml.toom.im:9333 To connect to me: run_p2pool.py -n whortonda.noip.me:9333 CPU: Core i7-6800K @ 3.4GHz RAM: 32GB Pipe: 100m/20m cable Using: Python 2.7 / Ubuntu 16.04 LTS I am using a non-standard miner port to avoid conflict with litecoind. Anyone is welcome to mine to my node, but I can't guarantee 100% stability. |
|
|
|
|
Regarding Bter...
On 27 March they responded to all my open tickets saying YAC deposits were fixed. All of the deposits I made over the past few weeks did in fact appear.
On 29 March, I made two new deposits, and neither have appeared after over 100 confirmations. I've opened another ticket.
I am done with Bter. My thanks again to Yobit and Alcurex for giving us a reliable trading platform.
|
|
|
|
|
This is fantastic!! Thanks to Yobit for adding the coin, and thanks to all who requested.
Yobit wallet still catching up on blocks it looks like... it's about 20K blocks behind but moving pretty fast.
|
|
|
|
Sorry, but what a dumb idea to name a coin almost the same as another. I'm out! YACoin predates YACCoin by 8 months... |
|
|
|
|
For what it's worth, Bter support just responded to all 3 of my open tickets with the phrase "still working on it.Thanks for your patience." [sic]
No YAC deposits have appeared in my account yet, but that's something I guess. I've been making small test deposits about once per day-- will update if they ever show up.
|
|
|
|
|
I also have a YAC deposit to Bter from 29 Feb which has not appeared in my balance. I opened a ticket and received no response for 2 days.
Deposits had been working fine for months before.
I'd recommend staying away from Bter until they address this problem. I'll share any updates I have.
|
|
|
|
@usukan -- I'm a web developer, so I'm accustomed to markup and scripting languages that don't compile. I'm not really experienced with the build process, and I don't have experience with C++. I can read the source and get an idea of what it's doing, but writing it is a different story. For that reason, I don't really feel that I'm qualified to be in a full developer role, but I would be happy to help in any way I can. I do feel like reverting the retargeting to V3 should be pretty trivial-- all the old code is still in the source, and it should just be a matter of reviewing and updating references. I could even take a stab at it, but compiling and testing would be a learning process for me. I would also be happy to take a look at the updated source once changes are made. I mined UTC when it was Nf15 and Nf16 as well, and I don't remember any major retargeting issues. Would love to see this coin make a comeback! |
|
|
|
Based on just a cursory review of Digibyte's retargeting (a.k.a. DigiShield), it appears to me that the algorithm is the same one UTC uses. The retarget boils down to this: - Calculate the time it took to mine the last 10 blocks (actualTimespan)
- Apply constraints to actualTimespan (max 16% down and 8% up)
- Adjust the difficulty by actualTimespan/targetTimespan (inverse scaling, because higher target means lower difficulty)
DGB also includes special adjustments for its various hashing algorithms, because they each have independent targets. The only substantive difference is the averaging interval and adjustment caps... and get this: in DGB, the averaging interval and adjustment caps are exactly the same as UTC retargeting V3.Which brings us back to bathrobehero's suggestion to use the old retargeting, which was a 10-block interval. I think that's the way to go. |
|
|
|
|
I understand the PoW block reward varies now that PoS has started... any way to predict what the average PoW block reward will be?
|
|
|
|
@bathrobehero: Good call. I think reverting to the V3 retargeting would work fine and may save some effort. It's still simple averaging as in V4 and V5, but back then the averaging interval was 10 minutes (10 blocks). That makes it much more responsive to what's currently happening with the network. Makes me wonder why they ever decided to change the averaging interval at all. The max adjustment was also different (was 16% down and 8% up in V3, changed to 16% down and 12% up in V4-V5) but that's somewhat arbitrary. |
|
|
|
@bathrobehero I am by no means an expert, so take all this with a grain of salt. I think you're on the right track, but the problem isn't with the frequency of the retarget or the percent increase/decrease limits-- it's with the averaging method not taking into account large fluctuations in network hashrate. The retargeting method uses a simple average of the time it took to mine each of the past 240 PoW blocks. With a simple average, all the data points are treated with the same weight, so blocks that were mined hours ago at absolute minimum difficulty have as much influence as the last block which perhaps was mined at a very high difficulty and took far too long. Super-simplified example: if there were 120 blocks mined over 10 minutes at low difficulty followed by 120 blocks mined over 3 hours 50 minutes at high difficulty, then a simple average would think that's right on target because hey, that's 240 blocks in 4 hours. What I would suggest is using some sort of weighted average to calculate the average block time. This method gives recent data points more weight than data points further in the past, so the block time of the last few blocks would have much greater influence on the next difficulty than the block time of blocks mined hours ago. It complicates the calculation a bit because you have to get the block time of each block over the averaging period and apply the weighting factors, but it's not that difficult. I think you could even reduce the period significantly, like perhaps the last 60 blocks (theoretically the last hour), without adverse effect. Here's how you would calculate a linear weighted average block time (pseudocode). averagingPeriod = 60; //60 blocks, one hour
weightedAverageBlockTime = 0;
i = 0;
while(i < averagingPeriod) {
weight = (averagingPeriod - i) / ((averagingPeriod * (averagingPeriod + 1)) / 2);
weightedAverageBlockTime += weight * (BlockTimestamp(blocks[thisBlock-i]) - BlockTimestamp(blocks[thisBlock-i-1]));
i++;
}
//it looks like from the source code that higher targets represent lower difficulty
//because the goal is to find a hash below the difficulty target
//so scaling is actually the mathematical inverse -- I think this is correct
scalingFactor = weightedAverageBlockTime / targetBlockTime;
nextDifficulty = Min(lastDifficulty * scalingFactor, proofOfWorkDifficultyLimit);
You could of course still apply the max increase/decrease limits, but I think the weighted average itself would handle that for you in all but the most extreme cases. Hope that's helpful and more power to you. |
|
|
|
Just an update: I was able to work around the longpoll disconnect issue by using the API. - start ccminer with --api-remote flag
- issue "pool" API command to get pool status info
- if LAST variable (last submitted share) is greater than 180 seconds, issue the "quit" command
- miner exits, batch file continues and tries next pool
Works like a charm! All that, though, and I haven't been disconnected even once from the pool in the past 2 days. Heh, figures. |
|
|
|
|
