v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
flare said:
eduffield : Is it possible that this piece of code is vulnerable for tampered blocks?
Code: 
for (unsigned int i = 1; i < vtx[0].vout.size(); i++)
                            if(vtx[0].vout[i].nValue == masternodePaymentAmount && mv1.GetPubKey() == vtx[0].vout[i].scriptPubKey) {
                                foundMasterNodePayment++;
                            } else if(mv1.GetPubKey() == vtx[0].vout[i].scriptPubKey) {
                                printf(" BAD MASTERNODE PAYMENT DETECTED:  %"PRI64u"\n", vtx[0].vout[i].nValue);
                            }

Since your test loop is starting at index 1, you are assuming that index 0 has to be miner reward, which is not the case for Block 18135. And the printf is not really catching the exception properly. I don't know yet if this can the exploited, e.g. by swapping value of miner and masternode rewards from 80:20 to 20:80 and pushing the 80% vout to the top in the tx....
Click to expand...

It can't be exploited, but if the masternode payment is the first entry then the block would get rejected by the whole network. I might as well fix it while we have the chance.
 
flare said:
Or use the payee field from blocktemplate and match the corresponding payout
Click to expand...
blocktemplate is used for real time tracking.
blocktemplate can't be used with previous blocks.
Searching vout is best option. With p2pool on testnet(small user, too high payout), it's more complicated.

And payout to masternode is not only 20 % of reward but 20 % of reward plus 20% of collected tx fee.

tx fee ;D
 
chaeplin said:
blocktemplate is used for real time tracking.
blocktemplate can't be used with previous blocks.
Searching vout is best option. With p2pool on testnet(small user, too high payout), it's more complicated.

And payout to masternode is not only 20 % of reward but 20 % of reward plus 20% of collected tx fee.

tx fee ;D
Click to expand...

So it's not that trivial to determine what the actual payee/amount vout was :cool:
 
Just move 5M hashpower to the NOMP for testing.
and my MN(100913) with Cold/Hot mode works pretty fine to me. (211.99.224.196)

my only problem is that: when finishing the cold and hot Maternode, the hot one successfully running massage. if i just killall my darkcoind daemon or stop masternode on the cold(local). the hot(remote) will become status "0" on the masterlist. Now i have completely follow the Evan's guide: reboot the local:smile:, and it's seems pretty good for me now. The hot(remote) works perfect..
 
Raico said:
Just move 5M hashpower to the NOMP for testing.
and my MN(100913) with Cold/Hot mode works pretty fine to me. (211.99.224.196)

my only problem is that: when finishing the cold and hot Maternode, the hot one successfully running massage. if i just killall my darkcoind daemon or stop masternode on the cold(local). the hot(remote) will become status "0" on the masterlist. Now i have completely follow the Evan's guide: reboot the local:smile:, and it's seems pretty good for me now. The hot(remote) works perfect..
Click to expand...

Well I just updated my other node a few hours ago to .9.13, and got instantly picked up on chaeplin's list :1 - immediately turned off local - no issues. Haven't received payout yet, but now with loads more MN's it does seem to take longer, sort of like p2pool ramp-up.
What does remote "darkoind masternode debug" say when it reports :0 ?
 
snogcel said:
Great suggestions both - honestly at this point I'm wondering if this is a weirdness with my Arch install. I've inserted that modified iptable (set it up for -j DROP), however still seeing the same thing. When running netstat locally I see the following:
Code: 
[root@localhost .darkcoin]# netstat -tulanp | grep 0:19999
tcp        0      0 0.0.0.0:19999           0.0.0.0:*               LISTEN      787/darkcoind
tcp        0      0 10.0.0.159:34075        54.80.186.130:19999     ESTABLISHED 787/darkcoind
tcp        0      0 10.0.0.159:34035        54.80.186.130:19999     TIME_WAIT   -

However, when I run nmap (against my testnet box public IP) on my EC2 box I get the following:
Code: 
Host is up (0.048s latency).
PORT      STATE  SERVICE
9999/tcp  closed abyss
19999/tcp open   unknown
Click to expand...

