v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
eduffield said:
chaeplin

Is nomp working? It hasn't had a block in awhile.
Click to expand...
in
Code: 
2014-06-11 18:51:22 ERROR: CheckBlock() : Vote not found in previous block

2014-06-11 18:51:22 ERROR: ProcessBlock() : CheckBlock FAILED

Debug log is placed to web link(same one in email)

EDIT: I restarted daemon with -reindex.
still CheckBlock.

resynced.
 
Last edited by a moderator:
eduffield said:
I just ran a bad daemon/p2pool and tried creating blocks that were tampered with, everything was rejected... looks like everything is working perfectly.
Click to expand...

Network looks very solid so far.

My tampered solominer got rejected from network yesterday, and ended on his own fork alone - since i disabled the CheckBlock() code and it confirmed his tampered blocks while network rejecting them :grin:

I recently tried to cause "DoS due to log spam" with a tampered protocolversion client, but the masternodes didn't didn't even care one bit.

Additionally i connected a RC2 masternode to testnet, to find that it only can participate as a normal client. If you start the masternode you will find it isolated, as the protcolversion/message format is incompatible between RC2 and RC3.

Still a minor issue with current versioning of 0.9.x client: It should be 0.9.5.12, but the binary to download is 0.9.4.12 (clientversion 90412) - so you accidentically stepped back a revision number during checkpointer rollback in git.

BTW: Whats the rationale of currently having different versioning schemes for client (0.9.5.x) and masternode (0.10.9.x)? What about having a common scheme (0.12.x.y) for both and change binary name for masternode to 'darkcoinmnd' instead? So the corresponding binaries will always be

darkcoind-0.12.x.y
darkcoin-qt-0.12.x.y
darkcoinmnd-0.12.x.y

(You may have noticed that i am very keen on a consistent versioning scheme to improve release management/process... )

I am currently in the process of getting the gitian builds to work, so that darkcoin is able to provide deterministic builds of binaries which are signed for validity - learning a lot from bitcoin's process here.

I plan to be finished this weekend and to setup something similiar to https://download.litecoin.org/litecoin-0.8.6.2/ where you can download all recent and old versions of darkcoin for all supported operating systems (Win, Linux, MacOS X). Doing good progress on this.
 
Last edited by a moderator:
I am very keen on you flare. Please rest assure that I will be tipping you as soon as MN gets going. Sweat and blood, I have 2 MN's + 3 DRK. I have a small list of tipsters to thank, I only wished I could send a hug or a kiss along with the tx id.

You too chaeplin! And Instacash, though he's not around here that I know of... and a few select others
You have no idea what all this means to me. Not only the prospects, but actually being part of all this, means a lot to me.

Thank you all, now get back to work, 'you code munchers you! :tongue:
 
flare said:
Network looks very solid so far.

My tampered solominer got rejected from network yesterday, and ended on his own fork alone - since i disabled the CheckBlock() code and it confirmed his tampered blocks while network rejecting them :grin:

I recently tried to cause "DoS due to log spam" with a tampered protocolversion client, but the masternodes didn't didn't even care one bit.

Additionally i connected a RC2 masternode to testnet, to find that it only can participate as a normal client. If you start the masternode you will find it isolated, as the protcolversion/message format is incompatible between RC2 and RC3.

Still a minor issue with current versioning of 0.9.x client: It should be 0.9.5.12, but the binary to download is 0.9.4.12 (clientversion 90412) - so you accidentically stepped back a revision number during checkpointer rollback in git.

BTW: Whats the rationale of currently having different versioning schemes for client (0.9.5.x) and masternode (0.10.9.x)? What about having a common scheme (0.12.x.y) for both and change binary name for masternode to 'darkcoinmnd' instead? So the corresponding binaries will always be

darkcoind-0.12.x.y
darkcoin-qt-0.12.x.y
darkcoinmnd-0.12.x.y

(You may have noticed that i am very keen on a consistent versioning scheme to improve release management/process... )

I am currently in the process of getting the gitian builds to work, so that darkcoin is able to provide deterministic builds of binaries which are signed for validity - learning a lot from bitcoin's process here.

I plan to be finished this weekend and to setup something similiar to https://download.litecoin.org/litecoin-0.8.6.2/ where you can download all recent and old versions of darkcoin for all supported operating systems (Win, Linux, MacOS X). Doing good progress on this.
Click to expand...

Awesome! I've just been compiling all of this on the fly (which is often why things are inconsistent/etc), so the deterministic builds would be greatly appreciated.

That's also good news about the DoS via protocol version. Tampering with that stuff shouldn't do much at all, but it's nice to see it verified.
 
flare said:
Hi Evan,

good news: I had another round of my tcpping script on masternodes and the changes to include port checking vastly improved masternode network stability and reliability!

There are currently 70 masternodes registered in the masternode list. tcpping is delivering the following results:

