Bitcoin Forum
August 17, 2018, 09:35:14 AM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
  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 27, 2017, 08:29:58 PM
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04

No promise that the new miner can actually mine blocks, but if anyone gets a block with this, please let the rest of us know. About 360% performance improvements, I'm getting around 900 MH/s on an overclocked 1080.

I've also seen some people worried about the PascalCoin wallet saying "Error: Proof of work is higher than target payload." This isn't a problem--the way my miner works (and presumably some others that are floating around now, although I haven't looked at the code for them) is by submitting shares that meet a target of 24000000. Note that we are currently on track for a target of 31000000 soon, which is 8192 times higher, so you should expect to see, on average, 8192 of those errors per actual block mined. The miner is submitting shares to the wallet, effectively. These shares don't count for anything unless they meet the target.

you say that this error is not really an error, but just how it work, but why you are saying that "no promise that the new miner can actually mine blocks"? if it work it should eventually find one

I'm saying that the error isn't necessarily an indicator of any problem (in fact, it's 100% expected), but that doesn't mean something else couldn't be wrong with the miner. Smiley

mmh ok...btw can you fix the multiple instance thing with the nvidia miner, amd can run all the gpu with one instances but nvidia still not...

Unfortunately I'm way too busy with other projects at the moment Sad Multiple instances really aren't that much of a pain though.
62  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [PASC] PascalCoin, deletable blockchain & bank account system [PASA] on: January 27, 2017, 08:25:32 PM
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04

No promise that the new miner can actually mine blocks, but if anyone gets a block with this, please let the rest of us know. About 360% performance improvements, I'm getting around 900 MH/s on an overclocked 1080.

I've also seen some people worried about the PascalCoin wallet saying "Error: Proof of work is higher than target payload." This isn't a problem--the way my miner works (and presumably some others that are floating around now, although I haven't looked at the code for them) is by submitting shares that meet a target of 24000000. Note that we are currently on track for a target of 31000000 soon, which is 8192 times higher, so you should expect to see, on average, 8192 of those errors per actual block mined. The miner is submitting shares to the wallet, effectively. These shares don't count for anything unless they meet the target.

you say that this error is not really an error, but just how it work, but why you are saying that "no promise that the new miner can actually mine blocks"? if it work it should eventually find one

I'm saying that the error isn't necessarily an indicator of any problem (in fact, it's 100% expected), but that doesn't mean something else couldn't be wrong with the miner. Smiley
63  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [PASC] PascalCoin, deletable blockchain & bank account system [PASA] on: January 27, 2017, 08:19:43 PM
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04

No promise that the new miner can actually mine blocks, but if anyone gets a block with this, please let the rest of us know. About 360% performance improvements, I'm getting around 900 MH/s on an overclocked 1080.

I've also seen some people worried about the PascalCoin wallet saying "Error: Proof of work is higher than target payload." This isn't a problem--the way my miner works (and presumably some others that are floating around now, although I haven't looked at the code for them) is by submitting shares that meet a target of 24000000. Note that we are currently on track for a target of 31000000 soon, which is 8192 times higher, so you should expect to see, on average, 8192 of those errors per actual block mined. The miner is submitting shares to the wallet, effectively. These shares don't count for anything unless they meet the target.
64  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).
65  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.
66  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
67  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.
68  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.
69  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.
70  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
71  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
72  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.
73  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
74  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?
75  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.
76  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?
77  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?
78  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
79  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?
80  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.
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!