[quote=“coinotron, post:38, topic:3875”]Windows.
I build ppcoind from sources on github. I’m using is this version : https://github.com/ppcoin/ppcoin/commit/f01ccea4b515ce6e01f4a50cc6b50a4f3337c7ee
There were some commits after that. They seem to be cosmetic but maybe they introduced something important?[/quote]
You should not need any commits after that. Are you on Windows 10 or 7? Is it a 32-bit or 64-bit version?
windows 8.1 64 bit
and
windows server 2012 R2 Standard
Good :)[/quote]
Same result. Any other ideas
“blocks” : 234612,
[
{
“addr” : “51.9.56.81”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309995,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.0/Peerunity:0.2.1(v0.2.0-2-g3cb34c9)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “62.163.212.157”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309995,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3-gf01ccea-Peerbox)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “78.8.188.249”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309996,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “93.80.182.24”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313813,
“conntime” : 1462309996,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.0/Peerunity:0.2.1(v0.2.1)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “104.236.180.129”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313773,
“conntime” : 1462309996,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “107.170.43.92”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313782,
“conntime” : 1462309996,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “107.170.209.76”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313782,
“conntime” : 1462309996,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “113.17.90.227”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309996,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “128.199.159.68”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309997,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.0/Peerunity:0.2.1(v0.2.1)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “142.4.218.174”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313782,
“conntime” : 1462309997,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “146.185.137.249”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309997,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “158.69.225.143”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313782,
“conntime” : 1462309997,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.0/Peerunity:0.2.0(v0.2.0)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “176.9.16.102”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309997,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “176.31.122.170”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313782,
“conntime” : 1462309997,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “178.62.105.210”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462309998,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.0/Peerunity:0.2.1(v0.2.0-2-g3cb34c9)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234885,
“banscore” : 0
},
{
“addr” : “149.210.215.250”,
“services” : “00000001”,
“lastsend” : 1462313782,
“lastrecv” : 1462313783,
“conntime” : 1462310903,
“version” : 60006,
“subver” : “/Satoshi:0.6.3/Peercoin:0.5.3(v0.5.3ppc-beta)/”,
“inbound” : false,
“releasetime” : 0,
“height” : 234886,
“banscore” : 0
}
]
What client are you using?
Peerunity
“version” : “v0.2.1”,
[quote=“cflocation, post:45, topic:3875”]Peerunity
“version” : “v0.2.1”,[/quote]
Strange. Try to leave it running for a while.
I think Peercoin network is in a serious condition.
I assume https://peercoin.mintr.org/ and https://coinplorer.com/PPC are right because they always have higher highest block number than my clients have.
I first found the problem when I read the forum. My peerunity (32bit win7) had less highest block then. So I deleted the blk* addr.dat and database/* files and downloaded from scratch. However my client was still between 10-20 block behind coinplorer, and the GUI shows the green tick(?!). I found that my peerunity was on the same fork of coinplorer because the blocks were the same. It also had the ssame blocks compared with a Rasp-pi that runs ppcoind.
I find 40% of the peers were on 0.4.0. What happens if you have a mixeed number of clients, some 0.5.x some 0.4.0? I don’t know. So I use addnode to add a bunch of 0.5.3 IPs I found from coinexplorer
addnode=171.111.239.116
addnode=50.107.97.125
addnode=73.211.90.130
addnode=24.155.192.146
addnode=72.179.10.209
addnode=67.247.254.74
addnode=176.9.16.102
addnode=85.25.207.141
addnode=94.101.39.58
and redownload from scratch AGAIN. And got the SAME results. Now my client was stuck 100+ blocks behind the above web sites.
Not to be discouraged, I use a proxy to make peerunity see the network through an IP in the US. I can see it trying to reorg but couldn’t.
I have a ppcoin official client which I stopped using on March 9 since peerunity was upgraded to 0.2. So I quit peerunity and fired it up in a totally separate datadir. It got stuck at 234725, behind the web sites highest (234903), and trying. Here is part of its debug.log. I think people outside N AMerica and W Europe are havign serious problems
[tt]
got inventory: block 000000000000000563a6 new
askfor block 000000000000000563a6 1462320803000000
2016-05-04 00:13:24 UTC received: block (292 bytes)
received block 000000000000000563a6
ProcessBlock: ORPHAN BLOCK, prev=72416b50cbe1c6172ed6
2016-05-04 00:13:24 UTC sending: getblocks (965 bytes)
askfor block a0b3d94de8551da371ec 1462320739000000
2016-05-04 00:13:24 UTC received: checkpoint (110 bytes)
ProcessSyncCheckpoint: pending for sync-checkpoint 000000000000000563a6a905cb952
226e347da78d721e70f9ed640de7a7815b2
2016-05-04 00:13:24 UTC sending: getblocks (965 bytes)
askfor block a0b3d94de8551da371ec 1462320859000000
2016-05-04 00:13:24 UTC received: checkpoint (110 bytes)
ProcessSyncCheckpoint: pending for sync-checkpoint 000000000000000563a6a905cb952
226e347da78d721e70f9ed640de7a7815b2
2016-05-04 00:13:24 UTC sending: getblocks (965 bytes)
askfor block a0b3d94de8551da371ec 1462320979000000
2016-05-04 00:13:25 UTC received: inv (109 bytes)
got inventory: block 0000000000000006d2a4 have
2016-05-04 00:13:25 UTC sending: getblocks (965 bytes)
got inventory: block 49c0bc8e98c44ed8a683 have
got inventory: block c0d0dd5663df1c13e8f8 have
UPnP Port Mapping successful.
2016-05-04 00:14:18 UTC received: inv (37 bytes)
got inventory: block b9de82d14c4c745eaaad new
askfor block b9de82d14c4c745eaaad 0
sending getdata: block b9de82d14c4c745eaaad
2016-05-04 00:14:18 UTC sending: getdata (37 bytes)
2016-05-04 00:14:19 UTC received: block (10070 bytes)
received block b9de82d14c4c745eaaad
CheckStakeKernelHash() : using modifier 0xd62bc78f8c90aceb at height=231462 timestamp=2016-04-12 18:18:47 UTC for block from height=226533 timestamp=2016-03-15 07:18:50 UTC
CheckStakeKernelHash() : check protocol=0.5 modifier=0xd62bc78f8c90aceb nTimeBlockFrom=1458026330 nTxPrevOffset=639 nTimeTxPrev=1458026144 nPrevout=1 nTimeTx=1462320864 hashProof=1dac8380284e341854689e77d8d66f6b17af355e670f1a06740d247c240d548d
ERROR: CheckProofOfStake() : INFO: check kernel failed on coinstake 9bca28e3b64c5f08ef8dca30a4e6ad5cb4c31626b860729d7be69361bfccb332, hashProof=1dac8380284e341854689e77d8d66f6b17af355e670f1a06740d247c240d548d
WARNING: ProcessBlock(): check proof-of-stake failed for block b9de82d14c4c745eaaad648742a51a0c96a585183e00fbb72b8d485d22eca758
ERROR: Error reading proxy response
trying connection 5.135.125.177:9901 lastseen=-1.1hrs
proxy connecting 5.135.125.177:9901
proxy connected 5.135.125.177:9901
connected 5.135.125.177:9901
2016-05-04 00:15:30 UTC sending: version (131 bytes)
trying connection 45.55.149.34:9901 lastseen=-2.3hrs
proxy connecting 45.55.149.34:9901
2016-05-04 00:15:31 UTC received: version (131 bytes)
Added time data, samples 7, offset +9 (+0 minutes)
+0 +7 +8 +9 +9 +14 +15 | nTimeOffset = +9 (+0 minutes)
[/tt]
I think the problem is that many updated nodes were accidentally forked and the owners may not realize it. I had several nodes that were updated to v0.5.2 well before the deadline that were still forked because they were apparently connected to a majority of Peerunity nodes.
Thus, simply connecting to random nodes that are running v0.5.2 or above doesn’t absolutely guarantee you won’t end up on a fork. I had to re-download the blockchain several times for one of my nodes. (Luckily, I save snapshots.)
This problem just illustrates the value of having a voting mechanism to trigger a protocol change (…although Bitcoin is demonstrating the problems with that approach as well.)
We just need to advertise strongly that everyone should check their node, even if they upgraded to the latest version before April 25.
[member=5782]mhps[/member]
Put these nodes in your ppcoin.conf and try again:
addnode=24.155.192.146
addnode=31.178.239.144
addnode=51.9.56.81
addnode=62.163.212.157
addnode=68.105.170.159
addnode=74.208.68.83
addnode=75.128.211.140
addnode=76.74.177.224
addnode=78.8.188.249
addnode=93.80.182.24
addnode=96.243.149.37
addnode=98.115.147.74
addnode=104.236.180.129
addnode=107.170.43.92
addnode=107.170.209.76
addnode=113.17.90.227
addnode=128.199.159.68
addnode=142.4.218.174
addnode=146.185.137.249
addnode=149.210.215.250
addnode=158.69.225.143
addnode=176.9.16.102
addnode=176.31.122.170
addnode=178.62.105.210
addnode=178.248.97.26
addnode=192.95.56.199
addnode=198.15.127.242
addnode=198.245.63.205
…and if that does not work try this instead:
connect=24.155.192.146
connect=31.178.239.144
connect=51.9.56.81
connect=62.163.212.157
connect=68.105.170.159
connect=74.208.68.83
connect=75.128.211.140
connect=76.74.177.224
connect=78.8.188.249
connect=93.80.182.24
connect=96.243.149.37
connect=98.115.147.74
connect=104.236.180.129
connect=107.170.43.92
connect=107.170.209.76
connect=113.17.90.227
connect=128.199.159.68
connect=142.4.218.174
connect=146.185.137.249
connect=149.210.215.250
connect=158.69.225.143
connect=176.9.16.102
connect=176.31.122.170
connect=178.62.105.210
connect=178.248.97.26
connect=192.95.56.199
connect=198.15.127.242
connect=198.245.63.205
Yes, the problem is that we had a fork, due to a bug in Peerunity 0.2.0, at the worst time possible. Since this fork happened at the same time as the network was planned to fork to a new protocol. This resulted in three different consensus clients operating on the network. Miners and minters moved fast to the correct fork, but had poor connectivity to other nodes on the same fork. This resulted in isolated pockets minting different chains because they never received the blocks they were supposed to build on. When these pockets suddenly got connected we saw reorgs happening. Old nodes obstruct transfer of new blocks between new nodes. The network seem pretty stable now, but make sure you are well connected to the correct chain before you start minting with large stakes. It is also very important that people update to Peercoin 0.5.2 or 0.5.3 and Peerunity 0.2.1. If you have an older node than this you should shut it down or upgrade.
My genuine recommendation is that you run the official ppcoin client until this blows over.
Everyone playing with peerunity in the meantime is just going to exasperate syncing problems until we get back on the right fork.
Sunny King is still checkpointing the official chain, and the official client is still syncing.
If you can export your keys from Peerunity and re-import them into the official peercoin client, I recommend you do that in the interim.
https://github.com/ppcoin/ppcoin/releases
I imagine this is why Sunny hasn’t been dealing with this issue. He’s not in charge of peerunity.
Peerunity is normally a compatible wallet and client, but it’s not the official wallet.
It’s these checkpoints that guarantee you are on the right fork.
P.S. I know peerunity supporters are going to be bothered by my recommendation “Hey PPCMan! As long as they upgrade to PeerUnity 0.2.1 they’re fine”…
I know… I know… but sometimes during tramatic times, there is nothing better than the official client. This whole thing started because of a bug in Peerunity. People may chastize Sunny from not moving too quickly with developmental updates. I’ve learned over the years to respect his way of thinking.
I’m running both Peercoin 0.5.3 and Peerunity 0.2.1. Both are in sync.
Yes, this is good advice, but as I said above, even if you are running ppcoin you may still end up syncing with the fork. There are updated clients out there that are promoting the forked chain probably without realizing it.
EVERYONE needs to check their client and make sure they are on the checkpointed chain.
Yes, this is very important.
How can we verify the checkpoint via RPC command?
getcheckpoint{
“synccheckpoint” : “0000000000000001f7e8a5374e1af7982eec340c4ed4cfde091237217dfb766f”,
“height” : 234915,
“timestamp” : “2016-05-04 02:07:22 UTC”
}
getblockhash 2349150000000000000001f7e8a5374e1af7982eec340c4ed4cfde091237217dfb766f
Use the height you get from getcheckpoint in the getblockhash XXXXXX you type next. If the hashes match you are good.
Yes, this is good advice, but as I said above, even if you are running ppcoin you may still end up syncing with the fork. There are updated clients out there that are promoting the forked chain probably without realizing it.[/quote]
Yes, you can sync with the fork with the official peercoin client, but not for long.
Understand it this way. Each block officially has 520 block confirmations. Since peercoin blocks are 10 minutes apart, that is 520 blocks every 10 minutes = 3.6 days.
So, practically speaking, it could take up to a week for your official peercoin client to realize it’s on the wrong chain. Especially since, the wrong chain is very long.
My recommendation is to run the official peercoin client, let it run, and do nothing with it for a full week. It will find the right chain, and the fact that other sync’d clients have proper “authenticated checkpoints”, and it will resync itself automatically. You don’t need to do anything, other then let time work in your favor.
We could call this the PeerUnity attack. It’s not an official attack, but if you convince enough people to install an alternate wallet, and sync enough nodes, you run the risk, that should there be a bug in the alternate wallet, it can cause a massive fork with checkpointing disabled.
Everyone kept freaking out about how centralized Peercoin was because of checkpointing. Checkpointing was the key to this success this entire time. Now you are feeling the pain when checkpointing was optional for a period of time.
I never once suggested that checkpointing be removed. I was happy to have it. It wasn’t even a mandatory checkpoint either. Should Sunny King get hit by a bus, and there were no more signed checkpoints, then the network would continue on without them.
This problem occurred when the network was diverse with non-official peercoin nodes and with optional checkpoints. But no one expected a non-official PeerUnity alternate wallet client bug. So now you understand the situation we have.
This is a learning experience.
The peercoin chain is still safe, and Sunny is still checkpointing. However it’s probably going to take an entire week or two before we’re back to normal.
So the next guy that pipes up and has concerns about checkpointing, excuse my french “they should shut up and leave well enough alone”. It was never a liability. If Sunny was less than genuine, he would have shown his true colors over the last 4 years, and he hasn’t.
Q&A:
Q: Is there anything functionally wrong with Proof of stake?
A: no
Q: Is there anything wrong with compatible clients like Peerunity
A: Yes, only if they have a bug, during a hard fork, and enough people are running a compatible non-official client
Q: Does this mean the peercoin chain is no longer legitimate?
A: No, it will continue to be legitimate. We have checkpointing that shows which chain is the correct fork. The only issue is time for your client (official peercoin client or peerunity 0.2.1) to realize it.
Q: During this temporary outage, should I be transacting peercoin?
A: I suggest no… not until you’re on the right chain. Your wallet balance continues to be safe before the fork. If you transact after the fork, without syncing properly with checkpoints, you run a risk of the transactions being reversed or not accepted.
Q: I’m a pool operator / exchange / faucet / block explorer, I feel affected by this, what suggestions do you have?
A: You should only be running the official peercoin wallet when running any of these types of services, now, and in the future. Do not use Peerunity for that…
Q: How can we avoid this situation in the future?
A: It’s actually quite simple. Don’t let checkpointing disappear until we have a wider adoption. Checkpointing handles all these types of problems in the event people build rogue clients compatible with the peercoin chain and get wider adoption. Rogue is a bad word, but I used it in this case to make the point very clear. Peerunity’s bug caused this, and it’s not the official client.
Q: So what are you saying, we shouldn’t have things like Peerunity?
A: No, we can. Believe me, the peerunity developers have been shocked by what has happened, and I have full faith they will be extra careful in the future.
Q: Final question. Should I get out of peercoin? Is this going to be an ongoing problem?
A: That’s your decision. I’m solid on Peercoin knowing what I know, and how strong this community and developers have been. One small hiccup in the road is to be expected. I’m “long” on peercoin and I would recommend the same to my friends and family too.
Q: Do you have some final words?
A: Thanks for asking (no one asked, but I like the question). Yes… Sunny King is a mirrored image of Satoshi Nakimoto. He’s exhibited the same traits as the creator of Bitcoin. With that being said, I have full faith in his ability to take peercoin where it needs to go, and I have full trust in his work. Even if Sunny died tomorrow, his code, design, and ppc blockchain would live forever. So my final word would be: “Thank you Sunny, and have fun.”
P.S. if you appreciate this post, please show me some karma, I’ve been stuck at +54 too long. 
The fork was found 7 days ago. The offcial ppcoind on my Raspberry Pi never found the right fork. My ppcoin-qt (now with [member=626]sandakersmann[/member]'s connect= nodes. 20 connections to 0.5.x ) is now trying hard to re-org but unable to do it (see below). It’s not that they stumbled on the wrong fork that concerns me. It’s that they can’t recover.
[tt]
version message: version 60006, blocks=234924
2016-05-04 03:13:20 UTC received: verack (0 bytes)
2016-05-04 03:13:20 UTC received: alert (192 bytes)
accepted alert 4, AppliesToMe()=0
2016-05-04 03:13:20 UTC received: alert (197 bytes)
accepted alert 5, AppliesToMe()=0
2016-05-04 03:13:20 UTC received: checkpoint (109 bytes)
Postponing 132 reconnects
REORGANIZE
REORGANIZE: Disconnect 113 blocks; ac866f8336f7689c3ec7…210ee772174ee75abab1
REORGANIZE: Connect 175 blocks; ac866f8336f7689c3ec7…a71007deb1970d7d66ec
coin age nValueIn=68990513 nTimeDiff=17205015 bnCentSecond=118698281102
coin age bnCoinDay=13738
ERROR: ConnectInputs() : 9c125157e9 VerifySignature failed
ERROR: Reorganize() : ConnectBlock e8bd8a656a00966eb873 failed
InvalidChainFound: invalid block=000000000000000a9f33 height=234919 trust=8249162095894128
InvalidChainFound: current best=210ee772174ee75abab1 height=234725 trust=8245903717150241
ERROR: SetBestChain() : Reorganize failed
ERROR: ProcessSyncCheckpoint: SetBestChain failed for sync checkpoint 000000000000000a9f330662b7c00113e279d08103b5d59c43d2a2afb5d09755
trying connection 113.17.90.227:9901 lastseen=-378425.5hrs
connection timeout
socket recv error 10053
[/tt]
You’re missing two key things:
Today is May 3rd. Sunny only re-enabled checkpoints yesterday, May 2nd. It takes a while for the forked network to see the checkpoints, accept them, and re-transmit them.
Each block on the chain isn’t confirmed for 3.6 days (520 block confirmations)
Everything you are witnessing is early yet. Leave the pi alone, do nothing. Within the next 7-14 days it will find the right chain on its own.
To quote your paste:
[quote=“mhps, post:59, topic:3875”]REORGANIZE
REORGANIZE: Disconnect 113 blocks; ac866f8336f7689c3ec7…210ee772174ee75abab1
REORGANIZE: Connect 175 blocks; ac866f8336f7689c3ec7…a71007deb1970d7d66ec[/quote]
113 blocks and 175 blocks is less than 520 blocks, isn’t it?
In one of my jobs, I did tech support. I use to get complaints from people who said “it takes forever”. They would complain that something use to happen in 1 second, and now it takes 10 seconds. “I’d say… so 10 seconds means to you, its forever??”
Similarily, this is a week to 2 week long issue. Sunny is already watching the chain. If he can speed up a fix, he will.
By the way, i feel the need to quote myself when Peercoin went down to 28 cents and back to 32 cents… I knew it then, and I know it now again:
[quote=“ppcman, post:80, topic:3178”]I was getting excited when we hit 28 cents a Peercoin, I started looking for things around the house to sell. Then we’re back up to 32 cents it’s becoming less attractive for my individual position when that happened.
This is like the second coming of Christ. (sorry to religious folks. I needed an analogy). A second chance to buy in at Peercoin’s all time lows like back in 2012 and 2013. I’m excited as it drops. The last thing I want to do is stop the drop. [/quote]