Separate names with a comma.
Please sign up to discuss the most innovative cryptocurrency!
Discussion in 'Testing' started by eduffield, Oct 7, 2014.
Yep, checked, getinfo reports v6.
139 tDRK and 8 rounds, finished about in hour, pretty good
I just try 999 tDRK 8 rounds
Enforcement is on! It's looking like the distribution code is working properly. Here's the payouts so far:
Those should all hit 2 before the list starts on 3 payments.
Everything looks great. Darksend works and is way more secure. The reward increases are working and enforced payments to specific masternodes is functioning properly. I think we're good to go.
PS. Masternode payments are going up to 25% within a week from the release. I'll set enforcement to turn on three weeks from release so we can bug the pools and make sure they updated the daemon and stratum.
Looking good Ed. Would it help provide data if I increased hashrate? As I've said before, I need Stratum pool to help...
NICE Work! This is what all MN owners have been waiting for....
I left a solo miner running 10.15.05 just waiting for enforcement to be turned back on and and it forked off just like i had expected.
So this means three more weeks of XwzmEE1cJ6HG84CgJvAt7ADmJ8W9Wh65Tq and XixmyNSGGGXEJEzKghoRnTto5ZVhficSek getting paid for their existing loopholes due to pools not upgrading, right?
Agreed this distribution method is exactly what will attract people to setup a MN as the returns can be predicted! AWESOME work Evan - cant wait for this to go live!
The first address is using the pubkey exploit and will be killed as soon as the network updates.
The second address is a miner who's just cheating by paying the same exact address every time. He'll be killed in three weeks.
Fantastic, secondly, replied on BCT as well, but for the payout structure, how does it work with new nodes coming online with the distribution?
It's a true proof-of-service setup now. So the nodes must be active, as soon as your new node comes online it has a 1 in N chance of being selected each new block (N being the total number of masternodes). After that it can't be paid again for N blocks.
You mean it can't be paid again for N-1 blocks? i.e. there are 3 MNs (A,B,C), and A gets paid in block 1, B gets paid in block 2, and C gets paid in block 3. Now if A can't get paid again for 3 blocks (2,3,4) , there is no node that can be paid in block 4.
Also, can it happen that there is a block where no MN is paid because nodes are coming and going? i.e. in the previous example, A gets paid in block 1, and MNs B and C drop.
I'm sure you already have these covered, just double checking.
Yeah I tried to test some of this on TESTNET by waiting to see my MN in the masternode winners list and then i shutdown my MN and still got paid, but it didn't come back up to get paid again until i brought it back online. But will test again on 15.6 with enforcement
There's a 10% margin to give the algo some room for nodes coming and going. So if you were super lucky you could get paid 10% more than everyone else. If there's no valid node, then the networks enforcement turns off for that block and the pool will pay a random node of it's choosing (which won't happen very often).
It takes 70 minutes of inactivity for a node to stop getting paid. But this framework now supports actively monitoring on nodes to make sure they're still up before payment, it's just not implement yet.
Yeah, I need to test the stratum patch anyway. I'll setup a pool and post the URL in a few minutes.
Ok cool, one more special case - does it handle protocol updates as well, when old MN versions are not counted into the total number, this is a situation where the number of nodes will change more radically than 10%.
I've been building these test releases in daemon mode, but I haven't had any luck getting my test masternode to work. I get clients connecting for iscollateralvalid() that list dozens of 0.4tdrk inputs which causes the CTransaction::CheckTransaction() : duplicate inputs error to appear. I made a special client build (daemon with darksend enabled) that only connects to my masternode, and it is behaving in a way that seems strange to me:
on the first "dsa" the client sends, one input is listed and i get the "please submit!" message on the masternode. after that the client keeps doing dsa again with one more input accumulating after every try, which results in the duplicate input error appearing on the masternode.
Am I doing something wrong here?
it looks like it works once i add txCollateral.SetNull() before each CreateCollateralTransaction() in DoAutomaticDenominating. I have no idea what i'm doing though!
New Stratum Pool:
This is testing the new patch, can I get some hashing power? Thanks
"Unable to create account: Coin address is not valid" -- doesn't accept testnet address.
Try again, should work now
no work available error. tried
site help shows: "stratum+tcp://localhost:3333"
Maybe you could do something about it?
Start by asking your exchanges in China to allow Darkcoin trading
Yeah, China adoption suffers from instamine accusation - only good PR can get us over this...
eduffield: I'm still getting "Darksend request incomplete: collateral not valid. Will retry..."
I've noticed this a few times too.