-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
As you can all see from @traxor's updates, I have been very very busy.
This morning I finished up with getting the wallet daemon (mod - because it's modular, and that's a nice short name). The new full node and wallet are based on btcsuite btcd and btcwallet, with all the necessary changes for it to conform to the existing consensus.
They can be found here:
https://github.com/parallelcointeam/pod and
https://github.com/parallelcointeam/mod I will be making a full release with installation packages for Windows, Mac, Debian/Ubuntu, Redhat/Suse and I have an account at the arch linux AUR and I will make a PKGBUILD for it also, and it will be available through the AUR (I'll make a binary, version pinned build and a rolling master branch build).
The new full node runs two separate RPCs for miners and pools to use, defaults to 11048 for sha256d and 11049 for scrypt. The full node, CLI controller and wallet daemon all autoconfigure for localhost access and integrates the full node and wallet automatically, both `podctl` and `mod` on first run with no configuration will copy the RPC credentials so you can get up and running quick and easy. The wallet daemon listens by default to port 11046
It got quite exciting a few weeks back as somebody with access to a lot of mining power started to put out blocks with different version numbers, which it turns out the old client treats as sha256d blocks. Then they started using 'Big S' signatures, which are part of the hypothetical signature malleability double spend attack - and then sure enough, logs started showing blocks coming in that were rejected because the outputs were already spent. The latest seems to be that they are trying to mine a side chain, but so far it looks like the rest of the miners have enough hash power to keep the head at the front.
Our secret shopper, whoever they are, or maybe they are just a legitimate
would-be-blockchain-robber, has ensured that it will be necessary to upgrade the protocol significantly. These are the changes I have in mind:
- - The new client will automatically set the equivalent of a checkpoint at about 288 (2 days) blocks, so that it will automatically block attempts to create side chains and push them ahead with a 51% attack.
- - The difficulty adjustment needs to work from a longer timespan than 50 minutes. I will set it to 4032 blocks, approximately 2 weeks. This is to address the problem that short term bursts of greatly increased hash power is leading to miners printing 10 blocks within a minute and then nothing for hours, which is entirely unsuitable for a real world transactional currency. Extending the averaging window will mean that the difficulty adjusts more slowly and can't be pushed up artificially by timed bursts.
- - Block versions have been messed up by the secret shopper, but after the prescribed hardfork block height they will again be properly enforced and I will design an extensible protocol similar to the one in bitcoin, that allows us to in the future upgrade the protocol using BIP9 softforks.
- - The peer to peer and RPC protocols will be enhanced with a messsagepack binary format protocol and use the OTR/Diffie Hellman Perfect Forward Secrecy encryption protocol, as it is patently retarded to use OpenSSL/GNUTLS, which is based on a web of trust model - which means you have to faff about with certificate authorities to just get it connected. The mechanism will be extended to enable users to make black or whitelists. Web of trust protocols are not identity-secure, as you sign public keys that afterwards the signed keyholder will advertise therefore your approval of them. There might be some purpose to this but I can't think of it. This encryption protocol will also be added to the peer to peer protocol, because in my opinion, even though it's public information, the propagation pattern should be protected at least a little bit, as locations enable attacks.
- - I am planning an SPV wallet, which will have native compiled GUI interface available. The SPV wallet is the testbed and initial showcase/prototype for the peer to peer network extensions I have planned.
- - The first application of this will be in the implementation of a transaction proxy relaying, like the outbound connection component of the Tor network. The nodes will all have a unique identifying EC keypair (ed25519, natch) which will be constructing a wrapper around its transaction broadcast with three layers designating the 3 peers that will relay the message. Each node will only know where it came from and where it's going but not whether it is the first, second or last hop before the destination node.
- - From there on, there will be built wrappers and sockets and interfacing libraries that can be used by other applications to connect to the network and use it to find specific subprotocol peers to enable other types of distributed applications, both centralised/federated type applications (eg, diaspora, paxos/raft/sporedb and other federated WoT database protocols) and trust-computed (for example like the Steem reputation system) and trustless (yes, potentially allowing multiple cryptocurrencies to interface directly through the network) peer to peer protocols. In other words, I am aiming to make the parallelcoin network the wires to connect a whole ecosystem of applications.
When I have completed the releases, with all the installers made for all of the above mentioned platforms (and if anyone has specific requests) - and already you can see on the newest release that @trax0r posted, there is literally binaries for almost every platform in existence, I will make a new ANN thread for discussion and feedback.
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQThc/kXLToA5xCfIuOCA/USO9KcBAUCW/nWowAKCRCCA/USO9Kc
BJdXAQD/+BxK5stddGlA1InaDDrF6GI74Dfqz62E2Qu5E7mqCgEApeF9r1SRvS4c
rveVObyPNZ5DJNMIkMVlpsRT0rZIhA0=
=EmXt
-----END PGP SIGNATURE-----
