• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
Hi all

Please could some one send me some test coins
mgW35d9qQQjN3D66U957rirpZE57XPftjR

Many Thanks
sent.
Please could someone explain or direct me on how to update my ec2 sever to rc3

Many Thanks
if this is ubuntu and you logged in as normal user, do the 4 lines one after another:
Code:
darkcoind stop && sudo -i
Code:
rm -v /usr/bin/darkcoind && cd /usr/bin && wget http://www.darkcoin.io/downloads/rc3/darkcoind && chmod a+x /usr/bin/darkcoind && exit
Code:
darkcoind -daemon -server -rescan -reindex -testnet && sleep 30 && darkcoind getinfo
Code:
darkcoind masternode start
 
can you post remote server getpeerinfo and getinfo ?
Sorry for the delayed response. My last payment was about 5 hours ago and I'm not seeing my IP address on the masternode list anymore even with the :0 flag, so maybe my MN is finally out of the MN network.

Code:
getpeerinfo.list 
[
    {
        "addr" : "87.230.94.57:19999",
        "services" : "00000003",
        "lastsend" : 1402343888,
        "lastrecv" : 1402343888,
        "bytessent" : 557565,
        "bytesrecv" : 672545,
        "blocksrequested" : 0,
        "conntime" : 1402249704,
        "version" : 70018,
        "subver" : "/Satoshi:0.10.9.9/",
        "inbound" : false,
        "startingheight" : 16187,
        "banscore" : 0
    },
    {
        "addr" : "37.59.18.147:55439",
        "services" : "00000003",
        "lastsend" : 1402343888,
        "lastrecv" : 1402343559,
        "bytessent" : 499915,
        "bytesrecv" : 275818,
        "blocksrequested" : 21,
        "conntime" : 1402249720,
        "version" : 70015,
        "subver" : "/Satoshi:0.9.4.11/",
        "inbound" : true,
        "startingheight" : 16188,
        "banscore" : 0
    },
    {
        "addr" : "184.73.179.187:19999",
        "services" : "00000003",
        "lastsend" : 1402343888,
        "lastrecv" : 1402343888,
        "bytessent" : 531946,
        "bytesrecv" : 529886,
        "blocksrequested" : 10,
        "conntime" : 1402249723,
        "version" : 70018,
        "subver" : "/Satoshi:0.10.9.9/",
        "inbound" : false,
        "startingheight" : 16188,
        "banscore" : 0
    },
    {
        "addr" : "54.187.152.9:45223",
        "services" : "00000003",
        "lastsend" : 1402343888,
        "lastrecv" : 1402343641,
        "bytessent" : 588812,
        "bytesrecv" : 458176,
        "blocksrequested" : 0,
        "conntime" : 1402249733,
        "version" : 70015,
        "subver" : "/Satoshi:0.10.9.4/",
        "inbound" : true,
        "startingheight" : 16188,
        "banscore" : 0
    },
    {
        "addr" : "188.226.248.36:19999",
        "services" : "00000003",
        "lastsend" : 1402343888,
        "lastrecv" : 1402343888,
        "bytessent" : 455193,
        "bytesrecv" : 633225,
        "blocksrequested" : 0,
        "conntime" : 1402249768,
        "version" : 70018,
        "subver" : "/Satoshi:0.10.9.9/",
        "inbound" : false,
        "startingheight" : 16188,
        "version" : 70018,
        "subver" : "/Satoshi:0.10.9.9/",
        "inbound" : true,
        "startingheight" : 16765,
        "banscore" : 0
    },
    {
        "addr" : "68.32.185.63:46356",
        "services" : "00000003",
        "lastsend" : 1402343888,
        "lastrecv" : 1402343888,
        "bytessent" : 12360,
        "bytesrecv" : 9225,
        "blocksrequested" : 0,
        "conntime" : 1402343500,
        "version" : 70018,
        "subver" : "/Satoshi:0.10.9.9/",
        "inbound" : true,
        "startingheight" : 16782,
        "banscore" : 0
    }
]

Code:
getinfo
{
    "version" : 100909,
    "protocolversion" : 70018,
    "walletversion" : 60000,
    "balance" : 360.80000000,
    "blocks" : 16778,
    "timeoffset" : -2,
    "connections" : 47,
    "proxy" : "",
    "difficulty" : 0.55004868,
    "testnet" : true,
    "keypoololdest" : 1401930356,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}
 
Mined two blocks (16778 and 16779) with 33% MN payout - checkpointer not intercepting so far

EDIT: Blocks got orphaned :smile: checkpointer working!

