 Show Posts
|
|
Pages: « 1 [2] 3 4 5 »
|
|
I've posted up the fixed submitblock code, still with a quite a bit of debug commands that should output to your debug.log.
This should work nicely with NOMP code without much changes, just need to disable sha256 checks, as well as run a JSON RPC Batch proxy to split the batch commands into individual calls.
Native batch support will probably need to be fixed via a code-base upgrade.
First pool and first large pool bounties still open!
(If anyone noticed a short disconnect from the pool, apologies! I was testing the code to be committed)
|
|
|
|
|
Ok gotta go to bed, didn't manage to clean up the code yet. Will post up the updated submitblock code soon!
|
|
|
|
(PS -- I downloaded the 0.3.2.1 Windows build from the Git releases, and it was crashing again like the old wallet did. I've had to go back to 0.3.2.0 for the time being.  ) Any idea why? Dya have a debug log of what led to the crashes? |
|
|
|
Lets put it to a vote to switch algo then - the logical choice being SHA-256 like Bitcoin and Peercoin. I think I would actually vote yes on that.
Hmm I'm not quite for SHA-256 since I like the idea of SLM being a gpu/asic-resistant coin. Oh, and NOMP server has finally accepted the first DCrypt block! 2014-10-27 19:55:45 [Pool] [slimcoin] (Thread 1) Submitted Block using submitblock successfully to daemon instance(s)
2014-10-27 19:55:45 [Pool] [slimcoin] (Thread 1) Block found: 00000002762cab5802109aa37cf8c5f08c77cde1611a017c3e3e130eea352695
|
|
|
|
Dead ? Thank primer-, after you gone price rise from 180 sat to 10k sat. Diff rise from 0.03 to 0.3. All thanks to you. Please feel free to leave forever, don't ever come back.  Good luck with the new clueless dev, idiot.  Good luck with your self illusion, idiot. Well he's not technically wrong xD  the new coin primer- mentioned is a prime based one, and those are really hard to accelerate. I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive. |
|
|
|
If anyone is interested in taking a look at the submitblock issue, slimcoind submitblock 01000000f2d59cd21920d6c06c3a4a4e5665ccc791a3ef412680f82fa33eb28e00000000ab110d0b1946579cf081ceade6fdca70c37ee09b0559c76ef24544d5a162c12b92ff4d54c85e031d261c23000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff27035c1502062f503253482f04a2ff4d5408080000000000000d0d2f6e6f64655374726174756d2f000000000338a87e00000000001976a91483c0525511cf0f49325f8d9634781efa4897d1ea88acdc4a0100000000001976a914b97278df80bbc7d0f4370356b990dda77753fe1d88acdc4a0100000000001976a914ce572bb0049ccba44d820181ba1b922badcaa41988ac00000000
will give ******* exception encountered *******
./slimcoind(_Z13LogStackTracev+0x3c)[0x5fa71c]
./slimcoind(_ZN11CDataStream4readEPci+0xe7)[0x520647]
./slimcoind[0x547aa7]
./slimcoind(_Z16Unserialize_implI11CDataStream5CTxInSaIS1_EEvRT_RSt6vectorIT0_T1_EiiRKN5boost17integral_constantIbLb0EEE+0x185)[0x578505]
./slimcoind[0x54c991]
./slimcoind(_Z16Unserialize_implI11CDataStream12CTransactionSaIS1_EEvRT_RSt6vectorIT0_T1_EiiRKN5boost17integral_constantIbLb0EEE+0x138)[0x57dcb8]
./slimcoind(_ZN6CBlock11UnserializeI11CDataStreamEEvRT_ii+0x23f)[0x57e02f]
./slimcoind(_Z11submitblockRKSt6vectorIN11json_spirit10Value_implINS0_13Config_vectorISsEEEESaIS4_EEb+0x48e)[0x5b567e]
./slimcoind(_ZNK9CRPCTable7executeERKSsRKSt6vectorIN11json_spirit10Value_implINS3_13Config_vectorISsEEEESaIS7_EE+0x14d)[0x5b15cd]
./slimcoind(_Z16ThreadRPCServer2Pv+0x1905)[0x5b8655]
./slimcoind(_Z15ThreadRPCServerPv+0xa2)[0x5ba182]
/lib64/libpthread.so.0(+0x7df3)[0x7f3f178b3df3]
/lib64/libc.so.6(clone+0x6d)[0x7f3f172df01d]
This is during the Serialization to CBlock. |
|
|
|
|
I've taken the NOMP pool down - I've confirmed that there's a submitblock issue, slimcoind crashes without any error log, every time a valid submitblock is submitted.
Will be working on fixing it on the Slimcoin client side, suspect it's a block header mismatch issue: no burn fields in the block header submitted by NOMP, and it doesn't seem that Slimcoin's block parsing routine handles this. Will investigate further and report back!
NOMP cannot use getwork to request for jobs so submitblock must be fixed, but think MPOS can request getwork so that might mean suprnova's one might work out?
|
|
|
|
The pool stats. are way off. Seems to be stable though.
Perhaps some more folks would spin-up a free cpu cloud instance and/or start mining in the pool. Just need to find a block to know that were good.
Oh that explains why the blocks haven't been found. Would have thought at >1MHs we should be seeing blocks. |
|
|
|
Did not produce a block  Oh right, that. There has been pools for Slimcoin before, so I assume things can be fixed soon |
|
|
|
So I know I could make a spreadsheet to figure this out, but I love the convenience of the burn calc on slimcoin.club - any chance you could add something that says how many days until you break even and how many effective coins will be left on that date?
A few assumptions made: difficulty unchanged from last PoB, no new burnt coin. For 10000 SLMs burnt, it will show 83.025724 SLMS GENERATED PER DAY, 14.27 SLMS DECAYED, 120 DAYS TO BREAKEVEN, 8425.162778 BURNT COINS LEFT AT BREAKEVEN Do you know if the rate of decay changes as a function of increased difficulty? Decay is a fixed constant that depends on the number of PoW blocks generated since burn: 1.00000198 per PoW block, burnCoins = nCoins / pow(BURN_DECAY_RATE, depthInChain); For the slimcoin.club calculator, I just assumed 720 blocks per day are PoW (i.e. 3 PoW and 1 PoB), and thus I hard-coded the decay per day is 1.00000198 ^ 720 = 1.001427... |
|
|
|
So I know I could make a spreadsheet to figure this out, but I love the convenience of the burn calc on slimcoin.club - any chance you could add something that says how many days until you break even and how many effective coins will be left on that date?
A few assumptions made: difficulty unchanged from last PoB, no new burnt coin. For 10000 SLMs burnt, it will show 83.025724 SLMS GENERATED PER DAY, 14.27 SLMS DECAYED, 120 DAYS TO BREAKEVEN, 8425.162778 BURNT COINS LEFT AT BREAKEVEN |
|
|
|
https://slim.suprnova.cc is up - we need to find a block though.. Not 100% sure if it works, this is a extremely strange algo, i will probably have to tweak some settings concerning the hashrate, but first i'd like to try if we can find a block or not. Ooh good news! And 2 MHs already too. Once we have a few blocks to confirm, this would probably be good Yea my NOMP server died on a submitblock call. Apparently that crashed the slimcoin daemon Not sure why, debug.log has no details, will look into it a bit! |
|
|
|
Ok, fixed some bugs with the temporary NOMP pool I've set up, looks like its counting shares now! Stats page is at http://www.slimcoin.club:8081/, stratum port is 41680. I don't have the hash power to mine a block anymore, so not sure if it works! First other pool bounty still holds - 2.5K SLM. First pool to hit 2MHs - 2.5K SLM. |
|
|
|
I'm at 35k now.. will take some time..
you can grab the blockchain snapshot from https://github.com/kryptoslab/slimcoin/releases up, it goes up block 126100! i also just finished setting up the NOMP @ stratum+tcp://www.slimcoin.club:41680, just to see what are the problems faced by pool makers. a lot of issues! particularly cos our client is an old pp fork which doesn't handle batch RPC, and I had to write a RPC proxy from scratch just for that. don't know whether it works cos i don't have that kinda hash power to claim a block, you guys can just try it out and see if it works looks like a next todo is to port dcrypt and pob to the peercoin devel github tree. (not claiming first pool, will help with pool setup if ocminer or any exp pool owners are using nomp) |
|
|
|
wow the diff is so high! did not find a POW Block in one Day with 50 Digital Ocean Instances.
just curious, how much is tt in terms of hash power? |
|
|
|
was just discussing with hankrules on our plans for slim and i thought ill also post mine here to get some thoughts haha yea actually i do feel pob in its current incarnation isnt very optimal yet, and ideally it shd decouple from pow and serve to secure the blockchain. this will be a long term goal for pob for me
im also discussing with @slimcoin on the scalability of slimcoin, and might make some changes to the burn decay rates to make it viable in the long run
in the short run i will probably just get the nomp pools ready by inserting the dcrypt algorithm and the slimcoin param, and try to get some experienced pool operators to handle the day 2 day routines.. i am also working w some partners to improve the visual branding and marketing to better convey what Slimcoin offers |
|
|
|
Nice. It would be the best if slimcoin old dev could give you the login data so you could freely change the content of the OP. I'm looking forward for the future of Slimcoin.
I offered to edit and send @slimcoin the updated OP contents whenever it needs to be updated, and he was ok with updating the OP with that. Will see how this arrangement works out! |
|
|
|
Just an update, PM exchange with Dev (timestamps are accurate): hi slimcoin dev,
there is still a huge interest in the novelty of your coin, hash rate is at a peak, bter has been on an uprise, and the community clearly believes there's room for growth.
so far there has been 2 other devs who already contributed code and effort to improve the client. we've also raised nearly 7K SLM for bounties and giveaways.
we are planning to perform a hard fork soon to disable PoS and sync-checkpoints, increment the protocol version to kick out misbehaving clients (this has been identified as a major bugbear on resources and we've issued a temporary fix), and to update a miscellany of issues that has been identified since. you can check out our fork and commits at github.com/kryptoslab/slimcoin.
also, at the point of the hard fork I will likely issue a ReAnn so that I can edit the OP, and work on rallying the community to continue the development.
would like to know your plans for SLM so we can synchronise our efforts!
Hello,
As I have posted before, the reason I "left" this project is some other stuff came up. I say "left" as I still follow its development on the forum. I did state I could do basic maintenance, of which was to hold the central sync node up. I have absolutely no problems with you forking this project, in fact, it would be of great delight to me if you did so. I can offer you assistance in navigating the PoB code and making you a reddit administrator for /r/Slimcoin. As for development, I have nothing much planned in the short termed future.
-P4Titan
|
|
|
|
|
After 1 week of PoB, I've lost 449.6 SLMs to decay but gained 3719.9 from PoB, so that's a rather respectable 8.27x gain ratio. As more people burn this ratio will go down, of course. I assume this would tend to 1 in the long run, though people aren't likely to burn if the return is like just 2x or 3x, unless we get a lot of transaction fees.
That's also roughly equivalent to a PoW hash rate of 750KHs, based on the current hash rate and difficulty. That's like around 600 CPU cores, running off an initial 49152 SLM investment and a 32USD Raspberry Pi.
Thought this might be useful snapshot to paint the potential of PoB!
|
|
|
|
|
