v0.10.15.x Testing

Status
Not open for further replies.
139 tDRK and 8 rounds, finished about in hour, pretty good :smile:
 
Enforcement is on! It's looking like the distribution code is working properly. Here's the payouts so far:

Payments ADDR
2 mg7j7YAhqUbLrN1btxZcnhW18ydCk7wACh
2 mhDE2DkKDK1Q3TVv3Gdg3GKMzNH7bxzF7M
2 miq9MsJvrdypV1ovpGSYvShBpMX7A5FaqU
1 mjhQ5PXZ6TftozhvMffmZczQU5cTAJbo35
2 mkFnwmgWU5MEVybrphXF4oBpZZ5nTyZAEL
1 mkkc3ac6PFKax1AzK7SeqHJUMUhwnHT5sj
1 moQgMKbaQAZKCCwAqCZvHt6ijouXCNGpYy
1 moTGqJBcDTtUpr2a7fSRYLUVNnMtcCME6Z
2 moufT7XNgdCjWnYyJUyuLZjK64zkfatfwM
2 mpCjmn7rKUs6TcXeXxTKoBK1wtkC1Qsune
1 mpMVevHGJCuBpqxFqbah1dgkSDnyi58nTb
1 mpV2d8vgC7LQNNzXzS3E84TMdykQQvHvkX
2 mpYsqsaz4Dcq3PSXSAS6QAVB6rPMMEcGY6
1 mrtY9qopFHzyqcXju13xFSE2Py6gVUWL6S
1 msYvxx52hVZjwDrgi1AHgmNUpxrTg1ctxT
1 mtBF5aK8sUP8NADWmnq7gC775TePFx42ro
1 mtfFVhkB4dsn7xRNxzWjJGEEHPSeQhon8X
1 mtohxUb85JwGutcg7y3UoAXhEDKQYkPop9
1 mvcEegL5wRP5kQ4A445zRhJjCjbZz9C2vF
2 mvK4V9LsPZvjgCaEPGq5d9b8xfKf3LiETt
2 mvxbSnZWL2jk3xxpPbLosXhSQ5jUKTUz14
1 mwBSmtHcH8jvUK6gr7F1w43HYttAGe9BFY
1 mwTXxpQW32AKtQUYhNKmTpgW3TmDDS8RBF
2 my9VPHXbbYiV84CXYfj1FzmNoMrmjv1duv
2 mybEwGJB98ZHEJkNs5Xa2Pps4DxUNMT2Yf
2 myKtKKwAnQWXR78QndMu5sjGoovPbu4jkC
1 myZ9uTjQeEH1N3Mf4iAtw8pRV2DFUYHzeu
1 mzyWRFPLH8q5F1B8isJ7E2uSJGhJSuDRKY
2 n15eS391XV1KMooJSX6GcWAwMDP43ojXtL
1 n31XM9Bucj1HHCiXzC5YtLKnqfKcwWgJ7n
2 n3477ZfbKrovCAZ8WgBHHk1f9YwzWgjJ3o
2 n43UCKkMybVQ7bFBfyZ2wJciHTetheyuc1
1 n4Ly2sMUYJ9sq7dmrESv9gftYb4udweubP

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...
 
eduffield said:
Enforcement is on! It's looking like the distribution code is working properly. Here's the payouts so far:
Click to expand...

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?
 
Miner237 said:
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.
Click to expand...
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!
 
oblox said:
So this means three more weeks of XwzmEE1cJ6HG84CgJvAt7ADmJ8W9Wh65Tq and XixmyNSGGGXEJEzKghoRnTto5ZVhficSek getting paid for their existing loopholes due to pools not upgrading, right?
Click to expand...

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.
 
oblox said:
Fantastic, secondly, replied on BCT as well, but for the payout structure, how does it work with new nodes coming online with the distribution?
Click to expand...

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.
 
eduffield said:
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.
Click to expand...

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. :)
 
illodin said:
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. :)
Click to expand...

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
 
illodin said:
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. :)
Click to expand...

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).
 
Miner237 said:
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
Click to expand...

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.
 
eduffield said:
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).
Click to expand...

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?
<edit>
it looks like it works once i add txCollateral.SetNull() before each CreateCollateralTransaction() in DoAutomaticDenominating. I have no idea what i'm doing though!
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top