So am i getting this right: The blocks are only checked for validity regarding MN payout by the central checkpointer at the moment?

https://github.com/darkcoinproject/darkcoin/blob/forkfix/src/main.cpp#L2628 translates to "only if you are the checkpoint master, check the blocks for masternode payouts validity"

So the checkpoint master is a specially compiled darkcoind version for this purpose (to include private master key) and this machine will be a bottleneck and target for DDoS attacks, since the clients are not capable to check the payouts for validity by themselves. If checkpointmaster is not available the miners will confirm any payout ratio after the usual 150 block confirmations.

Shouldn't all nodes confirm that the payout is correct or else it gets rejected and orphaned? And if so, if only, say 25% of the masternodes/miners who check are playing straight, is that enough to keep the payouts correct, or is it open to 51% attack?
 
So, as it turns out there's no bug. When the checkpointer is enabled, any blocks that pay out the wrong amount are orphaned and a new chain is started.
When a block is solved and found to be misbehaving, therefore orphaned, is the next solution used for the block? Or, is a new block started? Meaning, can the system be ground to a halt by a bunch of misbehaving miners?
 
Mined two blocks (16778 and 16779) with 33% MN payout - checkpointer not intercepting so far
EDIT: Blocks got orphaned :smile: checkpointer working!

So am i getting this right: The blocks are only checked for validity regarding MN payout by the central checkpointer at the moment?

https://github.com/darkcoinproject/darkcoin/blob/forkfix/src/main.cpp#L2628 translates to "only if you are the checkpoint master, check the blocks for masternode payouts validity"

Correct

So the checkpoint master is a specially compiled darkcoind version for this purpose (to include private master key) and this machine will be a bottleneck and target for DDoS attacks, since the clients/miners are not capable to check the payouts for validity by themselves. If checkpointmaster is not available the miners will confirm any payout ratio after the usual 150 block confirmations.

Basically the way it works is the rest of the network doesn't care about votes or masternode payments, although the pools will submit the blocks in the way to pay the correct masternodes. If the checkpointer is found and attacked we go back to a voluntary masternode payment system while that node is down/being attacked. If the node can eek out 1 checkpoint during the attack (which it should be able to), the attacker will loose multiple blocks via the network switching chains the correct one (they'll be orphaned).

It shouldn't be much of a weakness and again this is a temporary solution.
 
Shouldn't all nodes confirm that the payout is correct or else it gets rejected and orphaned? And if so, if only, say 25% of the masternodes/miners who check are playing straight, is that enough to keep the payouts correct, or is it open to 51% attack?

Before the central checkpointer was introduced, each client was capable to check the payout of a block and reject it when this test failed. With the current code, only the checkpointer will do this check.

I understand why the checkpointer was introduced (to prevent the forks we saw in RC2) - perhaps even these local payout verifications of the miners led to the forks (this was never really hunted down for me), but i feel we introduced a stabilizing element (checkpointer) at the cost of decentralisation.
 
It shouldn't be much of a weakness and again this is a temporary solution.

OK, fine for me - just wanted to address this as potential attack vector and risk. :smile:

Maybe RC4 does not need the checkpointer anymore.

EDIT: Nevertheless it seems the orphaning of my invalid blocks is reducing the number of paid out blocks - or is this just bad luck/coincidence or ramp up due to significantly increased masternode count?
 
Last edited by a moderator:
sent.

if this is ubuntu and you logged in as normal user, do the 4 lines one after another:
Code:
darkcoind stop && sudo -i
Code:
rm -v /usr/bin/darkcoind && cd /usr/bin && wget http://www.darkcoin.io/downloads/rc3/darkcoind && chmod a+x /usr/bin/darkcoind && exit
Code:
darkcoind -daemon -server -rescan -reindex -testnet && sleep 30 && darkcoind getinfo
Code:
darkcoind masternode start
Thanks for the coins and info

I have been setting up with (chaeplin Thanks) How to set up ec2 t1.micro Ubuntu for Masternode part 2/3 but when I get to number 6. add iptables rule. I create
/etc/iptables

and add

cat > /etc/iptables << EOF
#-----
*filter
:INPUT ACCEPT [1038:145425]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [434:87191]
-A INPUT -i eth0 -p tcp -m tcp --dport 9998 -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 8 --connlimit-mask 24 --connlimit-saddr -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 2 --connlimit-mask 32 --connlimit-saddr -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 9999 -j ACCEPT
-A INPUT -i eth0 -p tcp -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9999 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9999 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 9999 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
COMMIT
#-----
EOF

Then I add

/sbin/iptables-restore < /etc/iptables

add line to /etc/rc.local before 'exit 0'

