 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
Same issue ("Complete: Error"), made 3 NEM withdrawals, only the first one went through.
|
|
|
|
I had a stratum pool running (in 2014, so I think the state of art has moved on quite a bit), but it was quite finicky. I've uploaded all the code updates I've made though to make it work https://github.com/kryptoslab/node-open-mining-portal is the base, don't think I made any changes Added some commits to the following. https://github.com/kryptoslab/node-stratum-poolhttps://github.com/kryptoslab/node-multi-hashingOh cool! I really didn't know this community is still alive. I'm kinda surprised the slimcoin.club explorer is somewhat alive. I haven't touched it for nearly a year plus. Grabbing data from the server should be ok! Yeah if anyone wants the JS files please help yourselves! I kinda just ported the Slimcoin frontend from another open source bitcoin project. Re Dcrypt port, I also always thought browser mining would be interesting in a decentralising fashion particularly since it's a CPU coin (is it still?), and as a faucet of sorts. Had hoped it would be useful to attract people to the project. It pays out from the Giveaways address, but the mining is real (pool-style) and also pays into the giveaways address. If anyone can make use of it please do too  Changes made to Slimcoin.club: Added Novaexchange, relinked github, removed expired links, relinked bitcointalk Good news regarding a better Coinmarketcap integration: I have found a way how to extract the "circulating supply" from http://slimcoin.club - that is the number that is missing to calculate the correct market cap. There are some hidden URLs that can be spotted if you open the javascript files included in the home page (view source code for that). There seems to be a complete Slimcoin JavaScript frontend there and even a DCrypt "port". I hope @a123 (creator of slimcoin.club) is not annoyed if I grab the total supply every 5 minutes to provide it to Coinmarketcap (the server load should be minimal). I don't know if he released that Javascript files somewhere or if it's only a "private" implementation for his web site - @a123, if you are reading here, it would be cool if you could open source it ... I have written a little Python script that collects this number, I could extend and publish it to provide it to CMC in a more accesible way. However, it's so easy to grab that perhaps they can grab it by themselves - I've sent them the link and the method to grab the number. They say they need "up to 7 days" to add/change information, so if in ~2-3 weeks the figures are still not correct, I'll provide them a web service. @dzarmush: I guess the 502 errors are simply a bug/problem on bchain.info. Yesterday I consulted them several times and they had some load problems. I remember there was the link to the pool on slimcoin.club, i am struggling to make one. Do you have maybe some guide how to do? |
|
|
|
Oh cool! I really didn't know this community is still alive. I'm kinda surprised the slimcoin.club explorer is somewhat alive. I haven't touched it for nearly a year plus. Grabbing data from the server should be ok! Yeah if anyone wants the JS files please help yourselves! I kinda just ported the Slimcoin frontend from another open source bitcoin project. Re Dcrypt port, I also always thought browser mining would be interesting in a decentralising fashion particularly since it's a CPU coin (is it still?), and as a faucet of sorts. Had hoped it would be useful to attract people to the project. It pays out from the Giveaways address, but the mining is real (pool-style) and also pays into the giveaways address. If anyone can make use of it please do too Changes made to Slimcoin.club: Added Novaexchange, relinked github, removed expired links, relinked bitcointalk Good news regarding a better Coinmarketcap integration: I have found a way how to extract the "circulating supply" from http://slimcoin.club - that is the number that is missing to calculate the correct market cap. There are some hidden URLs that can be spotted if you open the javascript files included in the home page (view source code for that). There seems to be a complete Slimcoin JavaScript frontend there and even a DCrypt "port". I hope @a123 (creator of slimcoin.club) is not annoyed if I grab the total supply every 5 minutes to provide it to Coinmarketcap (the server load should be minimal). I don't know if he released that Javascript files somewhere or if it's only a "private" implementation for his web site - @a123, if you are reading here, it would be cool if you could open source it ... I have written a little Python script that collects this number, I could extend and publish it to provide it to CMC in a more accesible way. However, it's so easy to grab that perhaps they can grab it by themselves - I've sent them the link and the method to grab the number. They say they need "up to 7 days" to add/change information, so if in ~2-3 weeks the figures are still not correct, I'll provide them a web service. @dzarmush: I guess the 502 errors are simply a bug/problem on bchain.info. Yesterday I consulted them several times and they had some load problems. |
|
|
|
|
Just used hexpay for autobuy. Credentials didn't work right away but a PM to @topherhf got it sorted out very quickly.
|
|
|
|
|
12Y6sYYUDZd9HFC7EJ49wgeE1C6Se4SsgC
|
|
|
|
Used allanmac's code ( https://gist.github.com/allanmac/f91b67c112bcba98649d) from devtalk.nvidia.com to test TLB thrashing and compiled it with nvcc -m32. It didn't alleviate the TLB thrashing issue; 970 still dives like a stone past 2GB. Not sure if this is representative of memory bandwidth in Ethash though, just sharing to see if anyone can tweak and improve the TLB situation. Perhaps compile the ether miner for 32 bit's will help? Cached Pointersizes will go from 64bit to 32 (and double the tlb limit?) You need to remove the cpu verfication code because it use 64bit libraries I think..
Thought of that but it's going to be troublesome. You only have a 4GB address space, with windows already sucking up ~half. Then you have to load the 1.3 GB DAG from disk, and allocate 1.3GB of GPU RAM (which, AFAIK sits in the same space, although it isn't pinned to host). This doens't fit. So then you would have to read the DAG from disk in small chunks and copy it cover to GPU RAM. And when that's all done, you will have to pass on all solutions to a special light version of ethminer, that does light verification, is it can't load a DAG into RAM for the same reasons. Or you simply don't verify and risk some Boo's. Then, when that's all done, you're not even sure if it fixes the problem. You could try getting a 32-bit version of dagSimCL to work. I believe Epsylon3/tpruvot has been trying to get a 32-bit version of ethminer to work a while back. Can't find the source anymore. |
|
|
|
gjhiggins re-merged slimcoin (slimpeer/kryptoslab/tbarlett) back to the ppcoin's chain, bringing it to version slimcoin v0.4.0 back in feburary. it now compiles with qt5.0, and is more pool friendly as it natively accepts rpc batch commands, as well as some misc. changes and bug fixes. I've now changed slimcoin.club's library link to point at gjhiggin's fork. I did a Windows release ( https://github.com/gjhiggins/SLIMCoin/releases/download/SLMv0.4.0-alpha/slimcoin-qt.7z) and a blockchain snapshot 236000 ( https://mega.co.nz/#!pg8lEJoL!54dSH7LrpmOJiMzNS72MDCYvZtXwqnHGyCApmYIpxkA) back then, but I'm actually not running that version for the slimcoin.club site, so am not sure about the stability. Think all the previous contributors have access rights to that git, so that might be a useful point to start: https://github.com/gjhiggins/Slimcoin/. Bugs can be reported directly to the git, then most of the previous contributors will get a ping so it might kickstart something again? |
|
|
|
Wow works like a charm, thanks! I used it on a relatively clean install of Windows 7 and it still runs; so I suspect it should work for most people. I've taken the files from Jonnylatte's release and scanned it, and repackaged it into a .7z because somehow Github keeps rejecting the original .zip. You can get it now from both https://github.com/kryptoslab/slimminer/releases/download/v0.1/Slimmer.7z and http://www73.zippyshare.com/v/84890173/file.html. For pool purposes, run it using: minerd -o stratum+tcp://www.slimcoin.club:41680 -O <addr>:1 The iteration optimisation is set to 128 as per default (i.e. -i 128). You can vary this to optimise for your platform; faster PCs may benefit from lower iterations and vice versa. The other hex conversion speed-up by JL is already hard-coded in. <addr> can be generated using the brain wallet if you don't have the client. Go to http://www.slimcoin.club/#wallet, click "Key Generation", type in a passphrase and an address will be generated. All generation is done in-browser and nothing is sent back, but to be sure you can disconnect from the internet when you generate the key and then close the browser window. The slimcoin client will have a built-in brain wallet import RPC for the next release. |
|
|
|
Is everyting OK with pool? Last payout was 3 days ago, but blocks are getting found and confirmed...
I was just wondering the same thing. The pool shares the daemon with the giveaway daemon, but even though I requested an address for "nomp" using getaccountaddress, the SLM seem to be going into the "" account instead. Hmm might be a bug with the client, will look into fixing this. I've temporarily transferred funds from the "" account to "nomp", but it seems like the past few payouts were lost cos I don't seem to have captured any errors. The current immature blocks should be paid out once they mature. |
|
|
|
.... aaaand, still good. Well, now I'm confused,  but happy enough. no crash, good news i guess xD |
|
|
|
Anyway, herewith a single CPU instance at RunAbove - http://labs.runabove.com/power8/ - Not totally sure on the billing in comparison to other cloud server providers, but those are certainly some powerful core(s). Just went to try it! 1 thread gives 1.2KH, 2 threads give 1.5KH total, 4 threads give 1.8KH, 8 threads give about 1.5KH. Power8 works on a 8 thread per core. So I guess this kinda explains the results! |
|
|
|
Ok fixed sendmany! I didn't implement the code to handle sendmany in my RPC batch proxy. Also um, I set minimum payout to 70SLM. Now set to 0.1SLM. You should be getting your payouts soon! I hope. 1st consolidated payout details: http://www.slimcoin.club/#blkexp?block=139218"nomp" {"Sbz8ykVBmBMeFPMBi31pR1pFoGaajWkNEi":65.16429,"SN7xFUArRx9Zv4AV9cWj6dawsFxcXvpr6D":0.38056,"ShfxNcu5NxrLiBxXzZeouJ3tRRzwZQzaea":6.71146,"SPhwVTMMrPCKdJb66DwMRkKe5hf4xxJsXK":1.58863,"SYHJWERaM8XD3qowYxP2cL6ey1iLYf17dD":21.24969,"SRWLQwaLNp1vvdQiUHDeQ9arYsX5mCZsDg":4.71249,"STa3ALZUQT5urYV2Er7N9XJxC5u3EZq32b":2.51616,"ShgXk3k4ss7CFm51kPuXNtV4F1HpbZVPaT":12.75949,"SZpyupfHCfX1X9r5rtknHXZsyhq5qfsce6":9.746}"
2nd normal block payout: www.slimcoin.club/#blkexp?block=139225Fees - 1% to bounty, 1% to giveaways. For now. If we go PoS/PoB it might not quite matter I also got 1K SLM and 10K SLM donations for bounties! Any one wants to claim ownership  Any ideas what kind of bounties to offer too? Still running without a crash so far, I'll let it go a while longer and see... maybe it was just random.  Perhaps a high stake amount, look at how HYP is doing with 750% annualy, a very strong network as well because noone want to miss out staking. Just like burning with slimcoin, the wallet has to be online.
Yea this would be quite in line with the original dev's intentions for everyone to run their own wallet. Think this idea of PoS/PoB has quite a good potential! |
|
|
|
oops. it appears the rpc command sendmany wasnt implemented.. will work on this! ur shares shd b safe |
|
|
|
Maybe PoB+PoS is much better! Why waste power for GPU-CPU mining, when even RasPi can be used to complete SlimCoin usage? SlimCoin, SlimWallet & SlimMiner (RasPi  ) "Why use expensive and power-hungry hardware, when even Android smartphone can be your e-Wallet & Miner?" Actually PoS+PoB might be a good idea. I've been thinking a lot about it too! The whole code base is built off Peercoin, and we can't migrate out to a PoW only coin cos of the PoS heritage blocks. We will have PoB generation and PoS to secure the blockchain. We may not even have to migrate our PoB. Just tweak PoS to make it generate blocks more frequently (aka undo what slimcoin did before he got busy elsewhere) and I remember the difficulty even reached 1 at some time back then. No one would bother to PoW then! PoS did cause a lot of trouble for us last time though, in particular it interferes with PoW. But if PoW is meant to be an afterthought this isn't a problem then. |
|
|
|
What is the ratio of PoB blocks to PoW blocks?
The ratio is set to target 1 every 3 PoW blocks. |
|
|
|
Now I'm not much of a miner, but my only worry about a asic friendly algorithm would be that especially early on after the switch it'd be easy for one person to get all the blocks. On the flip side, cpu-only means someone with a botnet can do the same thing. Tricky decisions.
True. And there's also the spectre of 51% attack. |
|
|
|
There are Prime-based algos (Rie, Prime, Gap), Blockchain-based scratchpad algos (Wild Keccak) and memory-intensive ones (Cryptonight). Can take a look at http://cpucoinlist.com/. These are all based on high random access memory requirements which GPUs perform poorly with. These are mostly well-established algos with known optimised GPU miners, actually. But the main difference is the GPU miners don't have much of a Hash/Watt advantage over CPUs even after heavy and public optimisation, whereas for Dcrypt it could be a lot higher and still private. Alternatively, we can also focus on PoB for the masses, and just use an established Scrypt or SHA256 PoW for miners. |
|
|
|
Ouch. Bad news galore  On the bright side, we must have quite a bit of volume today on Bter and prices have fallen, so acquisition and mining would hopefully be cheaper. The coins would also hopefully have been bought by people committed to the growth of SLM. I learnt about the weakness once someone about 4 pages back mentioned about the low scratch space requirements, and the slimcoin.club web miner was experimenting with an iteration limit of 64. The improvement is actually rather little, around 20% max and you have to tweak for an optimal iteration limit. I haven't checked johnnylatte's hex acceleration routine. However, once this news gets out (like now) I suspect it would be trivial for experienced GPU coders to accelerate it, if it wasn't already. POB uses single-SHA256 and not dcrypt, so no iteration-based improvement would help it. The dump is likely by someone with a GPU miner or a botnet; I've seen single addresses recently hashing with over 5MH. I'll try to quickly implement the changes into the miner and release it; that should help level the playing field and buy us some time to change the algo, or just go completely GPU friendly. I'm still for a version of CPU only algorithm though, but we oughta use one that has been well established. |
|
|
|
The lack of new function, lack of marketing, hope a123 go ahead!，I have always been optimistic about this coin！！  Yea think it has a lot of potential, hope we're all able to work together to raise awareness of the coin |
|
|
|
|