Hey guys so I ended up removing Arch Linux and replaced it with XUbuntu - but strangely enough was still having the same problems up until a few minutes ago, when I realized I was connecting to an Access Point, and not my Comcast Router itself. Going straight to the Comcast Router ~seems~ to have corrected the problem, however in the process of reinstalling linux I lost my testnet coins (backed up /.darkcoin/wallet.dat instead of /.darkcoin/testnet3/wallet.dat, doh!)

Could anyone please send 1000drk to mvJkju1wcxYTA9h1cbu8Uf37pzby6kCKx8 ?

Thanks!
 
daaarkcoins said:
./darkcoind sendtoaddress mvJkju1wcxYTA9h1cbu8Uf37pzby6kCKx8 1000
3f74c1f360590324e806b424ff0b0abafc05b8b96d875d0f0632e2f36987c21b
Click to expand...

Thanks! Unfortunately still having the same problem - arrrgghh :-\

Does anyone have any insight on how exactly darkcoind is identifying if local ports are open? I'm completely stumped by this, unfortunately a LAN connection isn't possible on this box so I'm stuck with wifi.
 
yidakee said:
Well I just updated my other node a few hours ago to .9.13, and got instantly picked up on chaeplin's list :1 - immediately turned off local - no issues. Haven't received payout yet, but now with loads more MN's it does seem to take longer, sort of like p2pool ramp-up.
What does remote "darkoind masternode debug" say when it reports :0 ?
Click to expand...
well, the "darkcoind masternode debug" shows the same successfull massage in the remote when chaeplin's list shows "0".
and i think you're right that immediately turned off local which, in my case, i just reboot. But the result is the same.
So IMO, after setting up the remote, we just need to turn off/reboot the local and do no more operation like "darkcoind masternode stop" in local. But very strange that if i "killall darkcoind" in local, the remote seems not working anymore.(Chaeplin's list shows status "0", and the haven't received any payout for 3 hours. should i need to be more patient?)
nevertheless, the Cold/Hot Masternode and the network are both pretty good right now. May be it's just a little misoperation or someone might notice for someting, in case.
Thanks yidakee.:smile:
 
Yup, with the influx of so many new nodes, it seems to take longer to start getting payouts. I confess, I have not studied enough on the voting system to comment. In fact, the little I have puzzled me even more, I think it may be a bit too far out of my reach. In any case, yes, been +4h for me without payouts, on 10.9.6 (previous active version) it took me +5 hours and then they started rolling in.
 
Everything is looking good, I saw the orphans are being dealt with correctly and the logs show no errors or problems on all of my various nodes. I've set the 20th as the launch date!

I'll start compiling everything and updating core infrastructure, then I'll message all of the pool operators/exchanges/everyone else.
 
eduffield said:
Everything is looking good, I saw the orphans are being dealt with correctly and the logs show no errors or problems on all of my various nodes. I've set the 20th as the launch date!

I'll start compiling everything and updating core infrastructure, then I'll message all of the pool operators/exchanges/everyone else.
Click to expand...

Evan... I may be totally out of line here as I know nothing of coding... But that is just 8 days away. If you announce a pull-forwards release and then something comes up, and pull back... that will look much worse and more likely discredit DRK.

I would suggest not releasing a statement so soon, give it a few days and lets all collectively do our best to break testnet somehow.

Having said that, if all the issues and angles have been addressed and you're confident everything is taken care of, lets DO IT ! ;)
 
yidakee said:
Evan... I may be totally out of line here as I know nothing of coding... But that is just 8 days away. If you announce a pull-forwards release and then something comes up, and pull back... that will look much worse and more likely discredit DRK.

I would suggest not releasing a statement so soon, give it a few days and lets all collectively do our best to break testnet somehow.

Having said that, if all the issues and angles have been addressed and you're confident everything is taken care of, lets DO IT ! ;)
Click to expand...

From here on I'm going to be setting rough deadlines (Late June) for projects because the coding is what is unpredictable. Then after everything is working and everyone signs off on the release setting a firm date via the code and pushing out the changes to the network. The vast majority of the network can update in 8 days, so that's definitely not an issue. If it were more complicated of an update, I'd set it further out.
 
Status
Not open for further replies.
Back
Top