I am confused what has happened with this blockchain? The forum says the latest version is 0.9.5. I am on 0.9.5.9 Array ( [version] => 90509 [protocolversion] => 70001 [walletversion] => 60000 [balance] => 7.02847527 [blocks] => 600540 [timeoffset] => 0 [connections] => 3 [proxy] => [difficulty] => 544065.74668734 [testnet] => [keypoololdest] => 1430870554 [keypoolsize] => 101 [paytxfee] => 0 [errors] => Warning: This version is obsolete, upgrade required! )
Are my miners wasting their time? Your version is what the majority of the network is on actually. I think there were some false assumptions by the dev about the recent update. As far as i can see the update of only parts of the network to 0.1 is causing trouble. Stupid mistake, really. I'd recommend to keep an eye out for any new updates here on that matter. Wether hash is wasted isn't quite clear yet. We're waiting for updates from the dev for now. Thank you for the clarification. I did a test build of the latest source on Github and it seems as if MM was not supposed to be started quite yet Unobtanium Core version v0.10.0.0-d21fb40-dirty-preMM (64-bit) This is why I always use 'official' releases and never use the latest source.
|
|
|
The Unobtanium blockchain appears to have forked due to some miscommunication between the community and developer. Our pool is on the latest officially released version 0.9.5.9, which is what the majority of the block chain is on, and we are on the correct chain. Please follow the discussion here if you have concerns: https://bitcointalk.org/index.php?topic=527500.new;topicseen#new
|
|
|
I am confused what has happened with this blockchain? The forum says the latest version is 0.9.5. I am on 0.9.5.9 Array ( [version] => 90509 [protocolversion] => 70001 [walletversion] => 60000 [balance] => 7.02847527 [blocks] => 600540 [timeoffset] => 0 [connections] => 3 [proxy] => [difficulty] => 544065.74668734 [testnet] => [keypoololdest] => 1430870554 [keypoolsize] => 101 [paytxfee] => 0 [errors] => Warning: This version is obsolete, upgrade required! )
Are my miners wasting their time?
|
|
|
I understand the design behind BIP: 34. However I don't understand it's implementation in main.cpp. Can someone explain (in a somewhat 'dumbed down' fashion) what is happening here: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2673. Specifically this check: CScript expect = CScript() << nHeight; if (block.vtx[0].vin[0].scriptSig.size() < expect.size() || !std::equal(expect.begin(), expect.end(), block.vtx[0].vin[0].scriptSig.begin())) { return state.DoS(100, error("%s: block height mismatch in coinbase", __func__), REJECT_INVALID, "bad-cb-height"); }
Why is this coinbase being rejected by the above code? This specific example is version 2 (PoS) and has TX messaging02000000 c60c4b55 01 0000000000000000000000000000000000000000000000000000000000000000 ffffffff 1b 0101 <= serialized block height 04430d4b5508f8000001000000000a2f54696465506f6f6c2f 00000000 01 809fd50000000000 23 21022bec99ba133dc4bb055e1eb954370a4ca73f173348a6409c4ae8f92ef7ffd0f7ac 00000000 105365637572655061796d656e742e4343
Here is the code that generates the serialized height in Python def encode_coinbase_nheight(n, min_size = 1): # For encoding nHeight into coinbase s = bytearray(b'\1')
while n > 127: s[0] += 1 s.append(n % 256) n //= 256
# Add to byte array s.append(n)
# This can never be less that 1 bytes long if min_size < 1: min_size = 1
# Satisfy Minimum Length while len(s) < min_size + 1: s.append(0) s[0] += 1
return bytes(s)
|
|
|
I made the error of letting my earnings balance accumulate to a pretty significant amount on CoinURL. Today, out of nowhere I see my account has been banned, perhaps because the balance has grown large enough that they would go as far as to prevent me from withdrawing it
I have not violated any terms of service or committed any type of fraud.
That statement is said with fact and in the utmost confidence.
This post serves as a warning to anyone who uses the (CoinURL) service. I will continue to post updates here.
|
|
|
Interesting, this has been re-listed on Coinwarz
|
|
|
The new storage back end is in place and I've already migrated some blockchains to it. The results have so far been positive. I've seen less 'disconnects' and less stale/orphan blocks in the past 24 hours. I'm planning on moving the remaining blockchains in the next couple of hours. This include (but not limited to) Peercoin, Zetacoin, Bitcoin, and Litecoin. Your client may disconnect for a minute while I swap the storage. For those who like pictures.... The blockchains are currently using a steady 20 MBytes per second of bandwidth. The system can support up to 10 Gbps
|
|
|
ISP had something 'blow up' on there end. It's the only moving piece I can not control directly. The connection was down for more that 5 hours which indicated it was pretty serious. (I have a 1 hour response time SLA). Getting a second connection is not possible at the moment (way too expensive). Perhaps sometime in the future when I deploy more services and generate more revenue. Establishing connection with pool ppcoin.securepayment.cc:3357... Error: connect timed out
so unstable lately..
Aside from the connection issue last night. Stability should be getting much better real soon. I've purchased some new storage hardware that will improve things.
|
|
|
The version being used is the recommended release 0.4.0.0. It set to an additional 60 confirms to allow the newly minted coin's priority to rise to at least medium-high before sending them.
|
|
|
3 orphans cant get catch a break on dash iam done here going to mine on a pool or when solomining gets fix
I've taken the darkcoin/dash pool offline until the issue is fixed.
|
|
|
I'm was getting some of those two. Are you running behind NAT? Do you have the 1000 DASH that is required? I have Erros in my debug.log
2015-04-24 08:43:46 CDarksendPool::UpdateState() - Can't set state to ERROR or SUCCESS as a Masternode.
Why?? Masternode works but.
|
|
|
My pool found this block nHeight 257596 Hash 000000000016be405857a548371161b4569520e73eab8d70ea58276a75d55d5d But instead, this block got included in the chain: 2015-04-24 06:01:24 UpdateTip: new best=00000000001e870dd01bdb09a3bf72a438f1380363b169daa78957db578e19c8 height=257596 log2_work=61.314868 tx=1064294 date=2015-04-24 06:00:31 progress=0.999993 UPDATE: I think I may know why, I might need to apply these code changes: https://github.com/dashpay/dash-stratum/commit/27d49a5e19400800f9fe5940a808e6e652fe1e17#diff-61399243d4a76271891763ba0f3edfe8What happened here with this block? nHeight 257596 Hash 000000000016be405857a548371161b4569520e73eab8d70ea58276a75d55d5d 2015-04-24 06:00:58 CheckBlock() : Skipping masternode payment check - nHeight 257596 Hash 000000000016be405857a548371161b4569520e73eab8d70ea58276a75d55d5d 2015-04-24 06:01:00 ProcessBlock: ACCEPTED 2015-04-24 06:01:00 Masternode payment to XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb 2015-04-24 06:01:00 CreateNewBlock(): total size 11722 2015-04-24 06:01:00 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:14 keypool reserve 3 2015-04-24 06:01:14 keypool return 3 2015-04-24 06:01:15 keypool reserve 3 2015-04-24 06:01:15 keypool return 3 2015-04-24 06:01:15 partner 70.162.130.91:54280 using obsolete version 70038; disconnecting 2015-04-24 06:01:15 ProcessMessage(version, 104 bytes) FAILED 2015-04-24 06:01:16 keypool reserve 3 2015-04-24 06:01:16 keypool return 3 2015-04-24 06:01:19 keypool reserve 3 2015-04-24 06:01:19 keypool return 3 2015-04-24 06:01:19 Masternode payment to XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb 2015-04-24 06:01:19 CreateNewBlock(): total size 11948 2015-04-24 06:01:19 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:23 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:23 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:24 UpdateTip: new best=00000000001e870dd01bdb09a3bf72a438f1380363b169daa78957db578e19c8 height=257596 log2_work=61.314868 tx=1064294 date=2015-04-24 06:00:31 progress=0.999993 2015-04-24 06:01:24 ProcessBlock: ACCEPTED
Which line do you think it's not normal?
|
|
|
What happened here with this block? nHeight 257596 Hash 000000000016be405857a548371161b4569520e73eab8d70ea58276a75d55d5d 2015-04-24 06:00:58 CheckBlock() : Skipping masternode payment check - nHeight 257596 Hash 000000000016be405857a548371161b4569520e73eab8d70ea58276a75d55d5d 2015-04-24 06:01:00 ProcessBlock: ACCEPTED 2015-04-24 06:01:00 Masternode payment to XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb 2015-04-24 06:01:00 CreateNewBlock(): total size 11722 2015-04-24 06:01:00 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:14 keypool reserve 3 2015-04-24 06:01:14 keypool return 3 2015-04-24 06:01:15 keypool reserve 3 2015-04-24 06:01:15 keypool return 3 2015-04-24 06:01:15 partner 70.162.130.91:54280 using obsolete version 70038; disconnecting 2015-04-24 06:01:15 ProcessMessage(version, 104 bytes) FAILED 2015-04-24 06:01:16 keypool reserve 3 2015-04-24 06:01:16 keypool return 3 2015-04-24 06:01:19 keypool reserve 3 2015-04-24 06:01:19 keypool return 3 2015-04-24 06:01:19 Masternode payment to XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb 2015-04-24 06:01:19 CreateNewBlock(): total size 11948 2015-04-24 06:01:19 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:23 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:23 CheckBlock() : Found payment(1|276675000) or payee(1|XksNoqKaiVvW9Q3xYc5dbyiweuz9RF2oFb) nHeight 257596. 2015-04-24 06:01:24 UpdateTip: new best=00000000001e870dd01bdb09a3bf72a438f1380363b169daa78957db578e19c8 height=257596 log2_work=61.314868 tx=1064294 date=2015-04-24 06:00:31 progress=0.999993 2015-04-24 06:01:24 ProcessBlock: ACCEPTED
|
|
|
what is the pools conf rate set to peercoin(520?), and auto payout period in hours?
define("CONFORMATIONS", 580); //Found in src/main.h:COINBASE_MATURITY, usually COINBASE_MATURITY + 20 Checked every hour.
|
|
|
It just happened again. The 35 LGD I sent to myself got reversed Someone is definitely up to no good here. Looks like this just got 51% attacked. Every block and transaction in the last 16 hours has just gotten reversed.
It's possibly a stake attack. I don't know specifics of this coin, but most PoS/PoW coins place an incredibly high weight on PoS blocks. A single PoS block can reverse hundreds of PoW blocks, which makes it quite easy to cause mischief when a coin is quiet. I've seen this happen on numerous less popular coins. The solution is simple: more clients need to stake, to help cement those transactions and blocks, and override any malicious behaviour. If you have a balance, make sure your wallet is open, and unlocked (so it can stake) I'm going to buy a small amount at Cryptsy - mining is probably pointless right now if transactions are regularly reversed - and see how I go in 5 days time.
|
|
|
Normally that should not be a problem. However, LegendaryCoin appears to be having some block chain problems. Not sure if it's a 51% attack, PoS attack, or a fork in the block chain. The developer of that coin has not been seen or heard from for almost a year and the check point's have not been updated since. It means your hardware is too powerful for the coin's current network difficulty. Your finding blocks way too fast and the coin network can't keep up. You are basically 'orphaning' your own blocks.
So to do that in this case? How to do mining coins through yours pool?
|
|
|
It means your hardware is too powerful for the coin's current network difficulty. Your finding blocks way too fast and the coin network can't keep up. You are basically 'orphaning' your own blocks. Hi! LegendaryCoin Explain, please, that occurs. Pool the long finds the same block. Then becomes orphan.
LNGnPubsoGNjD6xs2KoohQPKL9BMDxhbTC Approximate Speed: 114.80 MH/s
Last 100 Blocks found by this miner:
178798: 2015-04-20 18:13:45 GMT-5 | Pending 178798: 2015-04-20 18:13:31 GMT-5 | Pending 178798: 2015-04-20 18:13:22 GMT-5 | Pending 178798: 2015-04-20 18:13:10 GMT-5 | Pending 178798: 2015-04-20 18:12:54 GMT-5 | Pending 178798: 2015-04-20 18:12:36 GMT-5 | Pending 178798: 2015-04-20 18:12:28 GMT-5 | Pending 178798: 2015-04-20 18:12:15 GMT-5 | Pending 178798: 2015-04-20 18:12:06 GMT-5 | Pending 178798: 2015-04-20 18:11:53 GMT-5 | Pending 178798: 2015-04-20 18:11:41 GMT-5 | Pending 178798: 2015-04-20 18:11:16 GMT-5 | Pending 178798: 2015-04-20 18:11:02 GMT-5 | Pending 178798: 2015-04-20 18:10:36 GMT-5 | Pending 178798: 2015-04-20 18:10:23 GMT-5 | Pending 178798: 2015-04-20 18:09:28 GMT-5 | Pending 178798: 2015-04-20 18:09:17 GMT-5 | Pending 178798: 2015-04-20 18:08:58 GMT-5 | Pending 178798: 2015-04-20 18:08:46 GMT-5 | Pending 178798: 2015-04-20 18:08:31 GMT-5 | Pending 178798: 2015-04-20 18:08:18 GMT-5 | Pending 178798: 2015-04-20 18:08:06 GMT-5 | Pending 178798: 2015-04-20 18:07:39 GMT-5 | Pending 178798: 2015-04-20 18:07:26 GMT-5 | Pending 178798: 2015-04-20 18:07:14 GMT-5 | Pending 178798: 2015-04-20 18:06:57 GMT-5 | Pending 178798: 2015-04-20 18:06:51 GMT-5 | Pending 178798: 2015-04-20 18:06:19 GMT-5 | Pending 178798: 2015-04-20 18:05:50 GMT-5 | Pending 178798: 2015-04-20 18:04:54 GMT-5 | Pending 178798: 2015-04-20 18:04:37 GMT-5 | Pending 178798: 2015-04-20 18:04:09 GMT-5 | Pending 178798: 2015-04-20 18:03:48 GMT-5 | Pending 178798: 2015-04-20 18:02:22 GMT-5 | Pending 178798: 2015-04-20 18:02:14 GMT-5 | Pending 178798: 2015-04-20 18:02:11 GMT-5 | Pending 177954: 2015-04-19 13:42:08 GMT-5 | orphan 177954: 2015-04-19 13:41:50 GMT-5 | orphan 177954: 2015-04-19 13:41:27 GMT-5 | orphan
|
|
|
A new release is scheduled to be applied to production this evening. This update requires all the stratum services to be restarted. Your client may disconnect for a few minutes. If you have backup pools setup, your client may momentarily fall back to one of those secondary pools and resuming mining on the primary pool a few minutes later.
|
|
|
Approximate Speed: 0 H/s
where the fuck did the hash go?
The current implementation of the statistics relies on the availability of shares pulled from the database. Every so often, two things happen that cause a 'zero' or 'inaccurate' result. Note, that in both instances there is no effect on your rewards. - When shares get flushed from the database, there may be times where nothing is left to use for calculating statistics.
- The replicated slave falls behind.
The first issue was a bug, and a fix is being applied as I write this. front end totally stuck,again... It's being worked on
|
|
|
|