v0.10.15.x Testing

Status
Not open for further replies.

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
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.
 

stonehedge

Well-known Member
Foundation Member
Jul 31, 2014
696
333
233
Looking good Ed. Would it help provide data if I increased hashrate? As I've said before, I need Stratum pool to help...
 

Miner237

Well-known Member
Foundation Member
May 28, 2014
510
223
213
Enforcement is on! It's looking like the distribution code is working properly. Here's the payouts so far:
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.
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
So this means three more weeks of XwzmEE1cJ6HG84CgJvAt7ADmJ8W9Wh65Tq and XixmyNSGGGXEJEzKghoRnTto5ZVhficSek getting paid for their existing loopholes due to pools not upgrading, right?
 

Stealth923

Well-known Member
Foundation Member
Mar 9, 2014
343
370
233
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.
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!
 
  • Like
Reactions: thelonecrouton

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
So this means three more weeks of XwzmEE1cJ6HG84CgJvAt7ADmJ8W9Wh65Tq and XixmyNSGGGXEJEzKghoRnTto5ZVhficSek getting paid for their existing loopholes due to pools not upgrading, right?
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.
 
  • Like
Reactions: Light and Miner237

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
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.
 

illodin

Member
Apr 26, 2014
122
71
78
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. :)
 
  • Like
Reactions: thelonecrouton

Miner237

Well-known Member
Foundation Member
May 28, 2014
510
223
213
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
 

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
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. :)
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).
 
  • Like
Reactions: thelonecrouton

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
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
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.
 
  • Like
Reactions: thelonecrouton

illodin

Member
Apr 26, 2014
122
71
78
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).
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%.
 
  • Like
Reactions: thelonecrouton

pinestabe

New Member
May 1, 2014
26
9
3
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:

qvvp

New Member
Oct 13, 2014
9
4
3
我們是開放的建議!我們應如何使它更受歡迎?
在中国新浪微博大v(微博名人)一直在宣传BTSX的信息,而Darkcoin除了CCTV报道的一个月内价格饭15倍以外,点击量最大的网页是关于Darkcoin骗局的---就是所谓预挖的问题。
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
在中国新浪微博大v(微博名人)一直在宣传BTSX的信息,而Darkcoin除了CCTV报道的一个月内价格饭15倍以外,点击量最大的网页是关于Darkcoin骗局的---就是所谓预挖的问题。
Yeah, China adoption suffers from instamine accusation - only good PR can get us over this...
 
  • Like
Reactions: moli
Status
Not open for further replies.