sbgyuff520
Newbie
Offline
Activity: 50
Merit: 0
|
|
July 06, 2014, 02:28:05 AM |
|
Thank you! I was in the China Internet. Can't open。 The software solves My grammar is not good
|
|
|
|
wxyzups
|
|
July 06, 2014, 03:00:05 AM |
|
Lost 2002.99shc From SZ9ZweWz3ZNVUMgZwS5VGgrCP4xdQ7opoQ to SW87Vv6qGWwMSkX43nTwAt2RVyyVk3epH2 lost 2002.99shc, the latest data synchronization, still have not received help
|
|
|
|
sbgyuff520
Newbie
Offline
Activity: 50
Merit: 0
|
|
July 06, 2014, 03:22:48 AM |
|
CPU:AMD 8350 Memory:Kingtong 4g*4=16G
C:\Users\Administrator\Desktop\S\工具shinyminer>shinyminer -o stratum+tcp://106.3.225.46:6666 -O STuuFKs5UBfyFXv11RWbiyeuipA9k9Seau:x -t 1 [2014-07-06 11:01:19] Starting Stratum on stratum+tcp://106.3.225.46:6666 [2014-07-06 11:01:19] 1 miner threads started, using 'ramhog' algorithm. [2014-07-06 11:03:23] Stratum requested work restart [2014-07-06 11:04:31] Stratum requested work restart [2014-07-06 11:06:47] thread 0: 2 hashes, 0.37 hash/m [2014-07-06 11:09:08] Stratum requested work restart [2014-07-06 11:10:46] thread 0: 2 hashes, 0.50 hash/m [2014-07-06 11:11:42] stratum_recv_line failed [2014-07-06 11:11:51] Stratum connection interrupted [2014-07-06 11:13:23] thread 0: 1 hashes, 0.38 hash/m
Normal? What should I do?
|
|
|
|
utrecht
Newbie
Offline
Activity: 23
Merit: 0
|
|
July 06, 2014, 03:32:32 AM |
|
Solo Mine
|
|
|
|
sbgyuff520
Newbie
Offline
Activity: 50
Merit: 0
|
|
July 06, 2014, 03:42:50 AM |
|
solo??? How to solo?
|
|
|
|
altcoiner15
Newbie
Offline
Activity: 19
Merit: 0
|
|
July 06, 2014, 04:07:30 AM |
|
Download the wallet, and change config file to ramhogthreads=1 gen=1
|
|
|
|
altcoiner15
Newbie
Offline
Activity: 19
Merit: 0
|
|
July 06, 2014, 04:17:14 AM |
|
Although the difficulty on the network is crazy high so you might get annoyed for days without blocks, so probably a pool is better.
|
|
|
|
sbgyuff520
Newbie
Offline
Activity: 50
Merit: 0
|
|
July 06, 2014, 04:18:35 AM |
|
Download the wallet, and change config file to ramhogthreads=1 gen=1
Please send a detailed steps,thanks!
|
|
|
|
|
sbgyuff520
Newbie
Offline
Activity: 50
Merit: 0
|
|
July 06, 2014, 06:22:55 AM |
|
Download the wallet, and change config file to ramhogthreads=1 gen=1
Please send a detailed steps,thanks! download windows wallet from https://www.dropbox.com/s/chgg78pxys7lodh/ShinyCoin-Qt-Win64-v0.3.0.zipchange config file to ramhogthreads=1 gen = 1 Create a new file, called ShinyCoin.conf. as follows: ramhogthreads=1 gen = 1 Copy this file to the%appdata% ShinyCoin Then run the wallet?
|
|
|
|
Bleeckerpub
Newbie
Offline
Activity: 42
Merit: 0
|
|
July 06, 2014, 06:57:04 AM |
|
I think in the end you will still have to invent a way for the nodes to trust each other so as to be sure about what is valid and what is invalid. I'm not sure this is possible by re-using the keypair that is used for signing/verifying the hashes, unless I am missing something here...
Why not? Well, I'm not saying it can't be used for node verification. But which nodes would have the authority to ban other nodes for distributing hashes with invalid signatures? 1) If you go ahead with a centralized infrastructure with 10-20 signing nodes (only those have the private key), then this problem is solved, as long as those signing nodes can be fully protected. 2) On the contrary, if you go ahead with a decentralized infrastructure, aka distribute the private key to all clients & nodes so they are all signing nodes, a client can still verify the signed hashes using the relevant public key and tell if the node is distributing valid hashes or not. Problem in this case is which nodes would have the authority to ban invalid nodes. As I see it, you need a second layer of trust or a type of voting system, with which a node gets banned if it gets 10 negative votes from clients or something like that. Let's say the node with the winning block is the signer of verifying the previous hashes. When the node attempts to relay the information not only is his winning block invalid because the signature for verifying the hashes are invalid but also by default all nodes receiving invalid info will be default block the IP address of any node trying to send or relay invalid hashes. Am I missing something?
|
|
|
|
utrecht
Newbie
Offline
Activity: 23
Merit: 0
|
|
July 06, 2014, 07:05:44 AM |
|
Let's say the node with the winning block is the signer of verifying the previous hashes. When the node attempts to relay the information not only is his winning block invalid because the signature for verifying the hashes are invalid but also by default all nodes receiving invalid info will be default block the IP address of any node trying to send or relay invalid hashes. Am I missing something?
yeah you're missing the code that should be attached showing how you're going to accomplish this. I also don't understand why any of this is relevant.
|
|
|
|
laxori666
Member
Offline
Activity: 71
Merit: 10
|
|
July 06, 2014, 07:08:05 AM |
|
I think in the end you will still have to invent a way for the nodes to trust each other so as to be sure about what is valid and what is invalid. I'm not sure this is possible by re-using the keypair that is used for signing/verifying the hashes, unless I am missing something here...
Why not? Well, I'm not saying it can't be used for node verification. But which nodes would have the authority to ban other nodes for distributing hashes with invalid signatures? 1) If you go ahead with a centralized infrastructure with 10-20 signing nodes (only those have the private key), then this problem is solved, as long as those signing nodes can be fully protected. Seems like this would already work as-is, sunny would just have to run more nodes with the private key or give the private key to other people. 2) On the contrary, if you go ahead with a decentralized infrastructure, aka distribute the private key to all clients & nodes so they are all signing nodes, a client can still verify the signed hashes using the relevant public key and tell if the node is distributing valid hashes or not. Problem in this case is which nodes would have the authority to ban invalid nodes. As I see it, you need a second layer of trust or a type of voting system, with which a node gets banned if it gets 10 negative votes from clients or something like that. There's no point for a private key if everybody has it. It'd be the same as if there's no key at all. Then the question is: should a node just blindly trust whatever block other nodes give them? That seems like a bad idea to me.
|
Gib ShinyCoins: STGsZtHw4DRUby8aYCKjiGReFt3JU94YnT
|
|
|
Bleeckerpub
Newbie
Offline
Activity: 42
Merit: 0
|
|
July 06, 2014, 07:10:30 AM |
|
I think in the end you will still have to invent a way for the nodes to trust each other so as to be sure about what is valid and what is invalid. I'm not sure this is possible by re-using the keypair that is used for signing/verifying the hashes, unless I am missing something here...
Why not? Well, I'm not saying it can't be used for node verification. But which nodes would have the authority to ban other nodes for distributing hashes with invalid signatures? 1) If you go ahead with a centralized infrastructure with 10-20 signing nodes (only those have the private key), then this problem is solved, as long as those signing nodes can be fully protected. Seems like this would already work as-is, sunny would just have to run more nodes with the private key or give the private key to other people. 2) On the contrary, if you go ahead with a decentralized infrastructure, aka distribute the private key to all clients & nodes so they are all signing nodes, a client can still verify the signed hashes using the relevant public key and tell if the node is distributing valid hashes or not. Problem in this case is which nodes would have the authority to ban invalid nodes. As I see it, you need a second layer of trust or a type of voting system, with which a node gets banned if it gets 10 negative votes from clients or something like that. There's no point for a private key if everybody has it. It'd be the same as if there's no key at all. Then the question is: should a node just blindly trust whatever block other nodes give them? That seems like a bad idea to me. Why does it have to be a single signature, why can't it be the signature that just won the block so each time the signer would change?
|
|
|
|
|
baigreen
|
|
July 06, 2014, 07:20:00 AM |
|
Who can make Windows 32-bit Qt wallet??
Thanks..
|
|
|
|
Chaosbubba
Newbie
Offline
Activity: 43
Merit: 0
|
|
July 06, 2014, 07:47:17 AM |
|
New win-64 wallet works well. How about any plan of exchange?
|
|
|
|
laxori666
Member
Offline
Activity: 71
Merit: 10
|
|
July 06, 2014, 08:02:58 AM |
|
There's no point for a private key if everybody has it. It'd be the same as if there's no key at all. Then the question is: should a node just blindly trust whatever block other nodes give them? That seems like a bad idea to me.
Why does it have to be a single signature, why can't it be the signature that just won the block so each time the signer would change? So you want people to trust the miner when he says he made a legit block? No conflict of interest there at all...
|
Gib ShinyCoins: STGsZtHw4DRUby8aYCKjiGReFt3JU94YnT
|
|
|
laxori666
Member
Offline
Activity: 71
Merit: 10
|
|
July 06, 2014, 08:04:32 AM |
|
Who can make Windows 32-bit Qt wallet??
Thanks..
I might be able to do a 32-bit version also... initially I made a 32-bit version but it crashed with even 1 ramhog thread. I guess can't use 15 GB of RAM on the 32-bit version? So I'll make it only work with 0 ramhog threads. Before the latest update there was no point but now there is I guess!
|
Gib ShinyCoins: STGsZtHw4DRUby8aYCKjiGReFt3JU94YnT
|
|
|
sbgyuff520
Newbie
Offline
Activity: 50
Merit: 0
|
|
July 06, 2014, 09:24:53 AM Last edit: July 06, 2014, 10:48:29 AM by sbgyuff520 |
|
Trading platform where?
There are several shinycoin mine pool?
|
|
|
|
|