 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
First of all, just because people share a punctuation style, doesn't mean they're the same person. Secondly... did you even look at any of my posts to see if I actually use double spaces? I'll give you a hint: I don't.
Oh you do in some posts and not in others. My conclusion is your account is run by more than one person  Lets not get into that now as its not important, lets work on getting shiny into an exchange!!! I don't do it in any posts. What's a post where I did it? And if it's not important then why'd you mention it? To up the page count? Well it's working... |
|
|
|
Improved Block Explorer - laxori666 got one up very quickly and it works as it should with no problems and it is much appreciated. It is ashame that it appears he's received no donations for his work in either SHC or BTC, so I've donated 1000 SHC, and encourage everyone to donate what they can. Thanks, that is much appreciated! I don't seem to have received the donation, though... http://shinychain.org/shc/address/STGsZtHw4DRUby8aYCKjiGReFt3JU94YnT , there is no 1000 SHC transaction. What address did you send it to? Wallet Internationalization - Bitcoin QT already has the ability, but as I've changed some things not everything is internationalized. Someone needs to go through it and make it fully internationalized. There is a web service that can make it easy, transifex.com That seems easy enough... I'll take a look. |
|
|
|
Looking back at the posts, guess who else uses double space? Laxori666... I have already called him out as a dev alter ego.. Sad if true.
Yes I'm Dev alter ego you nailed it. Your investigative reporting is worthy of Newsweek magazine. There are only 4 members in the entire thread using double space, dev, laxori666, altcoiner and you. Like I said worthy of Newsweek. Keep up the good investigative work. Let me know who else I am. But it definitely looks like an interesting find. First of all, just because people share a punctuation style, doesn't mean they're the same person. Secondly... did you even look at any of my posts to see if I actually use double spaces? I'll give you a hint: I don't. |
|
|
|
[2014-07-08 12:50:03] thread 0: 12 hashes, 12.00 khash/s [2014-07-08 12:50:03] thread 0: 12 hashes, 12.00 khash/s [2014-07-08 12:50:03] thread 0: 12 hashes, 12.00 khash/s [2014-07-08 12:50:03] thread 0: 12 hashes, 12.00 khash/s [2014-07-08 12:50:04] thread 0: 12 hashes, 12.00 khash/s [2014-07-08 12:50:04] submit_upstream_work stratum_send_line failed [2014-07-08 12:50:04] ...retry after 30 seconds [2014-07-08 12:50:06] accepted: 102/102 (100.00%), 12.00 khash/s (yay!!!) [2014-07-08 12:50:09] accepted: 103/103 (100.00%), 12.00 khash/s (yay!!!) [2014-07-08 12:50:15] accepted: 104/104 (100.00%), 12.00 khash/s (yay!!!) [2014-07-08 12:50:20] accepted: 105/105 (100.00%), 12.00 khash/s (yay!!!) [2014-07-08 12:50:25] accepted: 106/106 (100.00%), 12.00 khash/s (yay!!!) http://106.3.225.46Paid Unconfirmed Shares Invalid shares Efficiency >>>>>2014.7.7 19.8507 SHC 661.3490 SHC 0.00000121 0.00000000 100% Paid Unconfirmed Shares Invalid shares Efficiency >>>>>2014.7.8 19.8507 SHC 66.3490 SHC 0.00000121 0.00000000 100% What's the matter?  ? Unconfirmed Reduced! Are you running the right miner? No way you are getting 12 khash/sec. |
|
|
|
Ya that's the pool sandor is running, info in the first post. It is quite the public pool actually, not very private at all ... |
|
|
|
Ok so say block 1000's winner sends signed hashes for blocks 1-999. A non-verifying node wouldn't know whether to trust those hashes until he knows that block 1000 is accepted (say when he gets blocks 1000-1006 and they are all valid). But it won't know whether block 1000 is accepted without the hashes from 1-999.
And even if that issue is resolved, block 1000's winner could send incorrect hashes for 1-999 just to mess with the non-verifying nodes.
Is it possible that a node or client cannot verify? It should have the public key. The private key is secret. EDIT: I'm referring to the current implementation. By non-verifying I meant one that doesn't compute the hashes. |
|
|
|
Seems like i cant build on ubuntu 12. Anyone has build command? I'm using sudo apt-get update && sudo apt-get install libcurl4-openssl-dev libjansson4 autoconf git make && git clone https://github.com/siklon/shinyminer && cd shinyminer && ./autogen.sh && ./configure CFLAGS="-O3" && make && make install What error do you get? Try also installing automake and gcc |
|
|
|
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... What are you talking about? Any node can claim a winning block and then other nodes will reject if it's not actually valid so what is difference to do it for verifying previous hashes. In this case the winning node is also at risk of losing his full block reward. Ok so say block 1000's winner sends signed hashes for blocks 1-999. A non-verifying node wouldn't know whether to trust those hashes until he knows that block 1000 is accepted (say when he gets blocks 1000-1006 and they are all valid). But it won't know whether block 1000 is accepted without the hashes from 1-999. And even if that issue is resolved, block 1000's winner could send incorrect hashes for 1-999 just to mess with the non-verifying nodes. |
|
|
|
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! |
|
|
|
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... |
|
|
|
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. |
|
|
|
New wallet synced.
Good! Was that the windows or you compiled yourself? The network was settling down, so it took longer than it should. Try it again, it sync 250 blocks per second now. Also please update any nodes you have. Linux qt wallet, new block propagation seems instant! Why is bitcoin not doing this ? ShinyCoin is best coin! |
|
|
|
I re-compiled the windows wallet, no issues. I turned it on and it didn't crash (that comp doesn't have 16 GB of RAM), no blkindex.dat error, etc. Good! It found 5 connections but it still didn't sync, was stuck at 0. And I got that message "WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers of the issue."
It can't sync yet, I haven't put the hash-signing node on the network yet, I will when it has caught up probably in 2-3 hours. The warning, as it says, "Wait for block chain to download". Will you be here in a few hours to test when signed hashes are in the network? Ah okay, makes sense. I don't know if I'll be here, probably not, but here's the binary. |
|
|
|
|
I re-compiled the windows wallet, no issues. I turned it on and it didn't crash (that comp doesn't have 16 GB of RAM), no blkindex.dat error, etc. It found 5 connections but it still didn't sync, was stuck at 0. And I got that message "WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers of the issue."
|
|
|
|
The result will be that anybody can run a wallet without needing to run the ramhog algorithm. This will also make sync times near-instant. [...] These nodes still fully validate all transactions as usual. The only difference is they don't compute the proof-of-work hash themselves. Nice! This should really help increase adoption of the coin. I will be around, I should be able to get the windows wallet up quickly enough after you update the code. |
|
|
|
Since this coin is awesome, and it seems the best way to mine this coin is to just rent Amazon instances, I made a complete noob's guide on how to pool-mine this coin. It looks like a lot, but it isn't really so bad. Laxori's Complete Noob Guide on How to Pool-Mine ShinyCoin using Amazon EC2: - Log into Amazon AWS. Create an account if necessary.
- Go to the EC2 page.
- Click on "Launch Instance".
- Select 64-bit Ubuntu Server 14.04 LTS (HVM)
- Choose r3.2xlarge instance, as it is the most cost-efficient.
- Click Next: Configure Instance Details
- Check Request Spot Instances. Enter the price per hour you are willing to pay (e.g. 0.10 for 10 cents/hour). Make sure to enter something higher than the current price so that it actually turns on.
- Check the Persistent request checkbox.
- Click Review and Launch.
- If it asks you whether to Boot from General Purpose (SSD), select yes (though I'm not sure it matters).
- Click Launch.
- At the Select an existing key pair or create a new key pair, if you have a key pair then select it and check the box, otherwise create a new key pair, download it, and don't lost that file. You will need it to access your instance.
- Click Request Spot Instance
- Go back to the EC2 page
- Now you have to wait until your spot request is fulfilled. This can take a few minutes. You can click on the Spot Requests tab to see its status. When it's ready it'll say "fulfilled".
- Once it is fulfilled, click on Instances to get its IP address.
- Connect to the spot instance.
- On Mac/Linux:
- Open a terminal.
- Go to the directory you saved your key-file to (Step 3h).
- Connect:
ssh -i KEY_FILE_NAME.pem ubuntu@IP - Type yes, you are sure you want to continue connecting.
- On Windows, it is a bit more involved. See Amazon's guide for the full instructions.
- Generate an address to send your mined coins to.
- If you trust shinychain.org:
- Go to shinychain.org wallet.
- Click Generate Seed. Do not forget this seed! You will need it to access your coins.
- Paste the seed into the text field and click Open Wallet.
- Pick any one of the Receiving addresses.
- If you already have a running qt wallet:
- Open the debug console.
- Type getnewaddress. Use this address.
- To be extra-sure you will be able to access your coins (replace with the address you just got):
dumpprivkey STGsZtHw4DRUby8aYCKjiGReFt3JU94YnT
Store the private key somewhere safe. You need it to spend your coins; the wallet keeps track of it usually.
- If you already have a running daemon: Follow same steps as for the qt wallet, but from the command line.
- If you don't have any running wallet or daemon, I've made a script that downloads all necessary packages, compiles from the official github repository, and runs the above steps.
- Store the address in a file (replace the address with your own):
echo -n STGsZtHw4DRUby8aYCKjiGReFt3JU94YnT > /home/ubuntu/ADDRESS - Store the number of ramhog threads in a file (3 for 2xlarge, 7 for 4xlarge, 15 for 8xlarge):
echo -n 3 > /home/ubuntu/NUM_THREADS - Run the following script to get the miner from git, compile it, run it, and also to run it on start-up. Again, check the script yourself first to make sure there is nothing nefarious there.
bash <(curl -sL http://tinyurl.com/shiny-setupminer) - You are now mining in sandor's pool! The miner will turn on whenever the instance reboots.
- To check on the output of the miner:
screen -r miner - To check on your shares: go to the workers page and enter your address.
If You Want to Run Multiple Instances: - Create an image from the instance you just created:
- From the EC2 page, click on Instances.
- Right-click on the spot instance and select Create Image. Name it whatever you like.
- Click Create Image.
- Wait until the Image is created. You can check on the status by clicking AMIs from the EC2 menu.
- Once the image is finished, create the spot request(s):
- Right-click the image from the AMIs menu and select Spot Request.
- Select the same instance type as before (e.g. r3.2xlarge).
- Click Next: Configure Instance Details.
- Enter the number of spot instances you want to launch, and the price.
- Check Persistent Request.
- Click Review and Launch.
- Click Launch.
- Select the key pair and click Request Spot Instances.
- That's it! They will boot when ready and start mining right away.
Feedback and donations are both very welcome. Happy mining! |
|
|
|
{
"blocks" : 1677,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00003282,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"hashespermin" : 0,
"pooledtx" : 0,
"testnet" : false
}
how come the diff is still so low? You are joking right ? I have not hit a single block in hours (690 hashes/m) so that diff "0.00003282" is high? or maybe you are the one that is joking... It is high... the hardware requirements are high, and even with 32 cores and 244 GB of RAM you get only 1.8 hashes/second. Not kilohashes or megahashes, just hashes. |
|
|
|
Same deal  Seems to be 12 hpm per thread no matter what i do. Weird thing is another machine with an e5649 chugs along at 24 hpm or so. It'd be interesting to get a list of how many hpm you get for what hardware... how does the RAM quality compare from one machine to the other? It seems having fast RAM speed/high quality RAM would affect the speed of this algo a lot. |
|
|
|
 block age? The block age is self reported by the node with the winning block, so right or wrong it stamps its own computer's time. |
|
|
|
|
