If I understand the code correctly, the total target block time is 90s, not the PoW target block time. The PoW target block time is determined by this formula: (main.cpp:1045) int64 nTargetSpacing = fProofOfStake ? STAKE_TARGET_SPACING :
min(nTargetSpacingWorkMax, (int64) STAKE_TARGET_SPACING * (1 + pindexLast->nHeight - pindexPrev->nHeight)); STAKE_TARGET_SPACING is 90 (1.5 minutes) and nTargetSpacingWorkMax is 900 (15 minutes). Thus, for POS blocks, the target spacing is always set to 90 seconds (because fProofOfStake is true for POS blocks). For POW blocks, the target spacing is min(nTargetSpacingWorkMax, (int64) STAKE_TARGET_SPACING * (1 + pindexLast->nHeight - pindexPrev->nHeight)). In other words, the target spacing gets set to 90s * (2 + number_of_non_pow_blocks_since_the_last_pow_block). If this value exceeds 15 minutes, the target spacing is set to 15 minutes. => When there are many PoS blocks, the PoW block spacing gets increased in order to achieve the total average block time of 90 seconds. This feature seems to be inherited from Peercoin. Thanks for your detailed explanation. Any thoughts on total coin supply ? 250 million ? really ? PoS blocks are increasing at a very fast rate, are we to expect 15 minute PoW blocks soon ? |
|
|
|
the Reward for a POW Block i got recently was 5.x SLM should that really that low?
No, thats another GUI bug. |
|
|
|
Example blocks: 15158 (first one, afaict), 15305, 15436, 15468, 15474
Count ALL PoS blocks from height 0-15935 and 15935-19790 and you'll see what i am talking about... Now why would I count them when I already stated that, as far as I can tell, 15158 was the first one, and the graph clearly shows there were many more after the most recent fork? Besides, I still fail to see how that relates to "there were no PoS blocks before the last fork" (which is either false or true depending on which fork you were referring to), and moreover what the "this" in your post was. Anyway, as mentioned, PoW could go up to a 15 minute interval as far as the code seems to be concerned - so rather than broken, I'd suspect it's by design. There were several updates from 15000 - 15935. There were no PoS blocks when the network was healthy and when block propagation worked (up to block 15158). Then came the PoS update which killed block propagation/coin. PoW blocks were created every 90 secs up to block 15158. Quoting retard dev again : "A PoB block is found every 1-3 PoW blocks, (every 90-270 seconds). " ( https://bitcointalk.org/index.php?topic=613213.msg7019069;topicseen#msg7019069) EDIT : Specification says 250 million total coins will be created in 15 years. At the current rate 3000 coins are created per day. This number will be significantly lower every day due to higher difficulty/nEffectiveBurnCoins. 250 million in 15 years ? Not possible. |
|
|
|
You acting stupid too ? There were no PoS blocks before the last fork, it was broken.
You asked where the figures were coming from, I pointed out that it's in the code, you said that "this was implemented in the last fork". The only logical interpretation is that "this" referred to the code cited - not any potential issues with regard to any PoS dealings. As far as PoS blocks "before the last fork" goes - that depends on which fork you're referring to with "last fork". They do appear to have occurred before the most recent fork:  Example blocks: 15158 (first one, afaict), 15305, 15436, 15468, 15474 If you meant the fork before that, then sure. Count ALL PoS blocks from height 0-15935 and 15935-19790 and you'll see what i am talking about... Anyway, PoW creation time now is around 7-8 minutes. I cant wait for more PoS blocks, that should lower PoW blocks further  BROKEN, dev better fix it in the next update. |
|
|
|
If so, this was implemented in the last fork, i am 100% positive this was not the case before the fork. Fucking developer retard.
This has been in since at least the codebase of 2014/05/28, the first time I grabbed the code. (github history should show any changes there as well anyway) You acting stupid too ? There were no PoS blocks before the last fork, it was broken. |
|
|
|
Where did you get that number, out of your ass ? "Actually", looking at your pool stats (possibly bug-driven) or devs posting history?
It's in the code. main.h
STAKE_TARGET_SPACING = 90; // 90 second block spacing
main.cpp
static const int64 nTargetSpacingWorkMax = 10 * STAKE_TARGET_SPACING; // 15 minutes
Then there's a whole section that deals with the interval some more. If so, this was implemented in the last fork, i am 100% positive this was not the case before the fork. Fucking developer retard. |
|
|
|
Max target for PoW is actually 15 min. Where did you get that number, out of your ass ? "Actually", looking at your pool stats (possibly bug-driven) or devs posting history? |
|
|
|
What happened to all that Dev is an idiot, coin is DOA, you're out like 50x blah blah blah now you must've spent thousands on amazon servers and value coin pretty friggin high. Can you explain your propaganda campaign?
WTS 37,000 20BTC |
|
|
|
"networkghps" : 0.00205548, How much is this in MH/s ?
Last I checked, there were a thousand megas in a giga. So approximately 2Mhash/s. You'll want to get multiple readings over, say, an hour or so, given the constant difficulty adjustment, the estimate bounces around as well. Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ? slimcoin 2014-6-24 15:02:22 UTC 19485 000000044b6cd55ad887d022d0e3d2efdd9039d14d63408a8dcb5e14ec045bc3 9.36 immature slimcoin 2014-6-24 13:29:25 UTC 19431 00000000f7c59c2bc135a41bc7b5d7c48840acdfd354a3e52e2b8b90a716f8db 8.64 immature last two blocks pool found - 1hour 30min difference This time you are right primer  Sandor take a close look at your logfiles... That is definitely worse than "bad luck". Take some action, fast please! My first guess would be you're on a version of the node.js stratum that has the "block invalid" bug.. meaning a found block is is rejected in the stratum, but accepted in the client. Stratum and DB however do not notice that and the block is not counted at all There is nothing wrong with the pool... there are actually no blocks being rejected, all 100% submitted. Btw there were only 4 PoW blocks generated between 19431 and 19485 : 19467, 19477, 19479, 19480 It's basic statistics, primer-. If the network hashrate was 2 Mh/s, that means we would get 50% over the long run. BUT, since the sample size is only 4 blocks that means that the spread is large, so nothing alarming that the pool mined two less blocks than it was supposed to. Compare it to flipping a coin 4 times and getting 4x tail in a row. There were only 4 PoW blocks (which should spawn every 90 secs) in 1.5 hours ?? D Dont patronize me with basic statistics, instead of wasting characters about statistics you should have wrote something about a broken algo - PoW block should be created every 90 secs not one every 30 minutes! EDIT : I did check 20-30 blocks from 19431 and they all seems to be PoS or PoB.. Algo is obviously broken, PoW blocks are not created as stated in the whitepaper, one every 90 sec. What is causing this, PoS and PoB blocks ? |
|
|
|
|
MinGW bounty collected by 0xAli!!
|
|
|
|
You run several wallet with the same wallet.dat ?
Yes |
|
|
|
oh yeaaa faulty hardware. thats total bullshit. you really expect people to believe its possible for hardware to submit completely valid block solutions but absolutely no valid blocks dream on troll
Why would anyone withold myr blocks, to ruin the pool income for other miners ? You need a reality check - you're mad. |
|
|
|
I have not received a response from the myr.poolerino.com pool operators, just went in their irc with the issue but no response... people should stay away from that pool until this is resolved.
At times there is a 40TH anonymous sucker there, and at other times that speed gets broken down under several anonymous miners all with the exact speed of 2-3TH/s all of which hit no blocks.
This needs to be resolved yesterday...
Bug in stratum code or pool operator is a scammer. Forget about witholding block 'attack' there is no reason anyone would do that on purpose. What happend to btcguild was faulty hardware and ahmed knows it. |
|
|
|
now it's hard to find pob now .Currency becomes pointless to burn coins. all the supply one day reduced to about 4000 coins , too much time to find pob to get the coins back.
I have found many PoB today, make sure you are : 1. Synced 2. Minting (unlocked wallet) 3. Running the latest client I have the same problem, I am synced , Minting 24/7 and running last wallet........  Well one last trick i use is to run several wallets. I know the dev says it makes no difference but try it and post results.. |
|
|
|
now it's hard to find pob now .Currency becomes pointless to burn coins. all the supply one day reduced to about 4000 coins , too much time to find pob to get the coins back.
I have found many PoB today, make sure you are : 1. Synced 2. Minting (unlocked wallet) 3. Running the latest client |
|
|
|
|
I'm placing a 500SLM Bounty for an open source p2pool & instructions on how to install.
EDIT: dstorm was working on p2pool code, please update us on the progress.
|
|
|
|
"networkghps" : 0.00205548, How much is this in MH/s ?
Last I checked, there were a thousand megas in a giga. So approximately 2Mhash/s. You'll want to get multiple readings over, say, an hour or so, given the constant difficulty adjustment, the estimate bounces around as well. Only 2Mhash/s ?? The pool alone is doing 1Mhash/s so should be getting 50% of all PoW blocks ? Instead its hitting one block every couple of hours ?? How is this possible ? slimcoin 2014-6-24 15:02:22 UTC 19485 000000044b6cd55ad887d022d0e3d2efdd9039d14d63408a8dcb5e14ec045bc3 9.36 immature slimcoin 2014-6-24 13:29:25 UTC 19431 00000000f7c59c2bc135a41bc7b5d7c48840acdfd354a3e52e2b8b90a716f8db 8.64 immature last two blocks pool found - 1hour 30min difference |
|
|
|
|
Show Posts