But when I reboot ec2 I get an error whilst logging back in
ssh: connect to host 54.213.147.246 port 22: Connection timed out

Has anyone any ideas

Thanks All

 
OK, fine for me - just wanted to address this as potential attack vector and risk. :smile:

Maybe RC4 does not need the checkpointer anymore.
OK, fine for me - just wanted to address this as potential attack vector and risk. :smile:

Maybe RC4 does not need the checkpointer anymore.

EDIT: Nevertheless it seems the orphaning of my invalid blocks is reducing the number of paid out blocks - or is this just bad luck/coincidence?

Can you get me a list of your orphans?
 
Can you get me a list of your orphans?

Here you are - is this output sufficient?

Code:
[
    {
        "account" : "",
        "address" : "mprn34PKGRYgpRnQTTx9gxm8sHPxBtrwAh",
        "category" : "orphan",
        "amount" : 100.00000000,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "639008af5316aafb2ff18676194503aa52a0e659a29f5189fea45d6d62592405",
        "time" : 1402342815,
        "timereceived" : 1402342818
    },
    {
        "account" : "",
        "address" : "mqriDtEzZN1kwzFKXNLdm2fabNs9PcB5jt",
        "category" : "orphan",
        "amount" : 100.00733334,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "69fd1176ba9c6d6d62926ab04039b6b8060ac923e1bb042e99abfb5135a489f2",
        "time" : 1402343437,
        "timereceived" : 1402343441
    },
    {
        "account" : "",
        "address" : "mqq7BrfVjceZGVaz34yePAcPk6mmjPMyZW",
        "category" : "orphan",
        "amount" : 100.00000000,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "732072ef261ddbe0ff8b0a56ddf0ef543482214ee92fe63e21448c7ff34ca50c",
        "time" : 1402343556,
        "timereceived" : 1402343557
    },
    {
        "account" : "",
        "address" : "mvDK2y18cSJxbiPvPmZfSVUfXdH46k9h7X",
        "category" : "orphan",
        "amount" : 101.33333334,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "e6898520e5b3014b698430ce04a3fc684fb1afbafbc3a954c9429d56dfdc2050",
        "time" : 1402346628,
        "timereceived" : 1402346630
    },
    {
        "account" : "",
        "address" : "mmmLmuFc5y2iBLsvt7PTp62MEaRj35zK6J",
        "category" : "orphan",
        "amount" : 152.00000000,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "e6d87e6d67febdc2183c4f2e4ec8f360998d2d5896acce7fa9e8ea6c8cb1f8ff",
        "time" : 1402346748,
        "timereceived" : 1402346752
    },
    {
        "account" : "",
        "address" : "mrEPMBgHiuWvqUacMDPrT18ndShucKKyKA",
        "category" : "orphan",
        "amount" : 100.66666667,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "e0e71cb71ce215c7c46e56a67b47a181387264dc18c71312fb0e40be19718e83",
        "time" : 1402347210,
        "timereceived" : 1402347210
    },
    {
        "account" : "",
        "address" : "mpARGkch5FcgfT8tCk8YaJgzUvKoiXyAjF",
        "category" : "orphan",
        "amount" : 101.33333334,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "2b9c3ee87f37ce5dbda5bb979fabb045d10465d8cca4297d41b58f4c128a2a15",
        "time" : 1402349671,
        "timereceived" : 1402349672
    }
]
 
Thanks for the coins and info

I have been setting up with (chaeplin Thanks) How to set up ec2 t1.micro Ubuntu for Masternode part 2/3 but when I get to number 6. add iptables rule. I create
/etc/iptables

and add
cat > /etc/iptables << EOF
#-----
*filter
:INPUT ACCEPT [1038:145425]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [434:87191]
-A INPUT -i eth0 -p tcp -m tcp --dport 9998 -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 8 --connlimit-mask 24 --connlimit-saddr -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 2 --connlimit-mask 32 --connlimit-saddr -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 9999 -j ACCEPT
-A INPUT -i eth0 -p tcp -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9999 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9999 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 9999 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
COMMIT
#-----
EOF
Then I add
/sbin/iptables-restore < /etc/iptables

add line to /etc/rc.local before 'exit 0'

But when I reboot ec2 I get an error whilst logging back in
ssh: connect to host 54.213.147.246 port 22: Connection timed out

Has anyone any ideas

Thanks All
Did you add your local IP to the security group via the AWS dashboard? IIRC this was in part 1 of chaeplins guide. If you did, check your ISP hasn't issued you another IP. This had me stumped for a few minutes when it happened to me.
 
Here you are - is this output sufficient?

