Quote from: almightyruler on January 03, 2014, 05:25:32 PM

Quote from: cobrabyte on January 03, 2014, 05:02:06 PM

Block explorer : http://sbc.blockexplorer.io/chain/Stablecoin

also, you can use this block explorer as a node:

addnode=66.228.60.13

I have it set as primary in all of my stablecoin.conf files and it's guaranteed to be on latest stablecoind.

I'm reasonably confident that the 1.5 client I've freshly compiled will be able to handle whatever happens after block 317k, even with conflicting information from peers.

It's the others running old, older, and really really old clients (Satoshi:0.6.3 ?) that I'm concerned about. I was only mining for about 30 minutes on the wrong chain; some of these people would have been mining for nothing, probably blissfully unaware, since the fork a couple of weeks ago.

Clients need additional code to automatically detect forks and notify the operator.

This could actually be a feature that sits alongside the mixing service. @artos can sign (with his private key) a checkpoint-like message that's included in newer releases to inform older clients about upcoming, planned forks. Every client that supports the mixing service will have the public key that can be used to determine whether a received checkpoint message is authentic. So, when clients advertise their version information, they might include (encrypted) information about a known, upcoming fork.

Dunno, just an idea.

EDIT: Actually, I read through the Bitcoin protocol docs and found the 'alert' message (see: https://en.bitcoin.it/wiki/Protocol_specification#alert) that can be propagated across the network by @artos. It appears he needs to change the Bitcoin ECDSA pubkey that's set in the source code to his own ECDSA pubkey to make use of it. It's intended to be used to send messages about upcoming forks and it appears it will even communicate these messages to the GUI client's status bar. Cool feature that shows some insight from the BTC developers.