Bitcoin Forum
May 24, 2018, 01:37:01 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ... 86 »
61  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [PASC] PascalCoin, deletable blockchain & bank account system [PASA] on: January 01, 2017, 10:39:59 PM
I am using v 1.4 with 18 480s now... but no luck...

prefered intensity d0 p1 i23 c25 or i19

depends on the systems the rigs are built. No difference in mining speed though.


im also having no lucck here been trying for 2 days...sync...re-sync...linux server... wallet on windows...
4 r9 280x + 1 r9 280 tested a bunch of paramters and the result its always the same...
higher then target
can someone help im tired of this
01/01/2017 21:48:27.522 TID:00001E48 [Error] <TJSONRPCTcpIpClient> Sending Error JSON RPC id () : Error: Proof of work is higher than target payload:soulisty00 timestamp:1483307305 nonce:2266120537
01/01/2017 21:48:54.193 TID:00001E48 [Error] <TPCOperationsComp> Invalid new block 47945: Proof of work is higher than target
01/01/2017 21:48:54.193 TID:00001E48 [Error] <TJSONRPCTcpIpClient> Sending Error JSON RPC id () : Error: Proof of work is higher than target payload:soulisty01 timestamp:1483307333 nonce:1777236921
01/01/2017 21:49:07.855 TID:00000460 [Update] <TPCOperationsComp> New block height:47945 nOnce:-1949563651 timestamp:1483307344 Operations:0 Fee:0 SafeBoxBalance:47946000000=47946000000 PoW:00000000001C387E4336F0419B0011D96000252CC31905286853117C85B487DB Operations previous Safe Box hash:FC7936498E7EEE953ADFC491E76ADBEA9A359F20F5EA33107CC2AE150B7BB6B1 Future old Safe Box hash for next block:9BB6A36285D87EF12CA93C5D1AB38FE03BFA75F5D00307E95FAF5E1F97654105
01/01/2017 21:50:12.215 TID:00001E48 [Error] <TPCOperationsComp> Invalid new block 47946: Proof of work is higher than target
01/01/2017 21:50:12.215 TID:00001E48 [Error] <TJSONRPCTcpIpClient> Sending Error JSON RPC id () : Error: Proof of work is higher than target payload:soulisty02 timestamp:1483307411 nonce:1467606351
01/01/2017 21:51:16.670 TID:00001E48 [Error] <TPCOperationsComp> Invalid new block 47946: Proof of work is higher than target
01/01/2017 21:51:16.670 TID:00001E48 [Error] <TJSONRPCTcpIpClient> Sending Error JSON RPC id () : Error: Proof of work is higher than target payload:soulisty04 timestamp:1483307475 nonce:229189807




Hey, it actually looks like it's working fine. My miner will submit any share that's at a difficulty of 0x24000000 or above, and since the network difficulty is higher than that, it will submit a lot of shares that are "higher than target" to the wallet. The miner was a bit of a hack-job, but those messages are normal (and actually show that everything's working as intended).
62  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin - Protein Folding Research based Proof of Work on: December 16, 2016, 06:24:10 AM
Been a while since I last updated everyone, CureCoin is still chugging along as always Smiley

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.
63  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [OCHO] Bitcoin Ocho aka The Future [OCHO] NOW MINING on: December 16, 2016, 04:02:31 AM
Quote
    // remove round 8 for maximum OCHO
    //Round(a, b, c, d, e, f, g, h, 0xd807aa98, w8 = ReadBE32(chunk + 32));
    w8 = 0;

Quote
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
64  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: December 12, 2016, 09:50:37 PM
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.
65  Bitcoin / Development & Technical Discussion / Re: Bitcoin Tic-Tac Coopetition mining on: December 12, 2016, 06:52:55 PM
I'll make this a Christmas-themed thread Smiley

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 blockn+1 if the timestamp from the blockn plus 600 seconds isn't the same as the timestamp in blockn+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 phase
As 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 blocks
Even 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 same
Generally, 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.
66  Bitcoin / Development & Technical Discussion / Re: Bitcoin Tic-Tac Coopetition mining on: December 11, 2016, 09:07:20 PM
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 blockn+1 if the timestamp from the blockn plus 600 seconds isn't the same as the timestamp in blockn+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.
67  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: December 10, 2016, 04:06:15 AM
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 Smiley

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 Smiley
68  Alternate cryptocurrencies / Marketplace (Altcoins) / Re: PASCAL COIN + ACCOUNT TRADING THREAD on: November 18, 2016, 08:24:00 PM
WTSC / 100000 / 2000 sats / 2.0 BTC
69  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: November 10, 2016, 09:08:55 PM
Hey, devices are numbered starting from 0, so try d0 instead of d1. Smiley
First thing I tried. Then it's
Code:
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.
70  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: November 10, 2016, 04:55:35 PM
Trying to run mining on GPU, then I get this error. Can anybody help?
http://c2n.me/3Eb9N78.png
Thanks in advance.

Hey, devices are numbered starting from 0, so try d0 instead of d1. Smiley
71  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: November 06, 2016, 01:37:05 AM
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?
72  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin - Protein Folding Research based Proof of Work on: October 28, 2016, 01:40:03 AM
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.
73  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: October 24, 2016, 12:33:04 AM

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?
74  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: October 24, 2016, 12:23:23 AM

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?
75  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: October 23, 2016, 11:24:03 PM
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 Smiley
76  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: October 23, 2016, 11:16:40 PM

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?
77  Alternate cryptocurrencies / Marketplace (Altcoins) / Re: PASCAL COIN + ACCOUNT TRADING THREAD on: October 23, 2016, 06:40:14 PM
Now that the AMD miner is out, be prepared to pay a lot more for coins.  Cheesy

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.
78  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: October 23, 2016, 06:37:11 PM
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/2o9jwng

Try 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.
79  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: October 23, 2016, 02:56:59 PM
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 Smiley

------------------------------------------------------------------------------
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.
80  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Pascal Coin: P2P cryptocurrency without need of historical operations on: October 23, 2016, 02:24:31 AM
OpenCL miner is here!

https://github.com/Vorksholk/PascalCoin-OpenCL/releases/download/v1.00/PascalCoin_OpenCL_ProxyMiner_v1.zip

Getting 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:

Code:
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).
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 ... 86 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!