I’m always trying to learn more about the underlying protocols that power cryptocurrency networks, and obviously, Peercoin has a special place in my heart. Over the past couple of days, I’ve had a couple of questions mulling around in my head that I didn’t know where to find the answer for, so, rather than continue to wonder, I’ll ask here.
One of the concerns tossed about by the proof-of-stake skeptics is the idea that a rational minter will attempt to concurrently mint multiple chains, in the hopes that they will solve more than one, and that by some chance, the alternate chains that they solve will become the longest. Rather than seeking an answer for if that’s a true statement or not, I’m really curious to learn the answer to:
[ol][li]Is possible to use a block explorer-like tool to view all of the concurrently competing chains that exist on the Peercoin network?[/b][/li]
[li]If so, does one already exist?[/li]
[li]Can it also be used to identify valid, orphaned transactions (ala Blockchain.info)?[/li][/ol]
Another argument used is that Peercoin only provides the illusion of decentralization, because Sunny King’s private keys are used to validate and sign every single proof-of-stake block solved. An interesting topic, for sure, but at this point, I’m more interested in a set of related questions:
[ol][li]Has checkpointing, as it is currently implemented, ever been used to roll back the block chain after an attack?[/li]
[li]Is there any way to tell that the block chain has been reset or restructured due to an attack, perceived or real?[/li]
[li]If the answer to the question above is “yes,” does a tool exist that keeps track of when this occurs?[/li]
[li]And, finally, Blockchain.info has a “double spends” page – is there anything that would make it difficult to stand up a similar page that reviewed the Peercoin block chain?[/li][/ol]
I don’t know if there is an explorer. If a node secretly grows it’s own chain a public explorer won’t see it. But if you want to see possible ones, maybe there is a debug option for ppcoin-qt to prints out the blocks on those not-best-chains.
Let me know the following reasoning holds water:
Suppose some miners do this concurrent minting. Everyone of them accepts new chains (let’s call them alt-chains) which should have been orphaned. If I am to do this alone I can add a block every several months to one of the alt-chains. When I find a block, no one but myself will confirm it. It’s pointless.
So there have to be many miners doing this otherwise their alt-chins can’t grow and survive.
We know that orphan happens so often that quickly everyone of these miners has hundreds/thousands alt-chains to mint on concurrently. Every chain is like a new wallet for block processing work. Soon the miner will exhaust CPU cycles and/or RAM. Some chains will have to be dropped (orphaned). It becomes proof of work. Except it may take a while before a chain get orphaned (dropped).
If an alt-chain is orphaned some transactions done in this chain are erased even after they are confirmed by 6 blocks. A miner doesn’t want to drop alt-chains where he has found a block, because the block is what all this fuss is about. But other may not agree because other people has their own pet branches. They have their own set of chains to drop, which may include yours.
I have’t come to a conclusion as what happens next for an uncoordinate group of such miners. Will everyone ends up on a chain that is kept by so few miners that it eventually dies?
But for a coordinated group, conscious choices of whcih alt-chains have to be made among them. The mininer with the greatest minting power probably will win. Following his alt-chain and your blocks are likely to survive. Consensus is reached again, they will have a centralized POW coin, centered on the most powerful minter. A rational miner won’t do this.
More discussion about the above scenario is here. Both DeathAndTaxes and jonald_fyookball suggest that the concurrent minters will not mint on a tree of all forks, but only on the longest chain. Then an attacker has to own a lot of coins to hope his lone competing chain can out grow the main chain as there will be no peer helping him.
Bump. I’m still interesting learning how the community can develop tools to identify situations when the items above are occurring, or when they have occurred.
I’m with you on that. It is actually kind of surprising how little we know. The only stat I know of is the orphaned block count. I don’t know how it works, but I suspect that it dumps latest blocks across a number of nodes into a database and does compares. When blocks are dropped or changed in one or more nodes you would notice.
Technically you could build a client using the same protocol as the wallet to query all nodes and write their output back into a normal database. I bet SK and some others have such a setup, it would be great if the output of it could be shared as an API or by publishing the statistics.
I’m looking forward to the PNHM (Peercoin Network Health Monitor)
After doing some research it looks like you need to be connected to all the active nodes of the Peercoin network to be able to identify all the orphan/stale blocks.
Sounds a bit complicated for me.
I’ve successfully monitored up to 20 nodes, but I guess it’s far from enough to be meaningful and in fact haven’t found any orphan blocks since a few hours my scripts are running.
Can someone confirm that you need to be connected to the node minting or mining the orphaned block to be able to see it ?
I’m not positive of the answer to your question, mably. My initial inclination is to agree that you need to be directly connected to the node in question or be within a close proximity of it to be able to capture those transactions.
Would it be useful for your monitoring if there were more nodes on the network running your customized client? If so, I’ve got a couple of servers that are geographically dispersed. I’d be happy to run your client on them if they had a way to “phone home” to a central location that would benefit your data analysis.
Maybe running the standard client with -debug will already generate enough info in the debug.log file? For example if I run peerunity with “-debug -printcoinage -printcoinstake” and I see the foot track of the client choosing chains, like
received block 8880115676252972bd0f
CheckStakeKernelHash() : using modifier 0x9f7b702ce39fd64f at height=108325 timestamp=2014-04-24 00:19:53 UTC for block from height=106791 timestamp=2014-04-15 03:01:09 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0x9f7b702ce39fd64f nTimeBlockFrom=1397530869 nTxPrevOffset=160 nTimeTxPrev=1397530869 nPrevout=1 nTimeTx=1404834822 hashProof=000001c9b243ea382f682a1d6c474e988a460c878840ef4ddeefbd2e0c3851ca
ComputeNextStakeModifier: prev modifier=0xeccd0c153bc83ab3 time=2014-07-08 12:11:27 UTC epoch=1404821487
ComputeNextStakeModifier: no new interval keep current modifier: pindexPrev nHeight=121169 nTime=1404834430
coin age nValueIn=220030000 nTimeDiff=7303953 bnCentSecond=160708877859
coin age bnCoinDay=18600
SetBestChain: new best=8880115676252972bd0f height=121170 trust=2693078406880184 moneysupply=21544356.951958
ProcessBlock: ACCEPTED
Then only a schript/bat file is needed to filter out the useful contents and email/upload to a monitoring account to collect orphan statistics.
@Mably PeercoinJ alone isn’t ready for this task imo- easy to manipulate and create panic. @mhps good idea, core client w/ outbound connections limit removed and additional logging (timestamp, full blocks and txs in hex) + post-process is a right way to start