Code: 
54.198.191.99 -->seq 0: tcp response from ec2-54-198-191-99.compute-1.amazonaws.com (54.198.191.99) [open]  1.561 ms
54.198.252.150 -->seq 0: tcp response from ec2-54-198-252-150.compute-1.amazonaws.com (54.198.252.150) [open]  1.608 ms
54.203.217.224 -->seq 0: no response (timeout)
54.211.202.218 -->seq 0: tcp response from ec2-54-211-202-218.compute-1.amazonaws.com (54.211.202.218) [open]  1.708 ms

So the masternode network on testnet is not only listening and functional, its almost 100% up to date regarding client updates, which also mean that we have very dedicated masternode operators on testnet - thank you all for your effort.

So the basic implementation of proof of service in RC3 (aka "check for open port 19999/9999") is working as expected and the full implementation (aka "check if darksend is relayed") can be scheduled for RC4.

And now back to testing RC3 :smile:
Click to expand...

flare:
I have one of the timeouts on your list: 54.203.217.224 -->seq 0: no response (timeout)

I am pretty sure I have stayed connected, havn't touched the server since I updated it last

getinfo:
darkcoind getinfo
{
"version" : 100912,
"protocolversion" : 70018,
"walletversion" : 60000,
"balance" : 7695.32629998,
"blocks" : 17995,
"timeoffset" : 0,
"connections" : 8,
"proxy" : "",
"difficulty" : 0.62303919,
"testnet" : true,
"keypoololdest" : 1401626368,
"keypoolsize" : 99,
"paytxfee" : 0.00000000,
"mininput" : 0.00001000,
"unlocked_until" : 0,
"errors" : ""
}
Click to expand...

last transaction

{
"account" : "",
"address" : "mw23256bSTqEkP6ThTRrY3KNicB9cfwzLR",
"category" : "immature",
"amount" : 30.20000000,
"confirmations" : 18,
"generated" : true,
"blockhash" : "00000000a0ffbd18235b9997cce1831c94fa5f37f532e681ecd465fa31f28ae7",
"blockindex" : 0,
"blocktime" : 1402533695,
"txid" : "c6a08c8b9f42c7a847f1ff4b11fe3cf6f6e1ca8898d6d583746532af9c239a6b",
"time" : 1402533695,
"timereceived" : 1402533830
}
Click to expand...
 
Propulsion said:
Mind signing that with a gpg key?:wink:
Click to expand...

Yeah, thought about that too - in fact i have been scammed with spoofed bitcoin addresses in forum posts too.

So here you are

Code: 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

flare <[email protected]>
Software Engineer, IT-QA/QM subject matter expert and ISO9001 auditor.
Tips accepted: XvKkW3NJFhTr9hcgbV8EQcGqbCCshDS8vj

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFTmTYOEUWEsSLrMtMRAjlWAJ0dp583TtCBwRCvkbmFbB1jsMFXTACcCckU
Facb+AE6VfJ0HXfPHb9tEG8=
=GZfL
-----END PGP SIGNATURE-----
 
Last edited by a moderator:
We have sudden drop of masternode at block 18033.
http://tdrk.poolhash.org/blocks/masterlist/18033.txt
Code: 
Current time: 1402543622
ip status address lastseen sec(ago) activeseconds
107.20.28.12:19999 0 n2eL7u3pgqMYNSxVbvHDTL1WJJzS92qUbU 0 1402543622 -1402455246
54.83.143.1:19999 0 mh7mPbsJ3SarRbHDrGcWth8fD3J4fBMuY6 0 1402543622 -1402457042
107.20.122.204:19999 0 mp6rSxNV1gtSB2KMFDLMkEK6pcFQgEGfXC 0 1402543622 -1402455253
54.76.47.232:19999 1 mpKNkHEdgtxQAjTCkGB4ZwHAED74qwjDvj 1402542266786676 1355 245076
184.73.114.32:19999 0 mnJM9UeHTSWUtPQUnycxxLccpWat2WUyMJ 0 1402543622 -1402455238
54.224.75.195:19999 0 mxjko3miNiPCPqcHqnCDW6XUSgHfPs8TEs 0 1402543622 -1402455247

I add sec(ago) using
(currentunixtime * 1000000 - 'masternode list lastseen') / 1000000
 
chaeplin said:
We have sudden drop of masternode at block 18033.
http://tdrk.poolhash.org/blocks/masterlist/18033.txt
Code: 
Current time: 1402543622
ip status address lastseen sec(ago) activeseconds
107.20.28.12:19999 0 n2eL7u3pgqMYNSxVbvHDTL1WJJzS92qUbU 0 1402543622 -1402455246
54.83.143.1:19999 0 mh7mPbsJ3SarRbHDrGcWth8fD3J4fBMuY6 0 1402543622 -1402457042
107.20.122.204:19999 0 mp6rSxNV1gtSB2KMFDLMkEK6pcFQgEGfXC 0 1402543622 -1402455253
54.76.47.232:19999 1 mpKNkHEdgtxQAjTCkGB4ZwHAED74qwjDvj 1402542266786676 1355 245076
184.73.114.32:19999 0 mnJM9UeHTSWUtPQUnycxxLccpWat2WUyMJ 0 1402543622 -1402455238
54.224.75.195:19999 0 mxjko3miNiPCPqcHqnCDW6XUSgHfPs8TEs 0 1402543622 -1402455247

