 Show Posts
|
|
Pages: « 1 [2] 3 4 5 6 »
|
Could someone please host a blockexplorer for GRAIN?
I hope I will do it soon. btw, what is your urgent need? The best chain atm is 6301b91955eefe8ca952eb0080f1debdaf8dcd232257eebd0cc41e85f8578de6 at height 1057216 A blockexplorer is the basic service for a coin. Without an explorer people will think that GRAIN is just a joke. BTW: How many connections do you get? I know, that it's a basic service. I had no time during the summer time to set up one. For past couple of months I had about 10. In May-June it used to be 17. I am having only 4 connections. EDIT: I forgot the port forwarding in my new router, I am getting more connections now. |
|
|
|
Could someone please host a blockexplorer for GRAIN?
I hope I will do it soon. btw, what is your urgent need? The best chain atm is 6301b91955eefe8ca952eb0080f1debdaf8dcd232257eebd0cc41e85f8578de6 at height 1057216 A blockexplorer is the basic service for a coin. Without an explorer people will think that GRAIN is just a joke. BTW: How many connections do you get? |
|
|
|
|
Could someone please host a blockexplorer for GRAIN?
|
|
|
|
Anyway, if the network hash rate is bigger than 200M, this coin will be stable.
But, just 50-100Mh now,
I disagree with this statement. From what I saw, how the network behaves. I think that due the low block time, the network cannot distibute the mined block fast enough and we get orphans. Even with a high hahsrate, the network will always have a big amount of orphans due to the low block time. I believe, that in order to make Grain stable, we need a block time of at least 60 seconds. There is a good reason, why the major coins have a such high block time and not 30 seconds or less. Grain has now a block time of 15-25 seconds, this cant be stable. |
|
|
|
|
Something is wrong with the network.
My local Grain blockchain is always out of sync.
Edit:
This coin is just broken as shit.
Pow + Pos + very low block time = too unstable
Forks of 20-50 blocks are just too much.
I'm holding my 1.3M grain, because its pointless to sell it for almost nothing.
|
|
|
|
My wallet runs really slow and I think it's because I have 2400+ transactions.
Do you guys think I should make a new wallet and send my GRA to it? Think that might speed it up?
I did it and it helped. |
|
|
|
|
Is Mega down?
Bosian, can you please provide some mirrors for the client?
I am anly getting a blank screen with firefox.
EDIT: OK, i turned RC4 on and it works.
|
|
|
|
|
I have solo mined for 18h: 72 stale/invalid, 16 orphans and 4 accepted.
Never gonna mine it again
|
|
|
|
The coin appears working fine. The PoW diff a bit low, which may cause some orphans, but the mining should be fine...
anyway please post any issues you experience.
Hi Bosian, several people have problems with the Grain client. It gets a single core to 100% load and freezes the whole time. Its not just the GUI, the grain daemon doesn't respond to cgminer, you cant mine with it. Its not a full freeze, it freezes for 2-3 minutes, works for 2 seconds and freezes again. I had to create a new wallet in order to make the client usable again. I assume, that a huge ammount of PoS matured inputs is causing this. The client is not freezing, as long the wallet is locked. Do you have a clue how to fix this or should I just transfer my Grain to the new wallet and lose the coinage? I am using the windows client. Thanks! |
|
|
|
What the hell is wrong with the GRA wallet? It crashes all the time. Looks like the whole hashrate became so low because lots of wallets have crashed.
It does not even crash, it just is constantly "not responding". Can't even syncronize. Its propably the PoS algorithm, it works, when the wallet is locked and it also works if you create a new wallet. |
|
|
|
But the fair miner, with const address, has to have 1%. How is it works with your algo?
Hmm not so well  My idea sucks, its only resulting in PoW of generating adresses. I focused only on the greedy miner problem and forgot the fair miners. Sorry for wasting your time. |
|
|
|
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. There is a difference, vecause every miner has a different adress. The greedy miner cant just start to mine, if the last block was lucky, because the blocks are no longer lucky, the miner adress is now lucky or unlucky. He must have a lucky adress in order to generate a valid coinbase transaction with x64 amount of coins. In order to to generate a valid x64 coinbase transaction everytime, he first needs to search for a lucky adress. The normal miner will just mine with the same adress everytime and be hoping to get lucky. If you made it very hard to find a valid proof of luck, then the greedy miner cant profit from his permanent search for the lucky adress. If searching for a adress, that can solve if hash(previous_block_hash + Grain_adress) contains "99999" = superblock (or something like this) would take longer, than the average block time, then the search for the lucky adress would be pointless. The verificaton could work like this: 0. Current block is #230000. 1. Miner has adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj2. Miner generates his proof of luck: proof_of_luck_hash = hash(hash of block_#23000 + 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj) 3. Miner checks for superblock: if proof_of_luck_hash contains "99999" = superblock // in this case the proof_of_luck_hash containes the string "99999" so the proof of luck is valide, if not, then the miner can only create a valid transaction with 1x amount of coins, not x64 to the adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj. 4. Miner makes coinbase transaction with 64x amount coins to adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj and generates PoW. 5. Miner finds block #230001 and broadcasts it. 6. Client A receives the block #230001. 7. Client A generates the proof of luck for the block #23001 to be verified: proof_of_luck_hash = hash(hash of block_#23000 + adress of coinbase transaction_of_block_#230001) // adress of coinbase transaction is 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj8. Client A verifies the superblock: if proof_of_luck_hash contains "99999" = superblock // the proof_of_luck_hash containes the string "99999", so it is verified as a superblock and the transaction is valid. If the coinbase transaction would have only the normal 1x amount of coins and proof_of_luck_hash would not cointain "99999" (proof of work invalid), then the block would be also valid. If proof_of_luck_hash would not cointain "99999" and the coinbase transaction would have 64x amount of coins (superblock), then the block would be invalid. I am not a mathematician in a pure meaning of this term, so I might be mistaken but I see no statistical difference between the present algorithm and the one proposed by you. In your proposal the greedy miner need to do only two extra computations per block: the addition and hashing. He need not to find any lucky address but he would use the same address all the time. Then he get the same number of bonus blocks as he has now. Every miner has a different adress, but the hash of the last block is the same for everybody. Lets take these two adresses 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj and 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s. If we compute hash(previous_block_hash + Grain_adress) with each of them, we get a different result (hash) for every single adress. If we define a requirement for the proof of luck like: result hash must contain seven "9" or result hash must contain five "9" in a row ("99999"), then only a few adresses can generate a hash with a valid proof of luck. Lets say 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj would have a valid proof of luck hash from hash(previous_block_hash + Grain_adress) for the upper requirement and 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s not, only the miner with the adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj woulb be able to create a superblock with a x64 amount of coins transaction, the miner with the adress 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s could only create a transaction with x1 amount for this round. Other clients could verify this. This means, that each miner can generate a normal block with any adress, but only a few miner with a lucky adress can generate a superblock for a round. The hash of the last block differs with each round (block), because the last block is differnt, so that in the next round a different adress may be lucky. We can check the coinbase transaction to verify the miner adress. And you cant just easiely generate a adress that is lucky (valid proof of luck) for the current round, because: - You first have to generate a private key in order to generate a public key (grain adress) - You cant generate a lucky public key first (you could, the you dont have the private key to acces this adress) - You cant know if proof of luck is valid for this adress for this round, before you hash it with hash(previous_block_hash + Grain_adress) and test the result. The difference to the current algorithm: current algorithm: if the last blockhash was lucky and you find the nex block, then you find a superblock -> depends only on the previous blockhash my algorithm: each round a few miners (or none) can get a superblock, if they mine with a adress that solves proof of luck -> depends on the previous hash and the adress in the coinbase of the current block. With proof of luck, a miner cant just start to mine, after the last blockhash was lucky in order to find a superblock. Every round can result with a superblock, if the miner with the lucky adress finds the adress, but it would be unlikely, that a adress would be lucky for several round. A greedy miner could try two things: - test each round if his adress is lucky and only PoW mine if this happens - each round try to find a lucky adress by generating new adresses and only PoW mine if he finds one I think, that Grain with proof of luck would be very less profitable for miners, that only PoW mine in order to get the superblocks. 1% chance to superblock means, that every 100th address must be "lucky". Its easy to check 100 address, if they are lucky. 1% is way too high, each round could result in a superblock, so the chance must be a lot lower for a adress to be lucky. But I agree with bee7, this is just an idea and we need a mathematician to check it. I just read your idea and I think that yours is better  |
|
|
|
Every miner has a different adress, but the hash of the last block is the same for everybody.
Lets take these two adresses 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj and 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s.
If we compute hash(previous_block_hash + Grain_adress) with each of them, we get a different result (hash) for every single adress.
If we define a requirement for the proof of luck like: result hash must contain seven "9" or result hash must contain five "9" in a row ("99999"), then only a few adresses can generate a hash with a valid proof of luck.
Lets say 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj would have a valid proof of luck hash from hash(previous_block_hash + Grain_adress) for the upper requirement and 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s not, only the miner with the adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj woulb be able to create a superblock with a x64 amount of coins transaction, the miner with the adress 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s could only create a transaction with x1 amount for this round. Other clients could verify this.
This means, that each miner can generate a normal block with any adress, but only a few miner with a lucky adress can generate a superblock for a round.
The hash of the last block differs with each round (block), because the last block is differnt, so that in the next round a different adress may be lucky.
We can check the coinbase transaction to verify the miner adress.
And you cant just easiely generate a adress that is lucky (valid proof of luck) for the current round, because:
- You first have to generate a private key in order to generate a public key (grain adress)
- You cant generate a lucky public key first (you could, the you dont have the private key to acces this adress)
- You cant know if proof of luck is valid for this adress for this round, before you hash it with hash(previous_block_hash + Grain_adress) and test the result.
I got your idea from the original explanation. But really, the outcome will be the same using just one address, no need to search for some lucky address. The adding some constant (the address) to the previous block hash and then rehashing the sum just makes it a small bit harder to determine if the block is lucky or not. The distribution of the prev block hash and distribution of your function output for some fixed address is the same, so the probability to find a lucky block is the same. Moreover, we will have as many separate 'sequences' of lucky blocks as we have miners, so the number of lucky blocks will increase. If anyone knows some mathematician who could confirm or refute my conclusion I will appreciate his attention. I edited my post. |
|
|
|
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. There is a difference, vecause every miner has a different adress. The greedy miner cant just start to mine, if the last block was lucky, because the blocks are no longer lucky, the miner adress is now lucky or unlucky. He must have a lucky adress in order to generate a valid coinbase transaction with x64 amount of coins. In order to to generate a valid x64 coinbase transaction everytime, he first needs to search for a lucky adress. The normal miner will just mine with the same adress everytime and be hoping to get lucky. If you made it very hard to find a valid proof of luck, then the greedy miner cant profit from his permanent search for the lucky adress. If searching for a adress, that can solve if hash(previous_block_hash + Grain_adress) contains "99999" = superblock (or something like this) would take longer, than the average block time, then the search for the lucky adress would be pointless. The verificaton could work like this: 0. Current block is #230000. 1. Miner has adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj2. Miner generates his proof of luck: proof_of_luck_hash = hash(hash of block_#23000 + 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj) 3. Miner checks for superblock: if proof_of_luck_hash contains "99999" = superblock // in this case the proof_of_luck_hash containes the string "99999" so the proof of luck is valide, if not, then the miner can only create a valid transaction with 1x amount of coins, not x64 to the adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj. 4. Miner makes coinbase transaction with 64x amount coins to adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj and generates PoW. 5. Miner finds block #230001 and broadcasts it. 6. Client A receives the block #230001. 7. Client A generates the proof of luck for the block #23001 to be verified: proof_of_luck_hash = hash(hash of block_#23000 + adress of coinbase transaction_of_block_#230001) // adress of coinbase transaction is 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj8. Client A verifies the superblock: if proof_of_luck_hash contains "99999" = superblock // the proof_of_luck_hash containes the string "99999", so it is verified as a superblock and the transaction is valid. If the coinbase transaction would have only the normal 1x amount of coins and proof_of_luck_hash would not cointain "99999" (proof of work invalid), then the block would be also valid. If proof_of_luck_hash would not cointain "99999" and the coinbase transaction would have 64x amount of coins (superblock), then the block would be invalid. I am not a mathematician in a pure meaning of this term, so I might be mistaken but I see no statistical difference between the present algorithm and the one proposed by you. In your proposal the greedy miner need to do only two extra computations per block: the addition and hashing. He need not to find any lucky address but he would use the same address all the time. Then he get the same number of bonus blocks as he has now. Every miner has a different adress, but the hash of the last block is the same for everybody. Lets take these two adresses 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj and 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s. If we compute hash(previous_block_hash + Grain_adress) with each of them, we get a different result (hash) for every single adress. If we define a requirement for the proof of luck like: result hash must contain seven "9" or result hash must contain five "9" in a row ("99999"), then only a few adresses can generate a hash with a valid proof of luck. Lets say 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj would have a valid proof of luck hash from hash(previous_block_hash + Grain_adress) for the upper requirement and 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s not, only the miner with the adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj woulb be able to create a superblock with a x64 amount of coins transaction, the miner with the adress 9ECPZJBtbMHyfGikdUzQuf9Z8t6gGbWh5s could only create a transaction with x1 amount for this round. Other clients could verify this. This means, that each miner can generate a normal block with any adress, but only a few miner with a lucky adress can generate a superblock for a round. The hash of the last block differs with each round (block), because the last block is differnt, so that in the next round a different adress may be lucky. We can check the coinbase transaction to verify the miner adress. And you cant just easiely generate a adress that is lucky (valid proof of luck) for the current round, because: - You first have to generate a private key in order to generate a public key (grain adress) - You cant generate a lucky public key first (you could, the you dont have the private key to acces this adress) - You cant know if proof of luck is valid for this adress for this round, before you hash it with hash(previous_block_hash + Grain_adress) and test the result. The difference to the current algorithm: current algorithm: if the last blockhash was lucky and you find the nex block, then you find a superblock -> depends only on the previous blockhash my algorithm: each round a few miners (or none) can get a superblock, if they mine with a adress that solves proof of luck -> depends on the previous hash and the adress in the coinbase of the current block. With proof of luck, a miner cant just start to mine, after the last blockhash was lucky in order to find a superblock. Every round can result with a superblock, if the miner with the lucky adress finds the adress, but it would be unlikely, that a adress would be lucky for several round. A greedy miner could try two things: - test each round if his adress is lucky and only PoW mine if this happens - each round try to find a lucky adress by generating new adresses and only PoW mine if he finds one I think, that Grain with proof of luck would be very less profitable for miners, that only PoW mine in order to get the superblocks. |
|
|
|
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. There is a difference, vecause every miner has a different adress. The greedy miner cant just start to mine, if the last block was lucky, because the blocks are no longer lucky, the miner adress is now lucky or unlucky. He must have a lucky adress in order to generate a valid coinbase transaction with x64 amount of coins. In order to to generate a valid x64 coinbase transaction everytime, he first needs to search for a lucky adress. The normal miner will just mine with the same adress everytime and be hoping to get lucky. If you made it very hard to find a valid proof of luck, then the greedy miner cant profit from his permanent search for the lucky adress. If searching for a adress, that can solve if hash(previous_block_hash + Grain_adress) contains "99999" = superblock (or something like this) would take longer, than the average block time, then the search for the lucky adress would be pointless. The verificaton could work like this: 0. Current block is #230000. 1. Miner has adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj2. Miner generates his proof of luck: proof_of_luck_hash = hash(hash of block_#23000 + 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj) 3. Miner checks for superblock: if proof_of_luck_hash contains "99999" = superblock // in this case the proof_of_luck_hash containes the string "99999" so the proof of luck is valide, if not, then the miner can only create a valid transaction with 1x amount of coins, not x64 to the adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj. 4. Miner makes coinbase transaction with 64x amount coins to adress 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj and generates PoW. 5. Miner finds block #230001 and broadcasts it. 6. Client A receives the block #230001. 7. Client A generates the proof of luck for the block #23001 to be verified: proof_of_luck_hash = hash(hash of block_#23000 + adress of coinbase transaction_of_block_#230001) // adress of coinbase transaction is 9T5x6h164qpqk3s3Lunq7uAVLapQNCF7wj8. Client A verifies the superblock: if proof_of_luck_hash contains "99999" = superblock // the proof_of_luck_hash containes the string "99999", so it is verified as a superblock and the transaction is valid. If the coinbase transaction would have only the normal 1x amount of coins and proof_of_luck_hash would not cointain "99999" (proof of work invalid), then the block would be also valid. If proof_of_luck_hash would not cointain "99999" and the coinbase transaction would have 64x amount of coins (superblock), then the block would be invalid. |
|
|
|
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. |
|
|
|
|
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".
|
|
|
|
|