Code:
[
    {
        "account" : "",
        "address" : "mprn34PKGRYgpRnQTTx9gxm8sHPxBtrwAh",
        "category" : "orphan",
        "amount" : 100.00000000,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "639008af5316aafb2ff18676194503aa52a0e659a29f5189fea45d6d62592405",
        "time" : 1402342815,
        "timereceived" : 1402342818
    },
    {
        "account" : "",
        "address" : "mqriDtEzZN1kwzFKXNLdm2fabNs9PcB5jt",
        "category" : "orphan",
        "amount" : 100.00733334,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "69fd1176ba9c6d6d62926ab04039b6b8060ac923e1bb042e99abfb5135a489f2",
        "time" : 1402343437,
        "timereceived" : 1402343441
    },
    {
        "account" : "",
        "address" : "mqq7BrfVjceZGVaz34yePAcPk6mmjPMyZW",
        "category" : "orphan",
        "amount" : 100.00000000,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "732072ef261ddbe0ff8b0a56ddf0ef543482214ee92fe63e21448c7ff34ca50c",
        "time" : 1402343556,
        "timereceived" : 1402343557
    },
    {
        "account" : "",
        "address" : "mvDK2y18cSJxbiPvPmZfSVUfXdH46k9h7X",
        "category" : "orphan",
        "amount" : 101.33333334,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "e6898520e5b3014b698430ce04a3fc684fb1afbafbc3a954c9429d56dfdc2050",
        "time" : 1402346628,
        "timereceived" : 1402346630
    },
    {
        "account" : "",
        "address" : "mmmLmuFc5y2iBLsvt7PTp62MEaRj35zK6J",
        "category" : "orphan",
        "amount" : 152.00000000,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "e6d87e6d67febdc2183c4f2e4ec8f360998d2d5896acce7fa9e8ea6c8cb1f8ff",
        "time" : 1402346748,
        "timereceived" : 1402346752
    },
    {
        "account" : "",
        "address" : "mrEPMBgHiuWvqUacMDPrT18ndShucKKyKA",
        "category" : "orphan",
        "amount" : 100.66666667,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "e0e71cb71ce215c7c46e56a67b47a181387264dc18c71312fb0e40be19718e83",
        "time" : 1402347210,
        "timereceived" : 1402347210
    },
    {
        "account" : "",
        "address" : "mpARGkch5FcgfT8tCk8YaJgzUvKoiXyAjF",
        "category" : "orphan",
        "amount" : 101.33333334,
        "confirmations" : 0,
        "generated" : true,
        "txid" : "2b9c3ee87f37ce5dbda5bb979fabb045d10465d8cca4297d41b58f4c128a2a15",
        "time" : 1402349671,
        "timereceived" : 1402349672
    }
]

Found the problem, uploading a fix. Should see much lower orphans after this.
 
Updated to 10.9.10, no issues, listed :1, but its been like 5h and no payouts. : got payout since going to bed.

54.255.159.230:19999 1 f912e108979186ce9e4782dc150a12ef25397c00e15749767ede9eba9b9b3dbe moqpGCABQQefuujQ9nsAMJVEiwAXyAMw6o 1000.0
 
Last edited by a moderator:
Thanks for the coins and info

I have been setting up with (chaeplin Thanks) How to set up ec2 t1.micro Ubuntu for Masternode part 2/3 but when I get to number 6. add iptables rule. I create
/etc/iptables

and add
cat > /etc/iptables << EOF
#-----
*filter
:INPUT ACCEPT [1038:145425]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [434:87191]
-A INPUT -i eth0 -p tcp -m tcp --dport 9998 -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 8 --connlimit-mask 24 --connlimit-saddr -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 2 --connlimit-mask 32 --connlimit-saddr -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 9999 -j ACCEPT
-A INPUT -i eth0 -p tcp -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9999 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9999 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 9999 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
COMMIT
#-----
EOF
Then I add
/sbin/iptables-restore < /etc/iptables

add line to /etc/rc.local before 'exit 0'

But when I reboot ec2 I get an error whilst logging back in
ssh: connect to host 54.213.147.246 port 22: Connection timed out

Has anyone any ideas

Thanks All

This part:
cat > /etc/iptables << EOF #-----

Just means end of file, you don't put that into the file, in case that's what you did (I did that once, laugh all you want!) LOL

Also, actually, I just rebooted one of my servers and am unable to log back in. I can't figure it out. Been working on it for a while now, so maybe it's amazon? Hummm, just rebooted, this time from the website manager, and it let me back in :tongue: No idea what was wrong with doing the command reboot? h well, all's well that ends well ;P
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top