I add sec(ago) using
(currentunixtime * 1000000 - 'masternode list lastseen') / 1000000
Click to expand...

Yes, i noticed that drop to, and there has to be a reason why the masternode count is oscillating between ~20 and ~70



I reran the tcpping script and the nodes having a :0 state are still responding on port 19999, and now the count popped back to 70 again. Seems to be a avalance like effect, but the nodes never stopped to be available :what: - or is someone updating 50 masternodes at a time? Unlikely for testnet...

Perhaps Evan has a guess why this is happening?
 
Last edited by a moderator:
flare said:
Yes, i noticed that drop to, and there has to be a reason why the masternode count is oscillating between ~20 and ~70



I reran the tcpping script and the nodes having a :0 state are still responding on port 19999, and now the count popped back to 70 again. Seems to be a avalance like effect, but the nodes never stopped to be available :what: - or is someone updating 50 masternodes at a time? Unlikely for testnet...

Perhaps Evan has a guess why this is happening?
Click to expand...

24h period..

5nXPh5V.png




Ping every 30min.
Is this happen on time ?

What if delay is happen ? a minute, every ping ?

24 * 2 = 28 == alomost 30 min.
 
Last edited by a moderator:
chaeplin said:
24h period..
(serveral server restart happend)
5nXPh5V.png
Click to expand...

Do you refer to your server being restarted, or the other (70) servers being restarted? I monitored the drop from 70 to 19 on my three masternodes simultanously as well - so its not exclusively your server that is seeing this, it affected the whole MN network.
 
flare said:
Do you refer to your server being restarted, or the other (70) servers being restarted? I monitored the drop from 70 to 19 on my three masternodes simultanously as well - so its not exclusively your server that is seeing this, it affected the whole MN network.
Click to expand...
Oh my server. drop to zero happpened when darkcoind was updated(no monitering = 0)
 
eduffield said:
I just ran a bad daemon/p2pool and tried creating blocks that were tampered with, everything was rejected... looks like everything is working perfectly.
Click to expand...

But your tampered blocks are confusing chaeplins stats :grin:

chaeplin : Evan is messing around with the order of the vouts in the Blocks, so your tool cannot expect masternode payment to be the second entry. It seems http://tdrk.poolhash.org/ is always searching for second vout-entry in the generation tx to determine who got paid and what.

e.g. Block 18135 correctly paid out 30 DRK to masternode - and not 118.83828265. Adress displayed is miners address.

So you will have to change your code to search for 20% payment i guess :grin:

It was getting suspicious that one masternode (mt2ScQSwpsohN8KC9CuFGCuCuvyJkCY8iE) was having such extremely good luck in the voting

Code: 
last 90 blocks
     17 mt2ScQSwpsohN8KC9CuFGCuCuvyJkCY8iE
      7 muduy36Y9rLcpWEoT14p1TGXNggwSRZSa4
      3 mzArKcPEqCw812YBjKav4jArBD29mpnn1o
      3 mrXi3JeVASCew48xZCRnHq1L2M4FLvJDhT
[...]


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....

Will give it a try :grin:
 
Last edited by a moderator:
flare said:
Yes, i noticed that drop to, and there has to be a reason why the masternode count is oscillating between ~20 and ~70



I reran the tcpping script and the nodes having a :0 state are still responding on port 19999, and now the count popped back to 70 again. Seems to be a avalance like effect, but the nodes never stopped to be available :what: - or is someone updating 50 masternodes at a time? Unlikely for testnet...

Perhaps Evan has a guess why this is happening?
Click to expand...

Hey Guys,
The answer to flare's question is "Yes, someone is updating 50 masternodes at a time on the testnet". And I am that someone.
I'm trying to learn how to use a server management tool called SaltStack ( http://docs.saltstack.com/en/latest/index.html ). flare's chart matches my availability to upgrade the darkcoind daemon to Evan's latest version. It's rather quick hence the almost instant vertical climb back to ~70 masternodes. While unavailable, I let them run therefore they are responding to port pings on 19999.
If it is causing a problem, I can reduce the number of servers or take them offline. I had notice a while back that there were less than 10 masternodes on the testnet while 200+ remained on the mainnet. I thought I would try to help out while learning a new tool.
Apologies for the confusion.
atavacron
 
atavacron said:
Hey Guys,
The answer to flare's question is "Yes, someone is updating 50 masternodes at a time on the testnet". And I am that someone.
[...]
Apologies for the confusion.
atavacron
Click to expand...

Brilliant :grin: - you made my day :grin::grin:
 
Status
Not open for further replies.
Back
Top