XBY is very busy this weekend, please wait for answers to your questions till later. You are asking too many question at one time, it would take the developer away from his work. He did answer your last 'batch' of questions.
Sure, I'm not in any rush. These questions might be important for the developer to at least read though even if he doesn't have time to actually compose a response. What is your interest? Intellectual curiosity? You want to develop similar ideas into your coin (imitation is the best form of flatter etc) Or maybe are you interested in joining the project? Debunking what you think won't work? Vorsholk is very good person. no need start fight here. Thanks cyberhacker  It's mainly intellectual curiosity, I specialize in consensus-related technologies and I also don't want to see someone spend a bunch of time building a solution that they eventually find won't work—been there, done that. The hope is that the developer with either have some sort of solution to these problems, or that asking these questions will help him/her realize that some ideas might not work and adjust accordingly. There has already been significant thought put into consensus algorithms and getting around a lot of potential problems. Communication isn't instant (so transactions propagate unevenly and unreliably), nodes aren't always online, and people will actively try to attack the network. It isn't possible to have all nodes with completely synchronized clocks and identical mempools at every tick of those clocks. The ability for one individual party to be responsible for creating the next block (and a competitive environment where no one produces all or most of them) solves these issues—someone dictates truth in a way that everyone else can agree. A lot of alternative consensus algorithms or ideas for them end up having issues with deadlock (where the network is left in a state of permanent disagreement, and effectively breaks into two pieces which may or may not be able to continue to run independently). If communication was instant (where a transaction arrived instantly at all nodes simultaneously) and guaranteed to be delivered to all participants, we wouldn't even need blockchains: all nodes would know that all other protocol-adherent nodes also received the same data at the same time, so no one needs to establish 'truth' or mediate mutually exclusive events, because they couldn't have both been sent simultaneously and so the order in which they appeared would dictate precedence. A bootstrapping node would of course have some trouble, but connecting to tons of nodes and comparing the entire transaction history given by each would likely solve this to a reasonable degree (and this problem exists with PoS coins anyway, 'weak subjectivity'). |
|
|
|
XBY is very busy this weekend, please wait for answers to your questions till later. You are asking too many question at one time, it would take the developer away from his work. He did answer your last 'batch' of questions.
Sure, I'm not in any rush. These questions might be important for the developer to at least read though even if he doesn't have time to actually compose a response. |
|
|
|
Proof of Signature Basic Introduction The PoSign Mining is very easy to understand. Each client (STaTiC Node) sees the same transactions and therefore each block is equally visible by the entire network. The STaTiC Nodes job with regard to the consensus is to simply sign the blocks. If any STaTiC tries to sign a fake block, the other STaTiC's will blacklist it and continue signing the VALID blocks. For example: Let's say there are 100 STaTiC Nodes online across the network and 1 tries to create a block that contains fake information (such as; fake transaction or bad blockhash etc...) This fake/bad block hash will be different than the other 99 hashes and therefore the other 99 clients (STaTiC Nodes) will send a warn/repair RPC message to the "bad" client. If the "bad" STaTiC Node repairs the block then the hash will become the same as the other 99. If it doesn't repair it and instead tries to resend over and over, the other nodes will eventually blacklist the STaTiC. All other nodes (non STaTiC nodes) will see the last block that signed and how many STaTiCs accepted. In comparison; Bitcoin and all other coins have only one untrusted, randomly selected node that signs and creates the block. With XBY, each block is created and signed by all the currently ONLINE STaTiC Nodes. With XtraBYtes, there is no POW or POS mining to sign and verify the blocks. As we said, each online STaTiC signs and this is where you start to see the power of PoSign... Because, this means there are more signatures and more signatures = more security. Nobody can know all private keys from the STaTiC Nodes and therefore it is impossible to create fake STaTiC signed blocks. At this point, we have ONLY 1 STaTiC node controlling XBY and the network is fast and secure... After more STaTiCs have been registered on the network, XBY will be better than ALL other coins in the crypto world. At this point, nobody really understands what is really happening here... We are developing THE COIN  This is the LATEST INNOVATION in BLOCKCHAIN technolgy and our man Borzalom is the Genius Mastermind who thought of it. So, to summarize: If Bitcoin security is 100% (with untrusted nodes signing the blocks) How much more powerful is XBY when it is also (100% + the use of trusted nodes) * the number of STaTiC Nodes? Like I said... he was blowing my mind when he was explaining all this to me a few nights ago. Congratulations to all of you who are already with XtraBYtes... You are way ahead of the people who will be coming on board soon.... VERY SOON... I have a few questions about the specifics of your consensus algorithm. I generally approach consensus algorithms from a few angles: -What are the attack vectors (both in stalling consensus and in reversing established consensus) -How is power distributed (and what effects does that have on censorship) -How does it impact scalability (both in transaction volume and number of users) With those main ideas in mind: 1. How does someone actually become a STaTiC node? Do they have to go through the developer, can they set it up themselves? 2. How do you ensure that each STaTiC node sees the same transactions? Further to that point, if I send two transactions that conflict with one another, and some STaTiC nodes see the first and some see the second, how do they come to agreement which transaction is the legitimate one? 3. What constitutes a 'fake' block? 4. How do normal nodes know who the STaTiC nodes actually are, to verify the signatures against? How do thin clients do it? 5. Are blocks deterministic (i.e. everyone on the network at any point would be able to construct an identical block)? 6. It appears every STaTiC node is able to independently create identical blocks, is that true? 7. What is the threshold for normal nodes to accept a block as valid (99% of STaTiC signatures? 51%?) 8. What prevents the creation of an alternative history if someone compromises the original private key of the first STaTiC node? Is the network only weakly-subjective? This is one of the RARE occasions we will post with Borzaloms English. Anyone can see from his history that this is him... I do not have time to convert this to easily understandable English at this time because we are busy preparing the announcements. However, I do not want this to go unanswered because it is troll food and all of you deserve to have the best chance at winning here at XtraBYtes. Thank you for understanding, Borzalom and I will update this post ASAP. [3:46:20 PM] -- CCRevolution -- $: https://bitcointalk.org/index.php?topic=1864397.msg18775624#msg18775624[3:46:46 PM] -- CCRevolution -- $: That is a very heavy question... We will not have time to answer this tonight I dont think... unless you can make it very simple. [3:46:50 PM] Borzalom: 1 working. maybe just a hour needed [3:47:35 PM] Borzalom: I like heavy questions [5:09:07 PM] Borzalom: Here is the answers: [5:09:13 PM | Edited 5:09:51 PM] Borzalom: This is a first very- very good question. Therefore firstly I thank your contribution. I love the hard constructive technical questions. 1.) need deposit ( own address ) + need registration + long online time need after registration ( until old STaTiC-s accept the new STaTiC-s ) Difference the now and later the first registration ( between 25.000 - 50.000 blocks ) don't need the long online time and old STaTiC-s acception. After registration code released then don't need developer. Maybe some code fixes but no more. And of course this is experimental therefore if don't work the original plan then consensus maybe will change. 2.) The "chord" type internal routing between the STaTiC-s ensure the communication. Example If the hash of transaction is begin the 0x1 then the 0x1 STaTiC will the root who first validate and accept this transaction. If you sent the conflicted transactions then the first will accepted or both will denied. The target STaTiC-s will decide this. I say again, this is expermental therefore i don't know exactly the best solution. We will see how to work and if need then i will change the protocol. This is a top reason why no whitebook. 3.) Very difficult to answer. Of course lot of checking needed. Better question that what is the good block. If any block not good then that is fake. Each STaTiC need to make consensus and need exactly 100% same block accepted. If the all accepted transactions broadcasted between the STaTiC-s then the transactions of block will be equal therefore block has also will equal. ( just signature will the difference ) 4.) STaTiC registration will ensure the public keys of STaTiC-s. The key revoke will work simile. All emitted and revoked key stored to blockchain. nonSTaTiC nodes download the blockcahin and after done the download then will see all STaTiC public key and see also if the public key revoked. 5.) YES. The nonSTaTiC nodes created the blocks too but not broadcast. Each nonSTaTiC node validate the signed block and compare that the self generated block. Therefore if any STaTiC try generate false blocks then nonSTaTiC nodes will recognise too. 6.) YES. See above. All node is able to independently create identical blocks not just STaTiC. Difference between nodes: the STaTiC is able to signing too. 7.) Some STaTiC online and some offline therefore no exact number how many needed. After offline STaTiC go to online then will signing the all unsigned blocks. This work like the confirmation of transactions. Each client decide yourself how many signatures needed to accept the block. Now just one STaTiC working therefore very easy this number is one and 100%. Need expermence founding the best ratio and number. After all newly registered STaTiC begin the work we will see how many online and offline at a time. I don't know this number exactly before STaTiC. 8.) The first static is just temporary. Required this fast patch because nobody want mining zero rewarded blocks. After STaTiC registration success then i will burning the checkpoint to source code. The first temporary STaTiC will be removed. [5:28:07 PM] Borzalom: ---- [5:28:09 PM] Borzalom: remark: These answers valid at now. This is experimental coin. If required i change the plans. Remember why no white book. Just the goal fixed. We want STaTiC nodes, community owned coin and code, community data storage system, new block signing method. I personaly want very very big community who help me reaching the goals. I know this is big goal but i hope i have enought experience and knowledge to reache these goals. I say every time This is not tipical investment money this is experimental money. I don't richer or poor if you bought or sell. This is not my money i just the developer who experimenting. I think my first goal to save investor money who invested to bitmox successed. This is a next step. I don't guarante to this next experimence will als success or not. [6:47:41 PM] -- CCRevolution -- $: Hello, I just finished the video... [6:47:47 PM] Borzalom: ok [6:50:15 PM] -- CCRevolution -- $: I am going to post your response as is... there is no time. So, here is how I will preceed: Thanks for the answers. How does the network know when to produce a new block? A decentralized network like this can't keep a reliable timestamp--for example, Bitcoin has a timestamp that can be about ±2 hours, and that timestamp is embedded by miners into the block they mine. Also, how do you ensure that all nodes truly do see all the same transactions? While distributed networks like these generally work in a flood-fill-like manner, all kinds of things can cause nodes on the network to have a slightly different mempool. If all nodes on distributed networks truly had identical mempools, we wouldn't be having discussions about block propagation on Bitcoin, or they would be significantly different and less interesting (see https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 for example). To clarify a bit on the 'transaction contention' issue, here's an illustration: Assume the existence of two transactions which conflict with one another (but are each independently valid), Tx1 and Tx2.
Purple nodes are normal STaTiC nodes, red ones are regular or STaTiC nodes controlled by the attacker.
The attacker node on the right releases Tx1 and the blue nodes are the STaTiC nodes which are aware that Tx1 exists on the network.
The attacker node on the left releases Tx2 and the green nodes are the STaTiC nodes which are aware that Tx2 exists on the network.
The remaining nodes on the network all hear about either Tx1 or Tx2. At this point, some STaTiC nodes believe Tx1 to be legitimate and others believe Tx2 to be legitimate, and can't reconcile without abandoning what they believe to be truth. It could be said that, once a block containing either Tx1 or Tx2 reaches 51% signature threshold, that the other STaTiC nodes would reconcile. But then the attack vector still exists: what about 3 attacker nodes and Tx1, Tx2, Tx3 which all conflict? And you can't just change the signature threshold to 34%, because then the reconciliation problem moves up to the block level. And on that note: if you choose 51%, then control of a few STaTiC nodes could double-sign and potentially cause desynchronization.On the note of compromising the original STaTiC node, it would theoretically allow a separate, perfectly-valid blockchain separately. Since at block, say, bn only the single STaTiC node was relied on, then compromising it would allow creating a block bn+1, and a block bn+2, etc. And since none of these blocks on the attacker chain would include commitments of additional STaTiC nodes, that blockchain would only ever have that single authority, and could be created to arbitrary depth effortlessly. |
|
|
|
Proof of Signature Basic Introduction The PoSign Mining is very easy to understand. Each client (STaTiC Node) sees the same transactions and therefore each block is equally visible by the entire network. The STaTiC Nodes job with regard to the consensus is to simply sign the blocks. If any STaTiC tries to sign a fake block, the other STaTiC's will blacklist it and continue signing the VALID blocks. For example: Let's say there are 100 STaTiC Nodes online across the network and 1 tries to create a block that contains fake information (such as; fake transaction or bad blockhash etc...) This fake/bad block hash will be different than the other 99 hashes and therefore the other 99 clients (STaTiC Nodes) will send a warn/repair RPC message to the "bad" client. If the "bad" STaTiC Node repairs the block then the hash will become the same as the other 99. If it doesn't repair it and instead tries to resend over and over, the other nodes will eventually blacklist the STaTiC. All other nodes (non STaTiC nodes) will see the last block that signed and how many STaTiCs accepted. In comparison; Bitcoin and all other coins have only one untrusted, randomly selected node that signs and creates the block. With XBY, each block is created and signed by all the currently ONLINE STaTiC Nodes. With XtraBYtes, there is no POW or POS mining to sign and verify the blocks. As we said, each online STaTiC signs and this is where you start to see the power of PoSign... Because, this means there are more signatures and more signatures = more security. Nobody can know all private keys from the STaTiC Nodes and therefore it is impossible to create fake STaTiC signed blocks. At this point, we have ONLY 1 STaTiC node controlling XBY and the network is fast and secure... After more STaTiCs have been registered on the network, XBY will be better than ALL other coins in the crypto world. At this point, nobody really understands what is really happening here... We are developing THE COIN This is the LATEST INNOVATION in BLOCKCHAIN technolgy and our man Borzalom is the Genius Mastermind who thought of it. So, to summarize: If Bitcoin security is 100% (with untrusted nodes signing the blocks) How much more powerful is XBY when it is also (100% + the use of trusted nodes) * the number of STaTiC Nodes? Like I said... he was blowing my mind when he was explaining all this to me a few nights ago. Congratulations to all of you who are already with XtraBYtes... You are way ahead of the people who will be coming on board soon.... VERY SOON... I have a few questions about the specifics of your consensus algorithm. I generally approach consensus algorithms from a few angles: -What are the attack vectors (both in stalling consensus and in reversing established consensus) -How is power distributed (and what effects does that have on censorship) -How does it impact scalability (both in transaction volume and number of users) With those main ideas in mind: 1. How does someone actually become a STaTiC node? Do they have to go through the developer, can they set it up themselves? 2. How do you ensure that each STaTiC node sees the same transactions? Further to that point, if I send two transactions that conflict with one another, and some STaTiC nodes see the first and some see the second, how do they come to agreement which transaction is the legitimate one? 3. What constitutes a 'fake' block? 4. How do normal nodes know who the STaTiC nodes actually are, to verify the signatures against? How do thin clients do it? 5. Are blocks deterministic (i.e. everyone on the network at any point would be able to construct an identical block)? 6. It appears every STaTiC node is able to independently create identical blocks, is that true? 7. What is the threshold for normal nodes to accept a block as valid (99% of STaTiC signatures? 51%?) 8. What prevents the creation of an alternative history if someone compromises the original private key of the first STaTiC node? Is the network only weakly-subjective? |
|
|
|
|
Hey everyone, quick update on Curecoin 2.0:
We've gone through 8 internal iterations, fixed a lot of bugs/issues (radix tree for the ledger sometimes didn't return the correct hash when climbing back down a fork, clients had a difficult time forking back >~100 blocks, communication protocol wasn't expressive enough for handling certain network conditions, etc.). Still chasing a bug with clients getting desynchronized, so I'm working on an overhaul of the networking code.
|
|
|
|
...
Not all of that number is ASICs. But much of the appeal to cc was the ability to be on all sides. Like I said, at least now I know in advance the best thing to do is just mine/fold and dump. We are still planning to launch SigmaX which will share a common codebase with cc2.0 and provide pure-PoW functionality. It won't be SHA256D for ASICs, but it will still support "traditional" mining and the accompanying security model. |
|
|
|
|
Not sure what fix the PascalCoin dev is working on, but the usual solution that other PoW blockchains adopt is to let a new block be valid if its timestamp is greater than the median timestamp of the last 'n' (bitcoin chooses 11) blocks, and if it's less than the "network adjusted time" (average of all nodes you're connected to) + m hours (bitcoin chooses 2).
|
|
|
|
|
Just thought I'd check in, project is still active. Someone mentioned SigmaX, that is still planned to launch along with cc2.0.
If you have any specific questions, please PM me, as I don't have time to read through this thread on a regular basis.
|
|
|
|
My apologies if this has been already discussed, but what stops someone from sending the BTC proof from an exchange wallet? With a very small balance on an exchange, someone could potentially pretend they represent 1000s of Bitcoins.
I believe this distribution would be a lot more fair if it required the signature method, rather than allowing the tx method of proving address ownership.
It would be a lot more fair if they did it in any other way probably than the way they are doing it now. BTW are you still part of curecoin? I've followed your guides since the start of arriving at this forum and mostly decided on cure on the basis of you being core to that project? I was just thinking that requiring signatures over a message endorsing the Byteball address would be more sure-fire proof of ownership of the address. Still part of Curecoin, we've got some cool announcements coming soon |
|
|
|
My apologies if this has been already discussed, but what stops someone from sending the BTC proof from an exchange wallet? With a very small balance on an exchange, someone could potentially pretend they represent 1000s of Bitcoins.
I believe this distribution would be a lot more fair if it required the signature method, rather than allowing the tx method of proving address ownership.
Exchanges addresses has been ban. If an exchange want to link their wallet they will have to sign a message. How do the byteball guys know all of the addresses that exchanges use? |
|
|
|
|
My apologies if this has been already discussed, but what stops someone from sending the BTC proof from an exchange wallet? With a very small balance on an exchange, someone could potentially pretend they represent 1000s of Bitcoins.
I believe this distribution would be a lot more fair if it required the signature method, rather than allowing the tx method of proving address ownership.
|
|
|
|
Any miners available for NViDIA CARDS ?
bugged...as far as i know People have reported getting blocks with my CUDA miner including KlausT's optimizations, although it's solo-mining only. |
|
|
|
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04No 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. Your miner works! I just found two blocks in rapid succession (with only one block between them  ) with a rather low hashrate. Awesome, thanks!! |
|
|
|
Thanks for your efforts man! Is there any chance to compile your code for Compute Compatibility 1.2 ?  I'm getting Using Device: 0
ERROR ALLOCATION
CUDA Version: 6.1
CUDA Devices: 0
Mining on device #0...
ERROR ALLOCATION
ERROR ALLOCATION
ERROR ALLOCATION
ERROR ALLOCATION
ERROR ALLOCATION
ERROR ALLOCATION
Last error: CUDA driver version is insufficient for CUDA runtime version
ERROR ALLOCATION
ERROR ALLOCATION
ERROR ALLOCATION
Real: 1DDF0000CA022000E478A2CDB3B71D1F02E3DCAA435ABF0C32ABEABD27C1EE6CD
410640420F000000000001000100DBA7D0306B754E6E77306E5F3030C0562EF6AD2217BC
A5ADD34C75F1B4C219A5DA9B722947ED800000000000000000000000 Hey sorry, cc1.2 is way too old, my compiler doesn't even support it  |
|
|
|
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04No 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 make a miner but say "No promise that the new miner can actually mine blocks". WTF is this, how do you not know, if the miner that you made actually works? It's possible that one of the optimizations (namely the funnelshift, can't imagine an unroll causing a problem) could introduce a bug by not behaving the way I expect. The way to truly know a miner works is to mine a block with it (although you can be pretty certain that it works by manually checking hashes). So If it doesn't mine a block, we'll never know if it actually working. People will be mining for days, saying they can't find a block, not knowing if the miner actually works. What a waste of time and electricity. That's the game of mining for you. |
|
|
|
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04No 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 make a miner but say "No promise that the new miner can actually mine blocks". WTF is this, how do you not know, if the miner that you made actually works? It's possible that one of the optimizations (namely the funnelshift, can't imagine an unroll causing a problem) could introduce a bug by not behaving the way I expect. The way to truly know a miner works is to mine a block with it (although you can be pretty certain that it works by manually checking hashes). |
|
|
|
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04No 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. 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 Multiple instances really aren't that much of a pain though. |
|
|
|
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04No 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. |
|
|
|
Hey everyone, updated the CUDA GPU miner with some of KlausT's improvements: https://github.com/Vorksholk/PascalCoin-CUDA/releases/tag/v1.04No 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. |
|
|
|
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). |
|
|
|
|
Show Posts
