so far i can tell 7000 BTC is resting in these 7 wallets (each 1000 BTC) and the rest (170 BTC) has been mixed further down in smaller and smaller amounts.. 1MgM7WMAVteJ3k4PqfyB9AKdaBnHvdxvdG 14kgEXiKWCN46BEHVNwYjyuohFN83Uc5Jt 1AFbZuU5PufViRhNCChw8br6beo6K78r2H 1KPNHv8mfMPNivHptAiwwytUVZmzovVF8f 1J4TJQKgh1phPMcsV8cbRkAhV2Q6V8wW25 1Q2MxBc9Zbe6A35mTcD5jyU8PMr4K6oqGC 1Muse5NL7nDPPHVreF2Gkq5wv5XLbC2Qtz So the thief will be "saving" 7000 while he tries to get swap 170 btc now.. yeah its weird that the thief isnt touching those 7000 any further, maybe he is using it as leverage with BTER ? returning them to BTER for a certain price ? tbh i dont know what to think about it. |
|
|
|
so far i can tell 7000 BTC is resting in these 7 wallets (each 1000 BTC) and the rest (170 BTC) has been mixed further down in smaller and smaller amounts.. 1MgM7WMAVteJ3k4PqfyB9AKdaBnHvdxvdG 14kgEXiKWCN46BEHVNwYjyuohFN83Uc5Jt 1AFbZuU5PufViRhNCChw8br6beo6K78r2H 1KPNHv8mfMPNivHptAiwwytUVZmzovVF8f 1J4TJQKgh1phPMcsV8cbRkAhV2Q6V8wW25 1Q2MxBc9Zbe6A35mTcD5jyU8PMr4K6oqGC 1Muse5NL7nDPPHVreF2Gkq5wv5XLbC2Qtz |
|
|
|
|
darkcoin is rising again, hopefully steaming towards 0.012 (although a big sell awaits us at 0.0115999)
|
|
|
|
From what we can tell there's a uncommon condition on the network (seems to be about 1 in 10 clients), where some databases have became corrupt. Please check your logs for these messages:
--
2015-02-15 17:34:26 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large
OR
2015-02-15 17:34:26 ERROR: ReadBlockFromDisk : Errors in block header
---
If you find entries like that delete ~/.darkcoin/blocks and chainstate, then resync from the bootstrap:
https://github.com/UdjinM6/darkcoin-bootstrap
Thanks 
i had those two days ago .. they must have caused my MN to stop working back then. I remember someone else complaining about these errors back then .. i did a reindex with version .25 and had no problems anymore. 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Deserialize or I/O error - ReadCompactSize() : size too large 2015-02-13 22:33:07 ERROR: CheckProofOfWork() : nBits below minimum work 2015-02-13 22:33:07 ERROR: ReadBlockFromDisk : Errors in block header 2015-02-13 23:02:08 |
|
|
|
Evan : i found a lot of them in my normal wallet (not a MN wallet) when i started it up just now.
2015-02-15 16:06:13 ProcessBlock: ACCEPTED
2015-02-15 16:06:13 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:06:13 CheckBlock() : skipping masternode payment checks
2015-02-15 16:06:13 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:06:13 CheckBlock() : skipping masternode payment checks
2015-02-15 16:06:13 UpdateTip: new best=000000000002129735ab9c6a64ac95d3d5483a261943f83f75f153ae458bc53f height=220605 log2_work=60.99049 tx=866830 date=2015-02-15 15:08:26 progress=0.999325
2015-02-15 16:06:13 ProcessBlock: ACCEPTED
Later on they disappear and turn into ''CheckBlock() : Found masternode payment 220624'' for example.
2015-02-15 16:16:51 ProcessBlock: ACCEPTED
2015-02-15 16:16:53 mnw - winning vote CTxIn(COutPoint(e3ae3784bf5b18997895f278f174870a77333c5bd5dcb18695b2e912f2eab78c, 1), scriptSig=) Height 220633 bestHeight 220623
2015-02-15 16:17:00 spork - new 0cd8b35cf3d8e12fb749a8bdd9d5e533d42ea84306aa2d3e0c93d6171c0c1114 ID 10000 Time 1420126342 bestHeight 220623
2015-02-15 16:17:01 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:17:01 CheckBlock() : Found masternode payment 220624
2015-02-15 16:17:01 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:17:01 CheckBlock() : Found masternode payment 220624
2015-02-15 16:17:01 UpdateTip: new best=0000000000002b06f0b8bfe973d77031f999c2a4087ec31e631db2a45c4c901d height=220624 log2_work=60.990674 tx=866914 date=2015-02-15 16:16:51 progress=0.999998
2015-02-15 16:17:01 ProcessBlock: ACCEPTED
so i assume my wallet received your spork settings and there is no need to sent you the debug.log ?
I was very vague, These are OK: 2015-02-15 15:56:43 CheckBlock() : skipping transaction locking checks 2015-02-15 15:56:43 CheckBlock() : Found masternode payment 220620 2015-02-15 15:56:43 CheckBlock() : skipping transaction locking checks 2015-02-15 15:56:43 CheckBlock() : Found masternode payment 220620 2015-02-15 15:56:43 UpdateTip: new The ones I'm looking for look like this, and they must be after block 220625: 2015-02-15 04:58:45 ProcessBlock: ACCEPTED 2015-02-15 04:58:45 CheckBlock() : skipping transaction locking checks 2015-02-15 04:58:45 CheckBlock() : skipping masternode payment checks 2015-02-15 04:58:45 CheckBlock() : skipping transaction locking checks 2015-02-15 04:58:45 CheckBlock() : skipping masternode payment checks 2015-02-15 04:58:45 UpdateTip: new best=000000000007397b7b443996254c0ae2bec814edb474fa9658ac3bf4a68e7d5d height=220310 log2_work=60.987778 tx=865814 date=2015-02-15 02:27:51 progress=0.998236 thats very clear.. thanks |
|
|
|
|
Evan : i found a lot of them in my normal wallet (not a MN wallet) when i started it up just now.
2015-02-15 16:06:13 ProcessBlock: ACCEPTED
2015-02-15 16:06:13 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:06:13 CheckBlock() : skipping masternode payment checks
2015-02-15 16:06:13 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:06:13 CheckBlock() : skipping masternode payment checks
2015-02-15 16:06:13 UpdateTip: new best=000000000002129735ab9c6a64ac95d3d5483a261943f83f75f153ae458bc53f height=220605 log2_work=60.99049 tx=866830 date=2015-02-15 15:08:26 progress=0.999325
2015-02-15 16:06:13 ProcessBlock: ACCEPTED
Later on they disappear and turn into ''CheckBlock() : Found masternode payment 220624'' for example.
2015-02-15 16:16:51 ProcessBlock: ACCEPTED
2015-02-15 16:16:53 mnw - winning vote CTxIn(COutPoint(e3ae3784bf5b18997895f278f174870a77333c5bd5dcb18695b2e912f2eab78c, 1), scriptSig=) Height 220633 bestHeight 220623
2015-02-15 16:17:00 spork - new 0cd8b35cf3d8e12fb749a8bdd9d5e533d42ea84306aa2d3e0c93d6171c0c1114 ID 10000 Time 1420126342 bestHeight 220623
2015-02-15 16:17:01 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:17:01 CheckBlock() : Found masternode payment 220624
2015-02-15 16:17:01 CheckBlock() : fork detected, skipping transaction locking checks
2015-02-15 16:17:01 CheckBlock() : Found masternode payment 220624
2015-02-15 16:17:01 UpdateTip: new best=0000000000002b06f0b8bfe973d77031f999c2a4087ec31e631db2a45c4c901d height=220624 log2_work=60.990674 tx=866914 date=2015-02-15 16:16:51 progress=0.999998
2015-02-15 16:17:01 ProcessBlock: ACCEPTED
so i assume my wallet received your spork settings and there is no need to sent you the debug.log ?
|
|
|
|
A short update about enforcement
As it turns out the enforcement code and strategy worked fine, but it just appears some clients lost the spork settings and other clients were coming and going and never received them. This is pretty easy to resolve, simply by having the reference node frequently send out spork settings to the network.
We've turned back on enforcement and everything looks fine so far. If you want to help out just look for "CheckBlock() : skipping masternode payment checks" in your logs. If you see that, shoot me an email to evan@darkcoin.io with your debug.log. thats certainly a relief .. and wearthy of many rebumps |
|
|
|
Maybe the hacker will buy some drk and start mixing. Isn't that the smart thing to do? Lol
I didn't want to say that. But yes. Looks like drk goes up again, so....meaby it is his scope... I also thought about that. thats gonna be one spectacular rise if the hacker puts all his stolen BTC in DRK |
|
|
|
Seems like enforcement is back online  i'm not sure, a hour ago someone still managed to pay only 20% MN fees. |
|
|
|
|
do you guys think they can repay customers that amount of stolen BTC ? It is one of the more bigger exchanges in China
but if they can pay $1.756.650 .. what do you think ?
|
|
|
|
Pls contact Evan or UdjinM6 directly about this. This needs to be sorted out at dev team level i think also see page 4198 for info about enforcement off (just stumbled upon it, i guess the discussion with njs811 took some pages ) |
|
|
|
wtf has my pool paid MN 60% last 2 blocks, while some jerkoff is back to paying none?
that 60% is weird though, shouldnt even be possible. I suggest you provide Evan with your debug.log edit : i checked both MN addresses that got paid those 60% according website drk.mn and both just received 1.74 DRK on the 15th of feb, so it looks like they were actually paid according 37.5 % https://drk.mn/blocks.htmlfound blocks : 220484 & 220429 XyLz1jG5mUy93hK1QDcPZ6DqDqLvWdEF4A paid to random MN: XjkuayokN6t7V2FxaM81t9gP6aBgHzJNAo Xe98kvZ7MNNsVBbVF7MpgYv1oiKAm67sRy And another at 60% http://explorer.darkcoin.io/block/00000000000b96c470468ba586538be558528a58237ec5d507ee1f5ca953e883What a piss off. also 1.74 drk MN payment (in accordance with 37.5%) , i think drk.mn is showing incorrect info |
|
|
|
wtf has my pool paid MN 60% last 2 blocks, while some jerkoff is back to paying none?
that 60% is weird though, shouldnt even be possible. I suggest you provide Evan with your debug.log edit : i checked both MN addresses that got paid those 60% according website drk.mn and both just received 1.74 DRK on the 15th of feb, so it looks like they were actually paid according 37.5 % https://drk.mn/blocks.htmlfound blocks 220484 & 220429 : XyLz1jG5mUy93hK1QDcPZ6DqDqLvWdEF4A paid to random MN's: XjkuayokN6t7V2FxaM81t9gP6aBgHzJNAo Xe98kvZ7MNNsVBbVF7MpgYv1oiKAm67sRy |
|
|
|
What is the maximum amount of MNs available on the system? Is there a limit?
There is no artificial limit like 1440 or something which would centralize the coin to the hands of the rich few. PS. are you sure you're not one of child harold's puppets? Though I do agree with you that does drive the price of a coin up. Making it an interesting investment. Edit: and I don't know who that is. also the % of blocks going towards MN payments is going up per month which should have an impact on the price as well Masternodes increase payments if(nHeight > 158000) ret += blockValue / 20; // 158000 - 25.0% - 2014-10-24 if(nHeight > 158000+((576*30)* 1)) ret += blockValue / 20; // 175280 - 30.0% - 2014-11-25 if(nHeight > 158000+((576*30)* 2)) ret += blockValue / 20; // 192560 - 35.0% - 2014-12-26 if(nHeight > 158000+((576*30)* 3)) ret += blockValue / 40; // 209840 - 37.5% - 2015-01-26 if(nHeight > 158000+((576*30)* 4)) ret += blockValue / 40; // 227120 - 40.0% - 2015-02-27 if(nHeight > 158000+((576*30)* 5)) ret += blockValue / 40; // 244400 - 42.5% - 2015-03-30 if(nHeight > 158000+((576*30)* 6)) ret += blockValue / 40; // 261680 - 45.0% - 2015-05-01 if(nHeight > 158000+((576*30)* 7)) ret += blockValue / 40; // 278960 - 47.5% - 2015-06-01 if(nHeight > 158000+((576*30)* 9)) ret += blockValue / 40; // 313520 - 50.0% - 2015-08-03 if(nHeight > 158000+((576*30)*11)) ret += blockValue / 40; // 348080 - 52.5% - 2015-10-05 if(nHeight > 158000+((576*30)*13)) ret += blockValue / 40; // 382640 - 55.0% - 2015-12-07 if(nHeight > 158000+((576*30)*15)) ret += blockValue / 40; // 417200 - 57.5% - 2016-02-08 if(nHeight > 158000+((576*30)*17)) ret += blockValue / 40; // 451760 - 60.0% - 2016-04-11 |
|
|
|
- would like to see the windows wallets sync and download as fast and as problemless as on Linux (which is impressively fast).
crowning : I'm not sure if this is a Darkcoin problem...ALL my wallets sync way faster on Linux.
Maybe the windows GUI during sync is just starting to many processes at once, i wonder if it would be more efficient / faster if we decouple longterm syncing with the loading of the GUI wallet. With long syncs (longer than a day perhaps? ) make it sync first and only show some simple loading / syncing screen and once synced start all other processes of the GUI, including further syncing ofc. edit : just my thoughts, i dont have much techn knowledge / code knowledge so i have no idea if what i describe above is even remotely possible or even necessary. GUI performance issues should be fixed in 0.11.2.x spoiler: Performance Pack is already there https://github.com/darkcoin/darkcoin/pull/177  thanks.. good to know. nice job. |
|
|
|
- would like to see the windows wallets sync and download as fast and as problemless as on Linux (which is impressively fast).
crowning : I'm not sure if this is a Darkcoin problem...ALL my wallets sync way faster on Linux.
Maybe the windows GUI during sync is just starting to many processes at once, i wonder if it would be more efficient / faster if we decouple longterm syncing with the loading of the GUI wallet. With long syncs (longer than a day perhaps? ) make it sync first and only show some simple loading / syncing screen and once synced start all other processes of the GUI, including further syncing ofc. edit : just my thoughts, i dont have much techn knowledge / code knowledge so i have no idea if what i describe above is even remotely possible or even necessary. |
|
|
|
here are some of my own thoughts on future wallet improvements :
- would like an option to create certain blockchain points, lets call them reindex restore points (like how windows use restore points).
you can then select to restore the blockchain through re-index to a state for example of a week ago and dont need to have the whole blockchain re-indexed
I'll do backups of the blockchain for this. Integrating this into the wallet would be more convenient, though. - would like to see important commandline options integrated in the GUI wallet (zapwallettxes, reindex, rescan) so you can activate them on next restart
through the click of a button.
http://jira.darkcoin.qa/browse/DRK-139 - would like some info about possible new updates available in the GUI wallet so users will know its time to update
The original Bitcoin/Litecoin reference implementation had this, so I guess (but don't know) that it's also available in Darkcoin, but is just not used. - would like to see the windows wallets sync and download as fast and as problemless as on Linux (which is impressively fast).
I'm not sure if this is a Darkcoin problem...ALL my wallets sync way faster on Linux. thanks for your reply, the restart wallet options you propose on jira look great !! (just needs the reindex there as well .. but i think its just an example yr showing there ?) |
|
|
|
|
here are some of my own thoughts on future wallet improvements :
- would like an option to create certain blockchain points, lets call them reindex restore points (like how windows use restore points).
you can then select to restore the blockchain through re-index to a state of for example a week ago and dont need to have the whole blockchain re-indexed
- would like to see important commandline options integrated in the GUI wallet (zapwallettxes, reindex, rescan) so you can activate them on next restart
through the click of a button.
- would like some info about possible new updates available in the GUI wallet so users will know its time to update
- would like to see the windows wallets sync and download as fast and as problemless as on Linux (which is impressively fast).
Right now windows wallets often require restarts to get a good syncing (even when on latest wallet version 61000) and are sluggish during sync (again even with wallet version 61000). This one is mostly adressed right now with v0.11.2.x on Github i think .. but i'm not totally sure.
|
|
|
|
|
Show Posts
