I have an Idea for a random source:
Lets take the previous blockhash and the Grain adress of the miner and hash it.
something like this: hash(previous_block_hash + Grain_adress).
The greedy miner would first have to search for a proper Grain adress for his miner in order to receive the nex superblock.
Maybe you can design it to be very difficult to find the next proper adress for the superblock, like:
if hash(previous_block_hash + Grain_adress) contains "99999" = superblock
You could also add a superblock difficulty:
if no superblocks are found for a long time, the superblockdifficulty goes down, lets say from must_contain = "99999" to must_contain to "9999".
You could make it very very hard for a block to be a superblock, but every single block could be a superblock and the greedy miner would be fucked.
lets call it: "Proof of luck".
You can't do this, as the computation needs to be exactly the same for all clients, that's where the network agree and form the blockchain. So you can't take Grain address into it. Every client in the network can read the adress of the blockfinder from the transaction in the block or not? You would verify a block by checking the adress of the blockfinder from the coinbase transaction and not by your own adress. And you need to check the transactions. If not, then a miner could add any amount of coins to the coinbase transaction. You can do that with the last transaction, related to the block creation. But there's no diff than you do it with last block hash. It's just a random number hash, you combine different values or not, no difference there. Anyone who want to write a program to check that can do exactly what you do in the client. No additional protection or encryption. |
|
|
|
I have an Idea for a random source:
Lets take the previous blockhash and the Grain adress of the miner and hash it.
something like this: hash(previous_block_hash + Grain_adress).
The greedy miner would first have to search for a proper Grain adress for his miner in order to receive the nex superblock.
Maybe you can design it to be very difficult to find the next proper adress for the superblock, like:
if hash(previous_block_hash + Grain_adress) contains "99999" = superblock
You could also add a superblock difficulty:
if no superblocks are found for a long time, the superblockdifficulty goes down, lets say from must_contain = "99999" to must_contain to "9999".
You could make it very very hard for a block to be a superblock, but every single block could be a superblock and the greedy miner would be fucked.
lets call it: "Proof of luck".
You can't do this, as the computation needs to be exactly the same for all clients, that's where the network agree and form the blockchain. So you can't take Grain address into it. |
|
|
|
Technically, he is not wrong,
because of everybody mine at same time for the super block.
I want to concern the super block reward system should be improved to avoid this kind of special miner.
I know as lucky 7 coin are using similar way,
And lotto or the others are using pure random instead of use the previous data.
Maybe, somebody use a special miner, just monitor the hash value, and, if it find a super block chance,
Just put all hash power, and, go to the other coin ~
maybe he utilize couple of coins at same time ~
And, i think it is just one address,
there are couple of more,
Attract points of coins
(1) price
(2) PoS
(3) Super reward
After one month,
The reward of this coin will become half,
There is not much time ~
Lottocoin and all other "superblock" coins are all using previous hash as the source of randomness. The difference between Grain/Lucky7 and other superblock coins is the Grain/Lucky7 counts the occurrence of certain digits in the previous hash, while all other superblock coins use previous hash as the seed for a random number. Since the random generation used here is always deterministic random (mersenne twister), with seed you can always find what the random number will be. Thus there's no difference here: once you know the previous hash, you can determine whether this current block is a superblock, and what type of the superblock. It is the same as the wallet client determines it. There's no pure random, because all the clients need to compute exactly the same results, otherwise the p2p network can not be formed. This is the basics of p2p coin.  |
|
|
|
I have mined over 130 but i just got 4 8x blocks, it is too lower than 10% of possibility, But, i found some addresses which mined the super blocks mostly, The example, (Generated) http://coinblockchain.com/grain/address/9L3nHRkKae1Xzmp47AkYcaJKGyeqioqUDN(Transfer) http://coinblockchain.com/grain/tx/f572daa89cf7c6653383b2f372e8eced23f088c9969659c4549774969106bae3#i0(Storage) http://coinblockchain.com/grain/address/9GFzZoJ4cFLVmb3mMEZhMCJfNif7DUXjLb1. Is it a special address for the super block ? Or, 2. It is an address of Super lucky person ? Or, 3. Maybe somebody have a special miner to mine the super block only, If #3, it is the very disappointed about the reward system of Grain Coin ~ Somebody just join when super-block chance with big hash, after that, He mine the other coins ~~~~~ It is why the chance if super block is so low ~~~ The superblock supposed be random, it depends on the previous block hash. So far I am not aware of anyway to grab specifically the superblocks. If someone wants to do this, he must: (a) has huge hashpower (b) monitors all the time the blockchain and calculate the previous hash conditions. If he is able to do that, then he'll be able to get superblocks of any coin, because so far all the superblocks I know of are based on the previous hash... |
|
|
|
Yes please vote, RapidBalls is a great game... Yes vote us at cryptsy, also contact them request Graincoin being added!  Voted, I like RapidBalls Thanks, more people please vote for us |
|
|
|
Yes please vote, RapidBalls is a great game... Yes vote us at cryptsy, also contact them request Graincoin being added! |
|
|
|
Q1: Because when the block is found the node informs its peers that it found a new block, but not telling the block to the peers. Then it is peers responsibility to pull the block itself from that node. This has certain latency that depends on two factors - the network latency and the participating nodes performance and current load.
Q2: because the target time is 30 seconds while the delays in propagation are quite big, so the probability of two blocks found in the same time period required to propagate the block over the network is higher than the same probability for litecoin, for example. I can't recall if it was proposed in regard to the Grain or some other coin, but the idea was to double the target time instead of forthcoming reward halving. This proposed solution should lower the orphan ratio.
about Q2, I have tracked my debug.log file, from xx:50:00 at xx:50:23 Received block 0000000f275e14b8fdb xx:50:24 Received block 00000009f2f6774c316 xx:50:25 Recieved block 3b4a224dc17a785d8fbe <- PoW xx:50:25 Reorganized new best is the matched with the previous block of #159016 xx:50:43 I have found a block xx:51:21 orphans My computer report, I found a block #159016 at xx:50:43(and got feedback on xx:50:49), it is declare the block is orphans on xx:51:25 the block has been connected at xx:50:19, and other block is connected on xx:51:21 : The block has been found on xx:50:19 : QT just reorganize the block on xx:50:21, and there is no noticed, it indicate the old chain yet : my computer waste time till xx:50:43, and found the next block : got feedback from some body on xx:50:49 : on xx:51:21, it has notified about #159016 has found already, : on xx:51:22, reorgainze the block chain, and my founds are become orphans, (1) I just lost 30 seconds (xx:50:19 ~ xx:50:49), till I found a new block, (2) It has been fixed on xx:51:21, Maybe, it will takes a time to decide as an orphan block, it can takes a time sometime (xx:50:49~xx:41:21, 33 seconds) I am not sure, Is it the normal situation ? I have to lost 61 seconds till I got the notification about #159016 which has found 62 seconds ago ? The height of block racing can be happen with extremely low diff and large hashes, becuase of there is no time gap to share the information between QTs Is it possible on this coin now ? and, such a frequently ? To process a block how long latency will be needed ? I can agree about explaination, because of your explaination is absolutely right, but, my question is it is not fit on the current situation, if there are couple of seconds of time-gap, maybe yes, but, there are 20-30 seconds of time-gap, and didn't aware somebody found a new block ? and, fixed after next block ? I can not agree it is normal, If just happen once, maybe I can say, even difficult but can happen, but, it is happen 2-3 times every hours ? AGAIN, I do not talk about Techincally Possible or Not, Becasue of technically possible, But, I am asking Why too frequently ? Anyway, the dev think it is normal for this coin, and it is normal. and, I remebered the dev say this is normal. so, at least, it is normal for this coin, so, I do not want to mention about it again, What you described is perfect normal in all the coins. The time it takes for the network to negotiate depends on your network status and others network status. There is a predefined algorithm to determine which is the winner blocks/chains, and it is perfect fine and justified for everyone, as the same algorithm is applied in all case. Just to give you an historical example: WorldCoin, one of the top alt coins, had one incident a few months ago: one of the major mining pools in EU, because of the network connectivity issues related to some network, mined for 5 hours, and created a 462 block chain fork, this chain, became orphans after 5 hours of some blocked mined and confirmed 500+ times. This happens, and it happens in all coins. I don't see for GRA it is any different, from the data you posted. |
|
|
|
Whenever I start the wallet it freezes and I get not responding. I've restarted and re installed. Same problem. Was working fine yesterday.
I've noted since a few days ago that my wallet freezes constantly and uses more cpu than before... Unfortunately I can't even test the issue as I have no Windows. However, Bosian said that he did not note anything similar. Also, there is a post regarding freezes: I am having a lot of trouble running the 1.4 wallet with minting. I am running windows 7 and if I unlock it for minting it goes to non responsive.... Any ideas?
having same trouble, mostly when another running wallet grabs the focus. try: task manager>processes tab>sort by name, right click [grain]>set priority>DO NOT USE REALTIME  usually works for me, the realtime setting freezez my comp. Changing priority does nothing. It's really strange because before the cpu load was high only when started and then was minimal while stayed open. Now it's constantly high and "not responding" most of the time... Had no problems with my wallet at any point. When I run the wallet it has some effect on gaming but once it has synced it runs smoothly. Using windows 8.1. I think I will try to make a FAQ that could be added to OP as the same problems keep popping up on every 2nd page. Yes FAQ will be a good idea. As many questions are asked by different people and answered many times in the thread. |
|
|
|
|
At low diff it seems that it may have a lot orphans, but the block time is ok. When diff goes up the orphan seems goes down. Looks like the diff adjusting scheme is still not perfect. This situations also seen in many other pow/pos coins too.
|
|
|
|
Dear Bosian,
I didnt say, that the pool steals the coins.
I said, that the share difficulty of the pool jumps too high for my miner (300-400 Kh/s), so that I cant compute the shares fast enough for the short rounds.
This means, that when the round only takes 10 seconds and my GPU needs 20 seconds to find a share of min. 128 share difficulty, then I get nothing from this round, because i didnt submited any shares.
[...]
OK, thanks for clarifying. Unfortunately we can not fix the diff. The diff is determined from the previous real block time. bobbyb is talking about pool/share diff, not GRA network diff. The shares that the pool is offering are of too high a difficulty for his hashing speed, so his miner is often still working on solving a share when the network (or pool) finds the block solution. He gets paid zero for that block since he didn't submit a completed share, even though his miner has done SOME work on it. I see, this makes sense. Thanks. |
|
|
|
Dear Bosian,
I didnt say, that the pool steals the coins.
I said, that the share difficulty of the pool jumps too high for my miner (300-400 Kh/s), so that I cant compute the shares fast enough for the short rounds.
This means, that when the round only takes 10 seconds and my GPU needs 20 seconds to find a share of min. 128 share difficulty, then I get nothing from this round, because i didnt submited any shares.
If the share difficulty would stay at 32, then my miner would be able to find those shares faster and get also payed for the short rounds.
share diff 32 = 0,00048828125 diff
share diff 128 = 0,001953125 diff
share diff 256 = 0,00390625 diff
Those share difficulties may work for slow miners for 2.5 for 1 minute block target coins, but Grain has at the moment a block target <20 seconds (pow and pos).
Many rounds only take 1-5 seconds on forkpool, this is too fast for my miner to find shares at such high share difficulty.
Image if the last round took 1000% of the estimated round time and found a normal block and then the next one only takes 5% of the estimated time and finds a superblock.
This would be a nice compensation, but no. The share diff was too high, your miner didnt find any valid shares for this round due to the high share difficulty and you get nothing for the short round.
Have fun with the next long round...
And you cant solo mine with such a slow miner, because you get >50% orphans.
I am only asking the pool operator for a lower and stable share difficulty.
OK, thanks for clarifying. Unfortunately we can not fix the diff. The diff is determined from the previous real block time. I am not sure the recent diff increase is due to more hashpower, or if it is due to an algorithm issue. I am more thinking of the former, as the current price of GRA make it possibly one of the most profitable coin. The team is looking at this problem. Again, we can not fix the diff, otherwise you may get every second a block, it will mess up everything. The current block time is about 20 sec, that's why the diff is going up. But if you look at only PoW block, it is about 40-60 sec as block time, which is pretty reasonable. Though there are certain orphans, the minted block count is reasonable and within the designed range. The problem you described is why we need a pool. And the time to find a block is not fixed, it is random. |
|
|
|
MPOS (web interface) updating completed on gra.forkpool.com. If you have any problems, contact with me by online chat on site. Hi, Is it possible to get a static share difficulty of 32 or 64? I am mining with 300-400 kH/s and I mostly get nothing from short rounds (<30% of expected shares), because the share difficulty often changes to 128 or 256. It is kinda shitty if you mine the whole 1000% round and in the next short round you just get nothing, because you didnt submit a share fast enough due to the high share difficulty. Kind regards, bobbyb It is a good idea. I think all troubles with shares archive fixed now, and i will try make new settings for vardiff tomorrow. Possible i will try to decrease base target, this is settings increase shares per round. The share difficulty jumps still to 128, this is too high for 330 kH/s and 20 sec. block times (at the moment even 14 sec!) and average round times of 70 sec.  hmm interesting. I took a look at a particular block (block 150314) that you said not received. When I look at the block explorer, it says that the block 150314 is paid 1415 coins and sent to address 9Kvkbie3addSc3PGpdcQyKumQBRFKkSV2R. This address receives it: http://coinblockchain.com/grain/address/9Kvkbie3addSc3PGpdcQyKumQBRFKkSV2Rlooking at the activity of this address, it is a pool address. Then after some time, the coins 1415 are transferred out of the wallet (at block 150377 - this is 63 blocks later, should be a payout from the pool). This is cleared a transfer out, as it paid 0.02 GRA tx fee. I saw a lot small transfer out, is your wallet secure? hope it's not transferred out by a bot. (Note: I looked at it again, it's the pool payout to miners). And it looks like a payout to the miners. So anyway, the block 150314 is fine, you should have received its coins and already paid out to miners. I got nothing for this round, because the share difficulty was too high and I didnt submited any shares for this round. Yes it is a pool, its forkpool. A share difficulty of 32 or 64 would be nice. Vardiff jumps to 128 or 256 are too much. But from the blockexplorer, this is the trace of the 1415 coins from block 150314: minted at block 150314, sent to 9Kvkbie3addSc3PGpdcQyKumQBRFKkSV2R. Then later, the 1415 coins are sent from 9Kvkbie3addSc3PGpdcQyKumQBRFKkSV2R to two other addresses: 9Cji8S3hzCmQJUjFfWkoe8XggTkLtrgnKY: 194.553719 9CKy36m54nMYAx66NsgnrKr47J18uzggvM: 1220.426281 The transaction is http://coinblockchain.com/grain/block/000000001ab18da64639ad270f9bea52a108a3d77b9d9707b26712d78c7841bcand you can follow the links to further track where are these coins. |
|
|
|
MPOS (web interface) updating completed on gra.forkpool.com. If you have any problems, contact with me by online chat on site. Hi, Is it possible to get a static share difficulty of 32 or 64? I am mining with 300-400 kH/s and I mostly get nothing from short rounds (<30% of expected shares), because the share difficulty often changes to 128 or 256. It is kinda shitty if you mine the whole 1000% round and in the next short round you just get nothing, because you didnt submit a share fast enough due to the high share difficulty. Kind regards, bobbyb It is a good idea. I think all troubles with shares archive fixed now, and i will try make new settings for vardiff tomorrow. Possible i will try to decrease base target, this is settings increase shares per round. The share difficulty jumps still to 128, this is too high for 330 kH/s and 20 sec. block times (at the moment even 14 sec!) and average round times of 70 sec. hmm interesting. I took a look at a particular block (block 150314) that you said not received. When I look at the block explorer, it says that the block 150314 is paid 1415 coins and sent to address 9Kvkbie3addSc3PGpdcQyKumQBRFKkSV2R. This address receives it: http://coinblockchain.com/grain/address/9Kvkbie3addSc3PGpdcQyKumQBRFKkSV2Rlooking at the activity of this address, it is a pool address. Then after some time, the coins 1415 are transferred out of the wallet (at block 150377). This is cleared a transfer out, as it paid 0.02 GRA tx fee. I saw a lot small transfer out, is your wallet secure? hope it's not transferred out by a bot. (Note: I looked at it again, it's the pool payout to miners). And it looks like a payout to the miners. So anyway, the block 150314 is fine, you should have received its coins and already paid out to miners. |
|
|
|
I am having a lot of trouble running the 1.4 wallet with minting. I am running windows 7 and if I unlock it for minting it goes to non responsive.... Any ideas?
having same trouble, mostly when another running wallet grabs the focus. try: task manager>processes tab>sort by name, right click [grain]>set priority>DO NOT USE REALTIME usually works for me, the realtime setting freezez my comp. Thanks... I will give it a go Hope this will be fine. Sometimes the CPU usage from pos mining can be extreme, but usually it is fine, like my wallets they mine pos every 1-2 weeks, and do not take much CPU. In most case they do not mine by themself as I guess there's no qualified coin-day available in them. |
|
|
|
One more shop accepting Graincoin: Crypto Coin Stuff - Cryptocoin banners, stickers etchttp://www.cryptocoinstuff.comwe now have 14 shops/services accepting Graincoin (listed in OP). |
|
|
|
One more shop added Graincoin in its accepted payment list: Citrus Fit - Weight loss and detox products http://citrusfit.com/you can order their products now with Graincoin! |
|
|
|
I guess, there is a kind of trap, it is very hard to be in,
and you and me are in those hole,
Anyway, if possible we have to find a way to escape for the others ^^
Has it improved for you? In the past couple of hours I can only see 7 small corrections (one PoW lost) and one slightly larger correction that orphaned 3 blocks. In the 2 hours before that there were 65+ PoS corrections. T-4 to T-2 had 65+ small to medium corrections T-2 to T-0 had 8 small corrections Bit of a difference? I have restarted around hour ago, I have removed all, and started agin from sync. I have to check on tomorrow ^^ good luck... I've been mining, seems the diff now is OK, it was shot up for a while, but now it seems more reasonable. |
|
|
|
If you look at the genaretd PoS/PoW blocks, they are normal. If one PoW becomes orphan, the PoW block time will increase, which could cause the diff to decrease, and next block is easier. From the PoW block generation frequency, the target block time is within the designed range, I don't see anything abnormal.
See above for a PoS block that orphaned 7 PoW blocks. It was generated nearly 2 minutes after the first PoW block that it orphaned. Please look at the average block time of PoW blocks, everything is as designed. |
|
|
|
|
If you look at the genaretd PoS/PoW blocks, they are normal. If one PoW becomes orphan, the PoW block time will increase, which could cause the diff to decrease, and next block is easier. From the PoW block generation frequency, the target block time is within the designed range, I don't see anything abnormal.
|
|
|
|
Voted for and liked on Cryptsy Forum. Is there an IRC channel available for grain? Would anyone be interested in one? Could be useful to spread information and updates until the forums/subreddit pickup speed.
sure would be good to have an IRC. |
|
|
|
|
Show Posts
