Been a while since I last updated everyone, CureCoin is still chugging along as always  The new security technology I've alluded to earlier will be releasing in late January as a public beta, along with a public beta of cc2.0 using it. Timeline after that depends on community feedback and how stable everything is. More announcements to come soon, sorry everything is so under-wraps. |
|
|
|
// remove round 8 for maximum OCHO
//Round(a, b, c, d, e, f, g, h, 0xd807aa98, w8 = ReadBE32(chunk + 32));
w8 = 0;
void inline Initialize(uint32_t* s)
{
/* replace with 8's for OCHO */
s[0] = 0x88888888ul;
s[1] = 0x88888888ul;
s[2] = 0x88888888ul;
s[3] = 0x88888888ul;
s[4] = 0x88888888ul;
s[5] = 0x88888888ul;
s[6] = 0x88888888ul;
s[7] = 0x88888888ul;
}
lol |
|
|
|
I noticed a miner by the name of "suprnova" came online and is finding blocks FAST. Is a pool already up?  Interesting wallet... why we show pool miner's name? looks like a privacy problem (i know I can use any name, but still what's the point to show it?) Bragging rights, and also acts as an extra nonce field to use at high hashrates to avoid work duplication rather than manipulating a coinbase transaction or reordering the transaction tree. |
|
|
|
I'll make this a Christmas-themed thread Vorksholk, thanks for your insightful comments. My answers below.Interesting. To start off with, a few questions: 1. What happens with P2Pool blocks? P2Pool blocks (ex: https://blockchain.info/block/000000000000000001a1a36ada43fb03b4eb05f30cbe94a206a4a457fb4d71e5) pay out the coinbase + transaction fees to a bunch of addresses, proportional to each's contribution to mining the block. If a P2Pool block was included in the Tic phase, would all of those miners be signing new blocks in the system? There should be a signature per block to avoid bloating the chain.Alright, so P2Pool is probably incompatible with this system, correct? 2. Does the Bitcoin network enforce proper payouts to the miners of the 144-block Tic phase as a hard consensus rule? It appears from your post ("The new block is considered valid if: ... 2. It transmits the newly generated coins and any fees due in a fair manner") that this is the case, but I wanted to make sure that this wasn't just the validity check that other miners do before signing the block. It should be part of the block validation, although mining pools would not sign an unfair block for obvious reasons.] Alright, cool. 3. Who initially assembles the block for the network to approve? Whoever assembles the block gets an advantage (get authority over transaction inclusion, can choose to include their own zero-fee transactions). If you create a system where block n in the Tac phase is assembled by the miner who mined block (n mod 144) from the Tic phase, what happens if that miner is offline? If there isn't a particular miner/signer responsible for creating any particular block, how do nodes resolve which block to sign? Miners should take turns. If the current one responsible fails to deliver a new block, the next one will take his place and so on.How would that type of failover work? Would the network need a stricter timestamp? 4. How is the 10-minute timing enforced? Do peers on the network simply not accept a block n+1 if the timestamp from the block n plus 600 seconds isn't the same as the timestamp in block n+1, and the timestamp of the new block is within a margin of error of their current (local) clock? What would prevent 'whiplash' where miners/signers see it in their best interest to sign the new block as soon as it is proposed (regardless of whether it has actually been 10 real minutes since the last block), which causes them to be creating blocks that, based on their embedded timestamp, appear as if they were made in the future? As they approach the (fairly unknown) maximum allowable clock drift that the large majority of the network will support, they slow down (or even halt) block creation for a while. Even worse, if they overstep the allowable clock drift such that some peers on the network see a new block as barely-in-range compared to their local timestamp, but other peers see the block as barely-out-of-range, is there a desynchronization problem? The cost of performing PoW generally mitigates this problem, since a miner's primary goal is getting the network to accept their block, but in this model (where producing multiple valid blocks has a cost of nearly zero, and a block that gets rejected could have the timestamp adjusted, or could just be re-broadcast later to the network again), these limits could be continually pushed without any significant cost to the miners/signers. There is an incentive to keep mining blocks within a reasonable time delta. Generating blocks too quickly would leave fees for the next competition phase. Stalling the block generation would keep the miners from getting new rewards from the next Tic phaseAs long as the block subsidy is significantly higher than the transaction fees, I could see miners generating blocks quicker than desired to get to the next Tic phase sooner (and more total coins per unit of time during Tac).5. What happens when the last block of a Tic phase is contested, with two equally-valid blocks proposed by different miners? Is strong subjectivity lost? If the two miners who created competing blocks for the last block of the Tic phase both had significant mining power in the entire Tic phase, they would actively not vote for blocks that resolve the fork against their favor, which weakens the strength of the Tac blocks against reorganizations. Once one of the two blocks is signed by the majority of the mining pools, the conflict is resolved. Some margin for collusion exists though.6. If no block at height n reaches 51% mining approval, what happens? In case of conflict, the block with more valid signatures is considered the valid one. What if two blocks are proposed, and one gets 40% approval, one gets 45% approval, and there is 15% (current) non-participation. The network decides, somehow, to accept the one with 45% approval. Then, 6 of the previously-non-participatory 15% comes online and signs the block that previously only had 40% approval (making it now 46% to the accepted block's 45%). Does the network then switch to the 46% block? What if another block has already been stacked on the 45% block; do we have any strong subjectivity to convince bootstrapping nodes of the invalidity of the rejected block despite its' higher approval? A possible solution would be to accept a block with hash proof instead, but sharing the rewards in a similar manner. However a situation like this would imply most likely a cataclism in the network since it is in the best interest of all of them keeping signing blocksEven though it is likely in the best interest of all miners to keep signing blocks, I think it's reasonable that there would be times when, say, three blocks all split approval, particularly if some somewhat-adversarial party were to carefully introduce different blocks to different parts of the network simultaneously. How would the hash proof work? 7. What about the opportunity cost for miners/signers to create deep reorganizations during the Tac period? The opportunity cost of performing a deep reorganization is drastically lower and much easier to perform during the Tac period, as a majority signature power could collude to create a deep reorganization which they sign together. They could also get unfair leverage on their signature power, because they would not sign blocks for the entire period they intended to fork later, so that they don't compete against themselves. Miners might not be particularly opposed to signing onto a reorganization, because they don't forfeit their reward by doing so (the reorganization would still pay them the same amount as before). Scenario: 25% of block signers all agree to, during the first few Tac blocks, send 1000 BTC total to an exchange and sell it. They wait for confirmations on the exchange, sell the BTC, withdraw the value in alt-coins. They then create new transactions which pay out those 1000 BTC differently (back to themselves, and some sent to the block signers who aren't part of the collusion), and create a new fork with these transactions instead. The non-colluding miners are enticed to accept the fork by signing it, because they get paid additional Bitcoin which they don't own under the current valid chain, and they don't lose their block rewards for doing so, because the new chain will still pay out the coinbase + fees proportionally to the miners. The miners also can't simply embed that spend transaction they benefit from in the current chain at a higher height, because it spends a transaction (or transactions) which were already spent in the legitimate chain. This level of collusion and crooked behavior you imagine means that the miners are destroying the underlying value of the bitcoin from which they profit, so I would not expect this situation.This might particularly be a problem if Bitcoin mining becomes unprofitable, and miners are desperate to cash out. I suppose the concern here is largely that a fork can be proposed which all miners benefit from particularly easily.8. What happens if miners/signers sign multiple competing blocks simultaneously? A punitive system which punishes miners who submit multiple competing signatures could be implemented (see the Slasher proposal for PoS), but then the punishment of those accounts would be embedded in some way in a future block, which the miner(s) being punished would not vote for, further antagonizing the mining/signing power. I don't see the advantage of signing multiple blocks at once since the reward would be the sameGenerally, signing multiple blocks wouldn't disadvantage a miner, so if a miner is offered a small extra payout, they might happily sign the new block too.9. What encourages miners/signers to sign at all, rather than go offline and hope other miners/signers don't? If a miner doesn't have to be online to get their deserved reward from each block, why would they bother validating blocks and signing? If they don't get their deserved reward from each block if they don't sign the block, then it encourages miners/signers to selectively not broadcast other miners' signatures (either so that they can get a higher reward, or to undermine other miners' profitability and get a leg up). The miners would get the reward anyway. Signing is an almost zero cost operation. Being good citizens should be enough to motivate the miners to sign.In light of the previous discussion about incentivized reorganizations, a miner electing to not participate might make the chance of such a fork (which they would benefit from) higher, without incurring any risk. In my opinion, this point/question is mostly relevant if those incentivized reorganizations are a legitimate concern. 10. What would this change do to blockchains merge-mined with Bitcoin? Since for the Tac period, they can't use regular PoW mining, would the miner responsible for creating a particular block be the one who gets to merge-mine other chains? In the event that there isn't one delegated miner of each block, miners would all propose blocks in which they receive the merge-mining rewards from merge-mined chains, and wouldn't vote on anyone else's. I haven't considered merge mining at all, so I can't really say anything meaningful about this point. Also, what about the case of compromised signing keys? If some adversarial party were to quietly compromise two or three large pools, they could use those identities at some point to cause a deep reorganization at nearly no cost to themselves. |
|
|
|
Interesting. To start off with, a few questions: 1. What happens with P2Pool blocks? P2Pool blocks (ex: https://blockchain.info/block/000000000000000001a1a36ada43fb03b4eb05f30cbe94a206a4a457fb4d71e5) pay out the coinbase + transaction fees to a bunch of addresses, proportional to each's contribution to mining the block. If a P2Pool block was included in the Tic phase, would all of those miners be signing new blocks in the system? 2. Does the Bitcoin network enforce proper payouts to the miners of the 144-block Tic phase as a hard consensus rule? It appears from your post ("The new block is considered valid if: ... 2. It transmits the newly generated coins and any fees due in a fair manner") that this is the case, but I wanted to make sure that this wasn't just the validity check that other miners do before signing the block. 3. Who initially assembles the block for the network to approve? Whoever assembles the block gets an advantage (get authority over transaction inclusion, can choose to include their own zero-fee transactions). If you create a system where block n in the Tac phase is assembled by the miner who mined block (n mod 144) from the Tic phase, what happens if that miner is offline? If there isn't a particular miner/signer responsible for creating any particular block, how do nodes resolve which block to sign? 4. How is the 10-minute timing enforced? Do peers on the network simply not accept a block n+1 if the timestamp from the block n plus 600 seconds isn't the same as the timestamp in block n+1, and the timestamp of the new block is within a margin of error of their current (local) clock? What would prevent 'whiplash' where miners/signers see it in their best interest to sign the new block as soon as it is proposed (regardless of whether it has actually been 10 real minutes since the last block), which causes them to be creating blocks that, based on their embedded timestamp, appear as if they were made in the future? As they approach the (fairly unknown) maximum allowable clock drift that the large majority of the network will support, they slow down (or even halt) block creation for a while. Even worse, if they overstep the allowable clock drift such that some peers on the network see a new block as barely-in-range compared to their local timestamp, but other peers see the block as barely-out-of-range, is there a desynchronization problem? The cost of performing PoW generally mitigates this problem, since a miner's primary goal is getting the network to accept their block, but in this model (where producing multiple valid blocks has a cost of nearly zero, and a block that gets rejected could have the timestamp adjusted, or could just be re-broadcast later to the network again), these limits could be continually pushed without any significant cost to the miners/signers. 5. What happens when the last block of a Tic phase is contested, with two equally-valid blocks proposed by different miners? Is strong subjectivity lost? If the two miners who created competing blocks for the last block of the Tic phase both had significant mining power in the entire Tic phase, they would actively not vote for blocks that resolve the fork against their favor, which weakens the strength of the Tac blocks against reorganizations. 6. If no block at height n reaches 51% mining approval, what happens? In case of conflict, the block with more valid signatures is considered the valid one. What if two blocks are proposed, and one gets 40% approval, one gets 45% approval, and there is 15% (current) non-participation. The network decides, somehow, to accept the one with 45% approval. Then, 6 of the previously-non-participatory 15% comes online and signs the block that previously only had 40% approval (making it now 46% to the accepted block's 45%). Does the network then switch to the 46% block? What if another block has already been stacked on the 45% block; do we have any strong subjectivity to convince bootstrapping nodes of the invalidity of the rejected block despite its' higher approval? 7. What about the opportunity cost for miners/signers to create deep reorganizations during the Tac period? The opportunity cost of performing a deep reorganization is drastically lower and much easier to perform during the Tac period, as a majority signature power could collude to create a deep reorganization which they sign together. They could also get unfair leverage on their signature power, because they would not sign blocks for the entire period they intended to fork later, so that they don't compete against themselves. Miners might not be particularly opposed to signing onto a reorganization, because they don't forfeit their reward by doing so (the reorganization would still pay them the same amount as before). Scenario: 25% of block signers all agree to, during the first few Tac blocks, send 1000 BTC total to an exchange and sell it. They wait for confirmations on the exchange, sell the BTC, withdraw the value in alt-coins. They then create new transactions which pay out those 1000 BTC differently (back to themselves, and some sent to the block signers who aren't part of the collusion), and create a new fork with these transactions instead. The non-colluding miners are enticed to accept the fork by signing it, because they get paid additional Bitcoin which they don't own under the current valid chain, and they don't lose their block rewards for doing so, because the new chain will still pay out the coinbase + fees proportionally to the miners. The miners also can't simply embed that spend transaction they benefit from in the current chain at a higher height, because it spends a transaction (or transactions) which were already spent in the legitimate chain. 8. What happens if miners/signers sign multiple competing blocks simultaneously? A punitive system which punishes miners who submit multiple competing signatures could be implemented (see the Slasher proposal for PoS), but then the punishment of those accounts would be embedded in some way in a future block, which the miner(s) being punished would not vote for, further antagonizing the mining/signing power. 9. What encourages miners/signers to sign at all, rather than go offline and hope other miners/signers don't? If a miner doesn't have to be online to get their deserved reward from each block, why would they bother validating blocks and signing? If they don't get their deserved reward from each block if they don't sign the block, then it encourages miners/signers to selectively not broadcast other miners' signatures (either so that they can get a higher reward, or to undermine other miners' profitability and get a leg up). 10. What would this change do to blockchains merge-mined with Bitcoin? Since for the Tac period, they can't use regular PoW mining, would the miner responsible for creating a particular block be the one who gets to merge-mine other chains? In the event that there isn't one delegated miner of each block, miners would all propose blocks in which they receive the merge-mining rewards from merge-mined chains, and wouldn't vote on anyone else's. |
|
|
|
Yes you shouldn't need to pay for any accounts, PM me or proletariat and we'll send you them for free.
You can also PM me for a free account Has anyone had any problems depositing coins to Cryptopia? It says to use Account#143351-30 for deposits but why don't I see that number in the Account Explorer?
One trade is for .00002998 and the next is for .00001300, is it common with these coins to have such a disparity in the trading price?
Are you on the latest version of the wallet? The checksum for accounts changed with a recent update |
|
|
|
|
WTSC / 100000 / 2000 sats / 2.0 BTC
|
|
|
|
Hey, devices are numbered starting from 0, so try d0 instead of d1. First thing I tried. Then it's Error: too many resources requested for launch
Error: too many resources requested for launch
Error: too many resources requested for launch Ahh, then your GPU isn't powerful enough to mine, unfortunately. |
|
|
|
Hey, devices are numbered starting from 0, so try d0 instead of d1. |
|
|
|
Invalid new block 27000: Invalid target found:29EA65F7 actual:31EA6701
06/11/2016 06:33:17.001 TID:00001B80 [Error] <TNetClient> Received a distinct block, finalizing: Block:27001 Timestamp:1477864862 Reward:1000000 Fee:0 PoW:00000000000177A53F51A04B2E18CD8A168C7A74DA03047F63DDD8AA8162FEC6 (My block: Block:26999 Timestamp:1477864728 Reward:1000000 Fee:0 PoW:00000000002E3887BBF6C59A936B64BCFC303FC441475EC3EA28BDA59204F60F)
06/11/2016 06:33:17.829 TID:0000193C [Info] <GetNewBlockChainFromClient> My blockchain is ok! Need to download new blocks starting at 27000
06/11/2016 06:33:19.187 TID:00001B80 [Error] <TPCOperationsComp> Invalid new block 27000: Invalid target found:29EA65F7 actual:31EA6701
06/11/2016 06:33:19.187 TID:00001B80 [Info] <TNetClient> Distinct operation block found! My:Block:26999 Timestamp:1477864728 Reward:1000000 Fee:0 PoW:00000000002E3887BBF6C59A936B64BCFC303FC441475EC3EA28BDA59204F60F remote:Block:27000 Timestamp:1477864774 Reward:1000000 Fee:0 PoW:0000000000155485C26462872C6F926C192B1DE2D8C2B5D3EDEA34B8C6E7B92C Errors: Invalid target found:29EA65F7 actual:31EA6701
06/11/2016 06:33:19.187 TID:00001B80 [Error] <TNetClient> Received a distinct block, finalizing: Block:27001 Timestamp:1477864862 Reward:1000000 Fee:0 PoW:00000000000177A53F51A04B2E18CD8A168C7A74DA03047F63DDD8AA8162FEC6 (My block: Block:26999 Timestamp:1477864728 Reward:1000000 Fee:0 PoW:00000000002E3887BBF6C59A936B64BCFC303FC441475EC3EA28BDA59204F60F)
maybe still connection problem. how can i get more connection? and get through
It looks like, for some reason, your client isn't validating block 27000 (PoW target isn't good enough?), and so it can't build any blocks after that. I wonder if this has something to do with daylight savings time? |
|
|
|
|
Hey everyone, so that update I was talking about with our security technology:
We announced at Money 20/20 (one of the world's largest financial technology conferences) under the name VeriBlock, and we allow any blockchain to secure itself with the security of Bitcoin. Still can't say how we do it since we're semi-stealth, but here's what we're not:
-Not merged-mining
-Not existing on the Bitcoin blockchain itself
Currently two solutions exist to inherit security from Bitcoin:
Merged Mining requires that you get miners on board, and it's a sort of "fake" security, in that the opportunity cost for Bitcoin miners to attack you is very low--they can still mine Bitcoin while attacking your merge-mined chain. Additionally, you don't get the full security of Bitcoin, only the percentage of mining power you can convince to actually set up the process. It's not scalable for a lot of blockchains, because Bitcoin miners don't want to track a lot of other, lower-value blockchains to perform merged-mining anyhow.
Embedded Blockchains are embedded in the Bitcoin blockchain itself. Using the blockchain essentially requires using a modified version of the Bitcoin client which also understands the seemingly-arbitrary data embedded in Bitcoin. It's secure, but incredibly expensive to do, and also not particularly scalable (you generally end up making a Bitcoin transaction whenever you create a transaction on the embedded blockchain, because the Bitcoin blockchain needs to have data written to it).
So, we aren't those. We don't have the opportunity-cost issues of merged-mining, we don't have the scalability problems of merged-mining and embedded blockchains. We don't require Bitcoin miners to be aware or involved at all. That's a taste of what's to come.
|
|
|
|
what windows is that .... this is 2016 man win7 x64 man my windows 7 x64 looks like that, themes disabled too but the wallpaper is just solid black. your miner name is "pascalcoin" that's 10 characters... you should rename miner using 8 characters like "pascalco", in your wallet too rename the miner name to 8 characters and always mine with this key (8 characters too) when you create a key use the "secp256k1" I did everything you wrote but a miner and does not start In your PascalCoin wallet,when you open Project -> Operations, what is the miner name in the box? pascalco What directory is your PascalProxyv2.jar file in, and do you run it by double-clicking on it? |
|
|
|
what windows is that .... this is 2016 man win7 x64 man my windows 7 x64 looks like that, themes disabled too but the wallpaper is just solid black. your miner name is "pascalcoin" that's 10 characters... you should rename miner using 8 characters like "pascalco", in your wallet too rename the miner name to 8 characters and always mine with this key (8 characters too) when you create a key use the "secp256k1" I did everything you wrote but a miner and does not start In your PascalCoin wallet,when you open Project -> Operations, what is the miner name in the box? |
|
|
|
Who feels like we should be donating some coinage to Vork for doing all this crazy work for FREE for us?
I know he is mining himself and probably killing it, but still.
Vork, post up a BTC or whatever altcoin you want addy and let's get a donation train rolling.
No worries, I mined a lot, if you guys want to contribute to the ecosystem send a donation to the PascalCoin developer |
|
|
|
The miner also can't find the headerout and datain files, is the miner in the exact same directory as the proxy is running from? Why is the proxy a folder? |
|
|
|
Now that the AMD miner is out, be prepared to pay a lot more for coins.  Why? Same supply as before. Really wish the prices would go a little higher in this thread. Because more people will be mining with more hardware, since most miners have AMD cards. So more people consuming more resources to split the same daily pool of PascalCoin. |
|
|
|
I'm still mining and getting nonces. Just no blocks being found. My miners seem to have an issue finding the same nonce multiple times and submitting it over and over. It seems odd even with a larger farm that this miti person is getting most of the blocks. Only about 80,000 MHs total right now and I am mining with 6,000-7,000 MHs of the networks total. This is an image of just one rig hashing with 4 GPUs. http://imgur.com/2o9jwngTry adding the argument "c60" or "c30" to each one, do you still get duplicates? The duplicates are caused by the miner not stopping to get work before exhausting the nonce range (and then starting over). Lowering the cycle count will let it get work more often. |
|
|
|
Quick note for anyone wondering about my config that I tested this miner on:Windows 7 x64 Ultimate Latest AMD Driver (Crimson 16.10) GTX 1080 and RX 480 installed (1080 attached to display, RX 480 not connected to display, platform 1) RADEON 7970 are MURDERING this coin at 800MH/S
what intensity? Everything is default. Doesn't work on RX470/RX480 Does it give any kind of an error, or just crash? I can get it to mine with 1 GPU, but the other 3 don't run. Trying to set up another user account now and syncing the wallet to test if it will work for targeting the 2nd GPU. Opening multiple miners with different device targets didn't work on an account together. The first card runs at 100%, but the others are at 0% doing nothing. Also noticed when I find a nonce it finds and submits the same nonce 6 or 7 times in a row.
If you're seeing duplicated nonces, try decreasing intensity and/or cyclesize. So the benchmark only works on 1 GPU, cant test on any other GPUs.
Good catch--unfortunately probably can't fix for the next few days, since I'm traveling. If anyone else has Visual Studio or similar set up to compile AMD OpenCL host code (aka AMD app sdk installed, IDE configured), they could follow the instructions in the readme to make the benchmark version. Additionally, anyone can open the .cl file and change the single F in the targetY = 0xF0000000 line, which will make shares go 16x faster. Then mine with the normal miner, and divide the output number by 16 to get actual hashrate (but shares will be fast enough to work for benchmarking purposes, just not as nice). This coin is very good with Tahiti based GPUs like 7950 / 7970 / 280X
Bad for 290 / 470 / 480 / Any Pitcairns
That's really weird--I developed and tested the miner only on an RX 480 system. Maybe those GPUs had better instruction sets for mining, or the compilers from OpenCL to device kernels were better optimized for mining on older devices where SHA-256 mining was more relevant and AMD developers wanted to get more of an edge for their cards to increase sales? @Vorksholk
Hey mate , My 480s are crashing all the time , Ive tried everything ( underclock , undervolt , etc) , bur did not try change the driver.
Which driver you are using ?
Crimson 16.10, does it give any kind of error or just crash? Did you make sure your device and platform arguments were correct? Thanks, Vorksholk!
My R9290X (Hawaii) crashed quickly for all intensities from 23 down to 10. It seems to be stable at intensity 4, running cool at over 80% GPU usage.
I'll start working intensity back upwards again Real Soon Now to find a sweet spot.
Edit: Update - intensity 9 looks stable, whereas 10 was not in an earlier test. I'll do more careful checking as time permits, but for now the sweet spot for this rig seems to be i9.
Huh, what hash rate are you getting at intensity 9 on that card? help me please  i don't understand that characters..read the readme file of the miner. install the latest java run time environment so you can run "PascalProxyv2.jar" and input the right syntax (it is in the readme.txt file)  I did everything according to the instructions but I did not start out miner Yeah, the miner name you set in the Pascal Wallet needs to be 8 characters, it's not the name of the miner .exe file itself. I can only assume someone is attacking us again with huge hashing power. 4X increase in less than 3 hours. I put 6,000 MHs on mining and haven't gotten a block in 3 hours...
Attacking... or just mining a ton for their own benefit. Probably just someone with a large AMD farm who wants some Pascal ------------------------------------------------------------------------------ For anyone interested, the current difficulty (2Cxxxxxx) implies a network hashrate of ~58 GH/s, and the current blockrate at this difficulty implies a hashrate of ~100 GH/s. That's about 512x the speed of a few weeks ago.
|
|
|
|
OpenCL miner is here!https://github.com/Vorksholk/PascalCoin-OpenCL/releases/download/v1.00/PascalCoin_OpenCL_ProxyMiner_v1.zipGetting about 550 MH/s on an RX 480 with stock clocks.For anyone thinking about CPU mining, an i7-5820k overclocked used to get about 8 MH/s. Instructions very similar to PascalCoin CUDA Proxy miner. Here they are: To use this miner:
1. You must already have PascalCoin installed. If you don't have it, download it from sourceforge here: https://sourceforge.net/projects/pascalcoin/. Once it is installed, run the PascalCoinWallet.exe provided in the download.
2. You must be using a 256-bit secp256k1 key. This is the default behavior of the PascalCoin wallet.
3. Your miner name must be exactly 8 characters long. The miner expects that the input is exactly 176 total bytes (which is achieved by using a secp256k1 key and a 10-character name) NOTE: NOT 10 like before! 8 characters, because the last two will be used to identify each GPU!
4. You must have RPC enabled in your client (any port of your choosing, default is 4009)
5. You must run the proxy miner (PascalProxyv2.jar) in the same directory as the PascalCoinCUDA_ProxyMiner_smXX.exe file you run (everything is where it needs to be if you just extract the provided zip). For most people, the host should be 127.0.0.1, and the port should be 4009. Enter the same 8-character miner name you put in your PascalCoin wallet.
6. Open one or more (one for each GPU) copy of PascalCoinOpenCL_ProxyMiner.exe by cd-ing to this directory in a command prompt, and running PascalCoinOpenCL_ProxyMiner.exe.
The miner takes four arguments: device (d), platform (p), intensity (i), and cyclesize (c).
For example: PascalCoinOpenCL_ProxyMiner.exe d0 p0 i23 c50
would run the miner on platform 0, device 0, with an intensity of 23 and a cyclesize of 50.
Higher intensities are more demanding on the GPU. Additionally, too high of an intensity can cause the miner to actually decrease in effective hashrate.
The cyclesize has a minimal affect on hashrate generally.
Unless you have a special setup (like NVidia and AMD cards in the same system), your platform is probably 0. You can determine which platform and device to use from the output at the original miner's start.
You can also run the benchmark miner (in the Benchmark folder) to try out different devices and intensity/cyclesize arguments. If you are compiling from source and want to make the benchmark version instead of the normal mining version, comment out the lines responsible for writing to the datainXX.txt file, (optionally) change the header file you read from to a single name regardless of device name, change the line
printf("Found nonce: %08x T: %08x Hashrate: %.3f MH/s Total: %d\n", nonce, timestamp, (((((double)totalNonces) * 4 * 16 * 16 * 16 * 16) / (4)) / (((double)getTimeMillis() - start) / 1000)), totalNonces);
to
printf("Found nonce: %08x T: %08x Hashrate: %.3f MH/s Total: %d\n", nonce, timestamp, (((((double)totalNonces) * 4 * 16 * 8) / (4)) / (((double)getTimeMillis() - start) / 1000)), totalNonces);
and modify the .cl code by changing the lines:
uint targetX = h0 & 0xFFFFFFFF;
uint targetY = h1 & 0xF0000000;
to
uint targetX = h0 & 0xFFFFFF70;
uint targetY = h1 & 0x00000000;
This essentially lets the code find nonces 512 times faster, and accounts for the 512-times-faster-sharerate by reducing how many hashes it expects each nonce solve to take by a factor of 512, while removing the overhead of writing files (since writing a few files a second may cause it to be slower).
If you notice your miner finding several of the same nonce, try lowering the intensity and/or cyclesize (because you're sending so much work to the GPU that it can't get a timestamp often enough, so it exhausts the 4-ish billion possible nonces (~4 GH), and starte repeating work).
|
|
|
|
It's interesting to see what will happen. In the end, in my opinion, potential worldwide merchant acceptance is really the only thing that pushes coins to the top of the market cap. And that simply cannot happen with the current centralized CureCoin 1.0 . .
In my opinion it's sad that the CC team was somehow lacking ambition for CC2.0... Indeed their aim should have been to create THE ULTIMATE COIN that would send to trashcan all the useless global-warming-increasing GPU-based coins out there and concurrence Bitcoin, because being the ultimate cryptocurrency would push the coin to the top of the market cap and conversely offer tens, maybe hundreds of GPPD to F@H. But for CC2.0 to be the ultimate cryptocurrency, I think they should: - Remove all the flaws of CC 1.0 (mainly the premine -> DONE) - Not add flaws in CC 2.0 (the certification authorities) - Add massive advantages over Bitcoin (either new or inspired from other popular coins): - Protection against quantum computing (DONE) - Block time under 30s to allow effective payments - Anonymous transactions (Vorksholk argued that it might allow illegal stuff, but cash payments in US$ allow it too and they don't help F@H in compensation) Maybe SigmaX or CC3.0 will be the ultimate coin... And then, having the technically ultimate coin that moreover helps F@H, CC's PR should contact all major merchants accepting Bitcoin and convince them accepting Curecoin. Let me preface this by saying these are really good debates to have--and if you have specific ideas to address some of the concerns (namely certificates and WU validation of a dynamic WU system), we'd love to hear and discuss them. Here's how we're currently seeing these issues: Currently, the certificate system looks like the best way to be able to validate peoples' contributions to scientific computation networks. Bitcoin works because PoW uses SHA-256D which everyone can validate--they know the exact requirements and validation procedure for any PoW. Since the very nature of scientific computing is large workloads which continually evolve and change format (not everyone is folding the same molecule in the same way--in fact, aside from redundancy, no one is), this means of decentralized work validation isn't possible. It's really a tradeoff--technically it's possible to create a PoW based on validating a computation related to simulating a single molecular system, but then it's unusable as a means of scientific research because research teams can't change the molecule, can't change what about it is being simulated, etc. They also can't improve the software (aside from optimizing the software to produce the same results faster), and the workloads would have to be unimaginably small to be practical PoW targets (because everyone needs to recompute them). It's also a DDoS vulnerability to the network, because people could pretend to mine a ton of blocks with bogus WUs, and everyone would have to recompute the entire WU to see that it's false. With Bitcoin it's nanoseconds to compute a double-SHA256 hash. With even a small molecular simulation it's on the scale of seconds to minutes, which means someone could submit a few bogus blocks to the network, and the entire network would spend an hour frozen while it reprocesses every WU just to find out that they weren't valid PoW submissions. We also couldn't have a short blocktime for this reason, because even the slowest full nodes would need to validate blocks much faster than they are transmitted, and making the PoW validation require more than a trivial amount of time requires that the blocktime leaves a large enough window to ensure that peers aren't being "buried" by PoW validations, even ignoring the DDoS factor. We are considering a pretty fast blocktime--in the range of 1 to 2 minutes. 30s might be a bit short, but our goal is to get it as low as reasonably possible without causing any issues on the network. Anonymous transactions aren't our goal. Thanks for your answer and the news!! While I understand that you wanted to remove SHA256D PoW from CC2.0 because it is a waste of electricity, adding a third party in the loop (the certification authorities, who in the case of F@H we are not even sure are willing to participate, even though the recent results of Curecoin team might help convincing them) goes against the concept of decentralization which is one of the pillars of the success of blockchain technology and Bitcoin. If we want to replace Bitcoin someday, we need the trust of investors so they get ready to buy lots of M$ of Curecoin. And for that we should be as decentralized as possible and not have vulnerabilities Bitcoin doesn't have (a third party is a potential vulnerability and even if the problems an outside hacker or an insider at Stanford might create could be a posteriori corrected in the blockchain it would create hassle, would make bad publicity for the coin and make its value drop...). As far as motivation, CureCoin is waiting for a technology I'm currently working on to become available that will drastically improve CureCoin's network security. The technology isn't built for CureCoin specifically, but for the entire ecosystem to use, and CureCoin will be one of the first adopters. Update to come very soon (Tuesday) about what exactly the technology is. Haha, nice teaser!! On Tuesday we're going to break the record of people reading this topic! We're certainly open to ideas if anyone can think of a way to enable universities and other research institutes to still create work for which miners are rewarded without involving certificates (or a central service which just holds Curecoin and pays it out). The announcement on Tuesday will clarify why a certificate blockchain isn't a problem for network security (double-spends, blockchain forking, etc.) though The main issue with the certificate blockchain is simply a university being able to give themselves more Curecoin than they should be getting--it doesn't let them attack the consensus of the network to any concerning degree with the technology we're working on. |
|
|
|
|
Show Posts
