Topic: [PRE-ANN][HVC] Heavycoin - Ultra-secure, Decentralized Block Reward Voting, Fast - page 25. (Read 140040 times)
March 08, 2014, 04:04:31 AM
How is an IPO bad? NonMiners can invest in something they believe in
March 08, 2014, 04:02:26 AM
everyone will set it to high. it is naive to say the least to think people will set low values. its human nature. so what use is the voting?
this coin might soon be targetted by botnets.
this coin might soon be targetted by botnets.
You have to assume anyone who invested into the IPO is going to have the wallet installed on as many computers as possible with a 0 block reward.
If the block reward isn't high, I will stop mining.
Someone will just copy this coin and I will mine that one without the IPO.
March 08, 2014, 03:58:29 AM
everyone will set it to high. it is naive to say the least to think people will set low values. its human nature. so what use is the voting? do you really think that voting will fluctuate price?
this coin might soon be targetted by botnets.
this coin might soon be targetted by botnets.
March 08, 2014, 03:54:44 AM
Anyone mining this coin should set the coin reward to as high as possible.
Higher block reward = Miners make more money.
Higher block reward = Miners make more money.
A low reward means less coins but higher $ valuation. 2 sides to this selfish story
March 08, 2014, 03:53:20 AM
lol war of Miners and IPOers. Miners might destroy this coin
March 08, 2014, 03:52:53 AM
Anyone mining this coin should set the coin reward to as high as possible.
Higher block reward = Miners make more money.
Higher block reward = Miners make more money.
March 08, 2014, 03:20:41 AM
The source won't be released until launch. We are trying to providing binaries (for pool mining software) ahead of the launch, so pool operators can make sure everything is up and running.
In addition to mining (and voting) with the GUI wallets, you can use an external miner. For that, we've created a Heavycoin fork of cpuminer.
The external miner gets to write his/her block reward vote into the block. The block reward vote is specified with the -v parameter.
Your vote cannot exceed the maximum allowed block reward vote of 1024. Also, if your vote exceeds the current maximum block reward vote, then you will generate invalid blocks. This is not really a problem because the maxvote only changes in the final (Sustain) phase of decentralized voting. At that distant future you will simply relaunch your external miners with at vote between 0 and 8.
For those unsatisfied with this, the -m option allows the external miner to automatically cap his vote to the maximum permitted vote of the current voting phase. For example if you had -v 1024 and the maxvote reported by the pool was 8, then your block reward vote would be capped to 8. However, we do not recommend using this option unless you really trust the pool (ie. you own it). A dishonest pool operator could try to cheat by sending out an artificially lower maxvote, which would cause all the votes from external miners with the -m flag to be capped at a false maxvote. So really don't use this flag unless you are the pool operator.
Note
For pool mining, the block's vote could be set by the pool software or the external miners. However, we decided to make vote casting part of the external miner, rather than part of the pool software. If the vote for a given block were calculated and set by the pool software, then there would be scope for malicious pool operators to cheat and skew votes in a way that favors them. By allowing the external miners to write their votes directly into the block, we put the voting power in the hands of the individual miners, rather than the pool operators.
A malicious pool operator could still reject blocks from external miners whose votes they do not like; however, this condition would be easily (and publicly) detectable because of the discrepancy between the hashing power of the external miner and the number of his blocks accepted by the pool. It would be the same as stealing blocks or assigning a false shares. In practice it should be very hard for a pool to cheat like this without being found out and becoming very unpopular!
In addition to mining (and voting) with the GUI wallets, you can use an external miner. For that, we've created a Heavycoin fork of cpuminer.
Code:
Usage: minerd [OPTIONS]
Options:
-a, --algo=ALGO specify the algorithm to use
scrypt scrypt(1024, 1, 1) (default)
sha256d SHA-256d
heavy Heavycoin hash
-v, --vote=VOTE block reward vote
-m, --trust-pool trust the max block reward vote (maxvote) sent by the pool
The external miner gets to write his/her block reward vote into the block. The block reward vote is specified with the -v parameter.
Your vote cannot exceed the maximum allowed block reward vote of 1024. Also, if your vote exceeds the current maximum block reward vote, then you will generate invalid blocks. This is not really a problem because the maxvote only changes in the final (Sustain) phase of decentralized voting. At that distant future you will simply relaunch your external miners with at vote between 0 and 8.
For those unsatisfied with this, the -m option allows the external miner to automatically cap his vote to the maximum permitted vote of the current voting phase. For example if you had -v 1024 and the maxvote reported by the pool was 8, then your block reward vote would be capped to 8. However, we do not recommend using this option unless you really trust the pool (ie. you own it). A dishonest pool operator could try to cheat by sending out an artificially lower maxvote, which would cause all the votes from external miners with the -m flag to be capped at a false maxvote. So really don't use this flag unless you are the pool operator.
Note
For pool mining, the block's vote could be set by the pool software or the external miners. However, we decided to make vote casting part of the external miner, rather than part of the pool software. If the vote for a given block were calculated and set by the pool software, then there would be scope for malicious pool operators to cheat and skew votes in a way that favors them. By allowing the external miners to write their votes directly into the block, we put the voting power in the hands of the individual miners, rather than the pool operators.
A malicious pool operator could still reject blocks from external miners whose votes they do not like; however, this condition would be easily (and publicly) detectable because of the discrepancy between the hashing power of the external miner and the number of his blocks accepted by the pool. It would be the same as stealing blocks or assigning a false shares. In practice it should be very hard for a pool to cheat like this without being found out and becoming very unpopular!
March 08, 2014, 03:20:16 AM
All my CPU are belong to HVC
March 08, 2014, 03:17:52 AM
What size do you suggest?
I would say that miners with low hash rates should try to equalize a potential high reward voting from those with heavy hash rates.
Now if the heavy hash rate miners are also voting for small block sizes... then it will be a totally different ball game... but very interesting at the same time!
So what would you suggest for voting, for someone who has very low hash rate, as they only have a standalone PC
March 08, 2014, 03:10:33 AM
So cpuminer will be released at launch ?
It takes a long time to configure it on each rig...
It takes a long time to configure it on each rig...
March 08, 2014, 03:01:29 AM
The source won't be released until launch. We are trying to providing binaries (for pool mining software) ahead of the launch, so pool operators can make sure everything is up and running.
In addition to mining (and voting) with the GUI wallets, you can use an external miner. For that, we've created a Heavycoin fork of cpuminer.
The external miner gets to write his/her block reward vote into the block. The block reward vote is specified with the -v parameter.
Your vote cannot exceed the maximum allowed block reward vote of 1024. Also, if your vote exceeds the current maximum block reward vote, then you will generate invalid blocks. This is not really a problem because the maxvote only changes in the final (Sustain) phase of decentralized voting. At that distant future you will simply relaunch your external miners with at vote between 0 and 8.
For those unsatisfied with this, the -m option allows the external miner to automatically cap his vote to the maximum permitted vote of the current voting phase. For example if you had -v 1024 and the maxvote reported by the pool was 8, then your block reward vote would be capped to 8. However, we do not recommend using this option unless you really trust the pool (ie. you own it). A dishonest pool operator could try to cheat by sending out an artificially lower maxvote, which would cause all the votes from external miners with the -m flag to be capped at a false maxvote. So really don't use this flag unless you are the pool operator.
Note
For pool mining, the block's vote could be set by the pool software or the external miners. However, we decided to make vote casting part of the external miner, rather than part of the pool software. If the vote for a given block were calculated and set by the pool software, then there would be scope for malicious pool operators to cheat and skew votes in a way that favors them. By allowing the external miners to write their votes directly into the block, we put the voting power in the hands of the individual miners, rather than the pool operators.
A malicious pool operator could still reject blocks from external miners whose votes they do not like; however, this condition would be easily (and publicly) detectable because of the discrepancy between the hashing power of the external miner and the number of his blocks accepted by the pool. It would be the same as stealing blocks or assigning a false shares. In practice it should be very hard for a pool to cheat like this without being found out and becoming very unpopular!
In addition to mining (and voting) with the GUI wallets, you can use an external miner. For that, we've created a Heavycoin fork of cpuminer.
Code:
Usage: minerd [OPTIONS]
Options:
-a, --algo=ALGO specify the algorithm to use
scrypt scrypt(1024, 1, 1) (default)
sha256d SHA-256d
heavy Heavycoin hash
-v, --vote=VOTE block reward vote
-m, --trust-pool trust the max block reward vote (maxvote) sent by the pool
The external miner gets to write his/her block reward vote into the block. The block reward vote is specified with the -v parameter.
Your vote cannot exceed the maximum allowed block reward vote of 1024. Also, if your vote exceeds the current maximum block reward vote, then you will generate invalid blocks. This is not really a problem because the maxvote only changes in the final (Sustain) phase of decentralized voting. At that distant future you will simply relaunch your external miners with at vote between 0 and 8.
For those unsatisfied with this, the -m option allows the external miner to automatically cap his vote to the maximum permitted vote of the current voting phase. For example if you had -v 1024 and the maxvote reported by the pool was 8, then your block reward vote would be capped to 8. However, we do not recommend using this option unless you really trust the pool (ie. you own it). A dishonest pool operator could try to cheat by sending out an artificially lower maxvote, which would cause all the votes from external miners with the -m flag to be capped at a false maxvote. So really don't use this flag unless you are the pool operator.
Note
For pool mining, the block's vote could be set by the pool software or the external miners. However, we decided to make vote casting part of the external miner, rather than part of the pool software. If the vote for a given block were calculated and set by the pool software, then there would be scope for malicious pool operators to cheat and skew votes in a way that favors them. By allowing the external miners to write their votes directly into the block, we put the voting power in the hands of the individual miners, rather than the pool operators.
A malicious pool operator could still reject blocks from external miners whose votes they do not like; however, this condition would be easily (and publicly) detectable because of the discrepancy between the hashing power of the external miner and the number of his blocks accepted by the pool. It would be the same as stealing blocks or assigning a false shares. In practice it should be very hard for a pool to cheat like this without being found out and becoming very unpopular!
March 08, 2014, 02:58:20 AM
March 08, 2014, 02:57:18 AM
What size do you suggest?
March 08, 2014, 02:43:48 AM
Could someone tell me where to download the CPU miner at launch time, will it be available on http://heavycoin.github.io/download.html ?
March 08, 2014, 02:27:38 AM
My rig farm has a total of 300 cores at 3.5ghz (approx). Should I be looking at solo or pool mining at launch time?
With 3 hours of no reward mining, it will give pools plenty of time to get up and running. I would say solo mining would be very hard with the amount of interest in this coin.
May I suggest solo at the first hours then come to join us heavycoin.zhpool.com
March 08, 2014, 02:26:00 AM
Only about 4.5 hours left, exciting!
March 08, 2014, 01:41:33 AM
My rig farm has a total of 300 cores at 3.5ghz (approx). Should I be looking at solo or pool mining at launch time?
Where do you get such a rig farm? 
I would advise you to look into other cryptocurrencies at this time
March 08, 2014, 01:30:12 AM
Everyone should be on IRC!
We're having a POOL party
Freenode - #HeavycoinPool and #Heavycoin - join now
We're having a POOL party
Freenode - #HeavycoinPool and #Heavycoin - join now
I'm ON !!!!!!!!!!
March 08, 2014, 01:23:25 AM
I'm ON !!!!!!!!!!
March 08, 2014, 01:20:21 AM
We shall my friend! We shall!
#heavycoin now has a few more users. I've also made cryptomind and crypt0h4z3 ops (without their permission but hey) (from #heavycoinpool), I won't be around then so hopefully they can help manage the channel !
!Jump to: