Really short quick one -

I just finally got all three main components working

- Full node so far mostly reliably syncs and responds to RPC

- CLI RPC client works, connects to node and wallet, prints help correctly

- Wallet now connects to and syncs with full node.

There's lots of little niggles amongst it, as you would expect, but maybe within a day or so I will have it stable and the combined node/wallet "shell" mode working, the bottleneck that has been holding up the show for the last two months.

Well, it is my first time building a working blockchain application

I think I am now past the top of the hill, work-wise and patience-for-dragging-on-wise. I'm pushing myself from now extra double hard to make the milestones and catch as many of the clangers as I bump into.

Something that makes me think of as relates to the new suite going live - I will build a small webserver and run it behind a tor hidden service (for your privacy) that will receive crash reports. I'll have to add a setting for it, enable/disable automatic submission of reports. The reports will be just tracebacks sufficiently long to point me in the direction of the probable causes, and yes, you will have to manually set it to on and the GUI will also have an alert when pending reports can be checked and manually sent in if the user has opted in to help with this. No, I won't want it nagging you, just one 'dismiss' popup on first run and that's all, at least during the first three months it goes live.

while I am in pause mode, I elaborated a bit more on the hashing algorithm.

https://git.parallelcoin.io/dev/9/src/branch/master/doc/complexpow.md



Sorry, image isn't previewing because of my newbie status. But you will be able to see even with this provisional process graph that asics would have problems getting around the need for sending hashes between processing stages as a bottleneck, as well as squelching a lot of the possible optimisations from convenient ordering. I think we may yet put an Equihash Pow into the graph in a parallel stage connected to some of the other graphs in a messy-as-possible way.

It only really needs to see the chain through until we have the next generation asynchronous protocol working, I think it should happily succeed at giving us a year's grace.  Very probably minor changes, like pushing results from stages into even more intermediate stages likely would further reduce any working asic's efficiency, even if its processing path is fully programmable, and maybe by then Fluffybunny and other asic warriors will probably have got even better hashes to add to the process.

I can increase the complexity quite a lot without increasing the total time per hash. You can conceive easily of further complexity by adding logic gates that send hashes to different processing stages depending on part of their value... But I think it doesn't have to go much further than this to the point the proof is of bus interconnect and nothing else bigger constrains it. This is the most complicated and expensive part of any motherboard, the PCI express bus and the cpu-memory interconnect. No matter what way you slice it, the algorithm will congest this channel and leave a lot less options for improvement open.

maybe a whitepaper

I started writing this as a roadmap but ended up blathering on and decided that it's almost right for the white paper.

The TL;DR version is basically that we want to implement a proof of causality logic-clock based ledger, and build a framework to replicate the ledgers of other coins, including retaining their proof of work for issuance rate control purposes. Coins that do this get the sub-second transaction finalisation of the new protocol while keeping their issuance control and development of their ledger protocol is entirely independent.

We want to build a new network that can support a swarm of affiliated cryptocurrency projects, small, low cap, poor resources, with enthusiastic people.

By implementing several coin ledgers on one base protocol, it becomes simple to enable cross-coin atomic swaps in-band. The network can track the exchange rates and produce price charts as well.

Ok, just a brief report...

I now have got the full node launching though the ctrl-c interrupt handler isn't properly wired in. I should have all of the servers running again on the new 9 repository by tomorrow. The critical thing is getting the combined 'shell' launcher done, this is a combined full node and wallet node connected to the full node.

Once that launcher is done we start on the wallet GUI and I can finish the hard fork transition code and finalise the proof of work (I think I may make it a little more complex still, put some more simple hashes with more complex directed graph of processing steps disrupting linearisation.

I know it's not going to be perfect, proof of work is just the first working open-entry protocol architecture, it's pre-model-t grade, but even if for some reason every asic maker were to suddenly want to make miners for duo, we still have 6 months grace for their production cycle and either it will be structurally rearranged at that point or we might have got to a new protocol (i doubt it).

The essence of what we are doing next is fairly simple - think of Lightning and its cross-chain transactions, and then flip that upside down. Put it inside an environment a bit like Bitshares, with multiple, user issued tokens, except instead of just making a proxy for trading the token, we emulate it down to the last detail, as well as creating a PoW regulated coinbase issuance consensus, but this PoW does not regulate processing of blocks, only the timing of new coinbases being issued.

In other words, what we want to do next is build a proof of causality/logic clock based consensus, which can run a token without a PoW to stop double spends, and then create a PoW anyway, but it is only for issuance control and not for double spend security. Then with two or more such different ledgers implemented on the same platform, it is far simpler to add a cross chain settlement protocol and the network keeps track of the ratios of values between different subtokens.

Or in other words, we intend to build a base protocol that can be used to implement the ledger format and proof of work of other coins, and, of course, selecting other small cap and nearly-abandoned coins, offering to add their token in a coinswap process and our chain becomes the master, but their protocol plugin remains under the control of the user community and devs.

It's an excellent deal: share exposure to exchanges for the other coin, and a new market for parallelcoin.

The idea is that it allows the usually hodge-podge of dev skillsets available on each project could merge related work together, effectively growing a development team by mergers.

Forget bitcoin maximalism. How about network integration. Lightning is a nice idea but settling cross-chain transactions actually doesn't really solve any problems relating to latency. It does allow faster clearance when both sides of an exchange are using lightning but those on main net still have the congestion and scalability problem.

With both chains on an underlying common platform, the platform can be the site of implementing these token exchanges, it can track the price and history and you don't even need an exchange if all your trading partners are using tokens on the same protocol.

Ok! well, just don't keep asking for news if you don't mind.

The gender field is hilarious!

Gender:

Agende
Androgyne
Androgynes
Androgynous
Bigender
Cis
Cis Female
Cis Male
Cis Man
Cis Woman
Cisgender
Cisgender Female
Cisgender Male
Cisgender Man
Cisgender Woman
Female to Male
FTM
Gender Fluid
Gender Nonconforming
Gender Questioning
Gender Variant
Genderqueer
Intersex
Male to Female
MTF
Neither
Neutrois
Non-binary
Other
Pangender
Trans
Trans Female
Trans Male
Trans Man
Trans Person
Trans*Female
Trans*Male
Trans*Man
Trans*Person
Trans*Woman
Transexual
Transexual Female
Transexual Male
Transexual Man
Transexual Person
Transexual Woman
Transgender Female
Transgender Person
Transmasculine
Two-spirit
Asexual
Female to male trans man
Female to male transgender man
Female to male transsexual man
F2M
Gender neutral
Hermaphrodite
Intersex man
Intersex person
Intersex woman
Male to female trans woman
Male to female transgender woman
Male to female transsexual woman
M2F
Polygender
T* man
T* woman
Two* person
Two-spirit person
Attack helicopter

I think I will go with the last one too

A bounty program sounds like a good idea, we just need to find someone with the funds to pay them.

Incidentally, wtf is up with the KYC notification in this forum? Because I sure as hell ain't filling out the form it links to, it looks like fraud to me.

where is the telegram anyway?

If you are the one showing up saying 'any news' every so often and never replying when addressed and asking questions that often are right there a few lines beforehand, how about you try to actually have a conversation with us instead of wasting our time.

If you are an investor you want the developers not being nagged by silly questions that are already answered, right? That would be working against your interests as well.

I am the most communicative member of the team and this is upside-down because I am also the lead developer.

If you want to hang out at the discord, don't act like a robot and we won't treat you like one. Lurk or chat, don't type the very same message and never reply when addressed as you have been doing since I joined the team.

You may well be holding stake in DUO tokens but I have been staking quite a bit of sweat equity in this, and I gain no benefit from being disturbed by questions that seem to always be rhetorical.

Also, I don't use telegram. Your account, I presume @candyx has been unbanned from the discord, and I would appreciate it if you would respond when you post a question and someone addresses you. Otherwise the ban will be reinstated.

It has been a while since I last posted an update, and I have a bunch of things done now.

Firstly, the name of the main server is now just `9`. I haven't plugged on all the bits as I am systematically rebuilding from the old version  to avoid adding any fluff (and I know there is lots), but the repo is here: https://git.parallelcoin.io/dev/9 - it doesn't do anything yet, but once the configuration parts are completed all the old launch stuff is added back and all its necessary dependencies.

The configuration system stuff was driving me crazy between setting and saving, on the CLI and into the apps configurations turned out to be poorly supported with all of the CLI argument processing libraries I found.

After three rounds trying with libraries and one false start with a home-grown solution, I am back at crafting my own solution. The new CLI arguments processing only handles actual commands (node, wallet, etc) and triggers for stuff like replay and dropping indexes and so forth.

The actual configuration will now be handled by a simple codec and a file format that is easy to edit and has all the comments and defaults for the user. I am writing the code that saves the configuration now and once I finish the code that reads it back into the appropriate structure, I will build a typeahead search interactive CLI that lets you find settings and change their values interactively. The GUI will also have its own interface to this.

It will be possible later to extend the CLI interface to allow directly setting things for a one-shot run, and the configuration interactive CLI will let you also choose to launch commands after you change settings. I will aim to make it as smooth and intuitive as possible, but not wasting any more of my time on code that will rarely execute in real life.

I should be finished the configuration and launchers in a few days and hopefully @marcetin has warmed up his golang web app skills after a much too long break from it and we will be able to get the beta happening in the next couple of weeks.

We have secured a bit more funding for development now, so also expect soon a formal Roadmap and Whitepaper to let you all know what we are doing next.

The next phase of development is very likely to be towards building an application framework with a distributed, trustless epidemic, transaction-oriented protocol that is intended to form the basis of ultimately an entire operating environment, from end user to network infrastructure providers. The aim is to make a scalable framework that can go from realtime MMO first person shooter game level response, to media streaming and consensus accounting of delivery of media to calculate a monetisation system and reputation ranking for curation. But instead of thinking first about the application, rather, to build the pieces that have many ways of being applied.

Of course, where we go next we will make sure we bring as many of the willing passengers along as possible. Feedback and discussion is most welcome (come to the discord and say hello: https://discord.gg/nJKts94)

I'm getting through the issues at a fairly quick pace these last days. I eliminated two race conditions, fixed a bounds check in trace logging and  the consensus is working fully up to date

My current focus now these errors are fixed is analysing its replay performance and plucking some low hanging fruit optimisation targets. I have observed that the replay speed of this codebase leaves something to be desired, or it might just be download sync (not supporting faster protocols now operating with bitcoin), but I want to just now get all the easy improvements done so what remains has a more dubious chance of producing a stunning improvement.

The configuration system is half done, I can run one of the apps now but the configuration is not composing how I intended it to. I will be getting that right shortly and then I will finish putting all of the subcommands into action, controller, wallet, and then seeing if my idea of using the cli app library to spawn wallet and full node in parallel is right...

then finally I'll be at the base point to put the GUI on it.

I still need finish with the hard fork transition handling, though, I think I will do that next today after I see if I can make any improvements to replay time.

Not sure why this didn't happen sooner, but today I made an AppImage universal binary for the parallelcoin daemon legacy version, and yes, the Qt wallet client also, so anyone looking to run a wallet or node on a linux machine has a shortcut option to getting up and running. The links will be updated on the main site soon as also will more changes coming with several things coming to completion soon.

https://github.com/parallelcointeam/parallelcoin/releases

and as a repository at our interim new work in progress repository that will eventually house the whole collection of things:

https://seed1.parallelcoin.io/dev/parallelcoin-binaries

The binaries for other platforms will be added later, they are already available elsewhere.

seed1.parallelcoin.io / seed1.parallelcoin.info seed is back online, apologies for the downtime, it may have slowed initial syncing not being operational for several weeks.

It was necessary to solve the issue of binary distribution of the linux version at least and this was a happy surprise when I got it to work and I think this makes it significantly more accessible. As I am in the process of debugging the consensus now, I also needed these so I have seeds to quickly start up test nodes from.

Update

Progress with fixing errors in consensus is coming along swiftly, should be syncing again soon

We have got an immigration specialist looking into what options we have, something like a payment plan would be doable, and maybe some other way (I don't have much in the way of collateral but maybe something can be arranged). We are again back fully on the case.

There is a project, relatively small in scope and, although the path got a little wide of the original target before we re-acquired the target, being that of a managed crypto nodes hosting service, bitnodes.net, which needed a substantial overhaul of the back-end to get it working. I am helping also with this right this moment, just a few issues involving build environments, but the automation of boot and control of which node gets what image is mostly done.

This one is the self-funding avenue, and maybe we can get the (two years total and overdue) tax bill paid for my serbian legal entity that will allow me to continue my work without further disruption.

Regarding the actual server software, I have completed what is definitely the most complex API/syntax validation unit tests I have ever written, and I am currently drafting the map of the remaining parts to complete this self-validating, automatic CLI/configuration library, that will replace the climax library that it currently has, with a simple declaration syntax and collection of handlers, that will complete the baseline and necessary 'shell', being a dual-server launcher that is needed to implement the GUI wallet as a combined unit of node, wallet and GUI interface.

Every programmer hates tests, but especially in this case, it is necessary to check the definition of the application is fully correct in its syntax and semantics, before using the values it gathers and composits to launch the individual component(s) for a given sub-command (cli controller, full node, wallet, the combined node/wallet 'shell', and GUI, which includes the shell).

I think within the week I will be back at the point where all of the command stuff is working and this time, without any difficult bugs to chase down. @marcetin should at that point be ready to merge this new back-end for bitnodes with the front end he already wrote, and if we can stay on track well, I'll have my tax bill paid, I have to fully complete the hardfork logic, which is about half done, and  then the GUI, and we will finally be into beta. Maybe a month now, until people can really see it as it is intended, and start to have opinions about what we actually did, which up to now isn't really possible.

Crypto winter is now fully biting this project. I have just looked again closely at the tax bill that I am supposed to pay so that I can stay here, it's about 1100 euros.

I see absolutely no sane reason to pay this when a few hundred kilometers in any direction I can be inside EU jurisdiction.

I have no idea what to do about this. Sure, it might have helped if I'd finished sooner, and I'm really not that far, given no big new things become needed, from completion. Right now I am working on replacing the CLI/configuration library, as the code that I have written for this, has turned out to be much too error-prone and really there was no available library that really makes any better - the new library handles loading the configurations to spawn the node and wallet at the same time automatically, and I think I'd be finished on it within a week if everything wasn't so nerve-frazzling with this visa situation.

I have friends in Bulgaria who have offered to help out, and I guess probably their project wouldn't suffer from a little help right now, though the current issues on their agenda don't specifically need my coding skills - well, I don't know. There is also people who might be able to help in Bosnia too.

To be honest, I feel a little unworthy considering the poor rate of progress I was making during the first 3 months here. It's my first time taking on such a project, and the conditions in the market also dictate that really, the level of changes I have put together are nearly almost not quite the necessary baseline. From here, unto maybe the next 5 years, probably a lot of projects are going to be working under much tighter regimes than anyone would have expected during the end of 2017.

But hey, it can't be all bad. I'm pretty sure that you could fit the number of people in the world who can write go-crypto apps into an average loungeroom/dining area, uncomfortably.

Any suggestions most welcome. Something has to be done in the immediate short term.

Oh, by the way, speaking of exchanges, I am good friends with the operators of the easydex.net bitshares based DEX. I am unsure of the protocol level fees (in bitshares) for issuing tokens, but they have a standing offer to add DUO to their bridge, which includes all the majors plus also EUR and USD. Though right at this very moment it seems the bitshares network is undergoing some kind of maintenance as many nodes have been offline recently.

However, I expect this situation to improve fairly soon, and so yes, the idea was in my mind that when the release is done I would do the work of consulting/administering to attach DUO to their bridge just prior to the release, to help improve the potential liquidity of DUO as well as expose another section of the crypto community to the project.

I am not in a position to do much before I finish the beta, but afterwards, I will be available to help with any other listings people can organise. With the crypto market in a dip and 'apparent' bottom, there isn't great urgency to do this work right now nor funds for it, but I think once the thaw has started we should be poised to rapidly take advantage of the improvement.

Like many projects, of course we have our eyes on implementing new technologies that mesh with our platform. My main wish is that after release I can devote a smaller part of my time to maintenance and a greater part of my time to developing the asynchronous protocol that I intend to develop. No blockchain yet has async protocol, and this is the biggest obstacle to low latency high throughput processing. Money is the smallest use case for distributed databases, as important as it is, it is other services that monetise the tokens, payment is not a killer app nor is blockchain really suited, in its current shape, to be much more than this (PoS type protocols cut latency down but trade it for trust, which is an unacceptable compromise, but it does mean more effective non-monetary database applications. Async protocol would make every type of database a valid implementation target for a trustless, decentralised network.

I am once again fully back on the case. The last few weeks I have been quite off track but I have got myself back on task now, after finally getting a few minor detail type things more in the way I want them in my dev environment.

My current task is finishing the implementation of the hard fork, and getting the servers back into the state they were when I was last working on it, in the first week of february, I of course looked again at the difficulty adjustment.

Out of curiosity, I had a bit of a look to see what the probabilistic distribution of block times was, and as I had suspected, it is exponential. Many bitcoiners parrot this nonsense that the odds of finding a block do not change from one minute to the next, but this is not true. They are confusing poisson distribution with the distribution of a poisson point process (PoW is the latter).

This led me to look at how I can bias the adjustment to reduce the incidence of blocks shorter than 1 second, and I think I have got something on it now that works. Basically, now the adjustment has a full soft limiter that works on the basis of an exponential reduction of influence at the margins.

Previously it was flat against a complex averaging, now, it has a final stage where whatever the adjustment is, the wider it is, the less it changes the difficulty. It works like a hard limit, except it's soft and squishy. The important thing is that it doesn't too aggressively adjust even in the case of a very divergent clump of blocks.

The most likely time a block is going to be extremely short or extremely long is at the time after a really big change in difficulty and its inverse correlate, hashpower. This new adjustment step helps ensure that the difficulty adjustment doesn't jump too quickly and directly, itself, cause long or short blocks. I was more concerned about short blocks, in this case. Ideally if we say 9 second block time, then we want under 30% of the blocks to come under 4 seconds. This should be the case now.

I am starting on adding the full hard fork block target time adjustment. Previously it was just selected by using testnet, it runs the 9 second blocks. I have to write the code that changes the mainnet block time after the hard fork activation.

Once that's done and tested we will be focusing intensively on the GUI, the final stage before pre-release beta testing.

Good to hear that probably DUO hodlers will not be affected considering how much DUO landed in Cryptopia shortly before the hack. Who knows how long they will take to resolve it, I mean we are only just now seeing the last loose ends tied up for the MtGox crash never mind BitFinex and the Nicehash heist... people really need to get their priorities straight on security.

I have been making steady progress since my last report. I have now got the bits together for the actual block time change of the hard fork, and a testnet hard fork test with a much earlier height of activation. I just need to start debugging it and soon there will be not much left to do except finish the GUI.

The hash algorithms are going to remain in flux until an undetermined time before the hardfork kicks in. The provisional height for activation is 199,999 but this may be extended forward, though I think it's possible it will be able to stay on this schedule. The hash functions have been revised and changed.

Watching the spectacle that is the Grin release, I can safely say that I doubt that Parallelcoin will have as much nonsense associated with issuance rate, distribution, or secret development of faster miners. It is astounding to me that almost 4 years after Cuckoo Cycle was invented it has taken this long for any chain to adopt it. The lie-sensing nonsense of the cabal of GPU programmers and ASIC makers has marred their release quite badly.

The algorithms being used for post-hardfork parallelcoin should not be easily accelerated. There is about 11 or so hash functions used in the entire thing, but one of them is Cryptonote 7, version two, which is slated for the next Monero hardfork, this is inherently a cache-locality-focused PoW, and runs fastest the more cache the processor has. AMD makes GPU and CPUs with the biggest caches hence why monero mining has been able to hold a small contingent of CPU miners despite how big its market cap.

The other unusual hash function is the Argon2i hash. Argon2i is based on Blake2b (or it might be blake2s) and in a similar vein as Scrypt is actually a 'key derivation function' designed to slow down bruteforce attacks on human-memorable passwords used for symmetric encryption. Just as Cryptonote has an optimal hardware platform in the Ryzen processor family, Argon2i requires a lot more memory and so its strategy here is to exceed onboard cache and bottleneck on the system memory bus. Again here is a place that the AMD will be better, as its memory bus latency and throughput are significantly higher than Intel and other processors.

The anti-asic strategy I am applying is not absolute, but rather the structure of the chain of hash functions intentionally intersperses functions with a significantly different optimal hardware. CN7v2 runs best in a Ryzen. Argon2i runs best the faster the memory bus (so yes it would be a candidate for GPU acceleration and possible specialised processor with large onboard cache). So we have two separate processors that are connected at best by PCI-express, meaning their throughput is bottlenecked by PCI-e bandwidth.

I anticipate the best strategy for ASIC makers working to increase power efficiency for the new Parallelcoin PoW scheme will basically be in a compact AM4 motherboard with a ryzen CPU, blake2 accelerator with large cache for Argon, sitting on the PCI-e bus, and a multi-algorithm simple hash processing accelerator for the rest of the hash functions.

Or, in other words, not much distance from commodity hardware, and therefore also commensurately lower efficiency increase potential. Plus an increased complexity burden by requiring at least 3 separate processors (CPU, GPU, ASIC) coordinate their processing to stream the data through in a pipeline.

I am not bothered by ASICs so much as I consider it to be a fact that most blockchain developers do not spend enough time working on improving the low level protocol or the complexity of the PoW algorithms, and too much time cleaning the boots of symbols like bitcoin and satoshi. Blockchain tech people and distributed systems researchers are two sets that have far too small an overlap. CS researchers have a wealth of knowledge that could benefit blockchain tech but sadly it seems to take a long time before anyone actually adopts the technology. This is normal, I guess, but the tech must become fit to purpose and the purpose itself still is unclear to some extent.

I will update again when we reach the next milestone of a functional, usable multiplatform GUI wallet interface.

PS:

I just finished writing a command to automate setting up a localhost testnet cluster. Manually setting all the configurations is tedious and error prone so this will help accelerate testing a lot. Likewise the GUI needs a live network to test on so this makes that easier for @marcetin who is the main UI dev (years of web dev experience)

As @marcetin started working on the wallet GUI, it became clear I needed to clean up the logging system and launch system to enable one binary to run both node and wallet alongside the GUI.

It took some searching to find the simplest and cleanest solution, but I had already written a logging framework, so step by step I will be stripping out the old  logger, putting in the new one, and everythting launches from one nice CLI with sub-commands, automatic self-configuration with sane defaults and later some more utilities and extensions of the components.

The new logging system is based on goroutines and channels, so it minimises context switching, reducing the processing cost of logging.

The all-in-one structure will mean that distribution can be done just with the binary, at least to start with, and with a installation script for each platform, it can be installed where it will be immediately accessible. Possibly I will make installer packages that download and place the binary and create any necessary user interface shortcuts rather than contend with many different installers. It's usually just a few files in the user's profile and the GUI would be accessible by the system launch menu.

It may take a little while for me to finish the launcher/log changes, it's pretty heavy going repetitive stuff, lots of details to account for.

I have been thinking about installations and defaults... I think it will default to running the GUI with no options given, and prompt you to install it, it is easy to put different parts in for different operating systems.

I'm not sure about how to copy the binary in windows but maybe it has some 'do this when I finish' special thing that lets you do exactly that, move the binary to its proper place. Or for windows maybe just download it again and put the file in the right place. On mac the dmg package is the whole thing. Writing installers for multi-platform is a pita, but hey if we can have a GUI launch on all platforms we can be the installer. Also later on such things as running at startup and whatnot, which also has implications with the server versions as well.

Also note that it will have integrated explorer webserver and extended GUI that links to the wallet GUI. No more wondering where to check if a transaction has made it into a block!

Just a little, super-short update:

I have been finding it very confusing trying to work with the KCP protocol for this task, so I have been learning how to program UDP sockets directly.

I now have an important part of it worked out, the 'reliability' part in the Reliable UDP - a fully working Reed Solomon error correction codec. It uses a 9/3 scheme, where you send out 9 separate packets, but only 3 have to make it to the other side intact to deliver the message.

This is very pessimistic about corrupted packets and dropped packets, but it should ensure that almost never a retransmit is required. Being that transmission can be up to 400ms on a good day from the opposite ends of the internet, the extra 5-10 ms for encoding and the triple amount of data sent hardly seems like a bad price to pay.

This reliable UDP protocol is for pushing work to miners in the case of a mining farm, since at 9 second average blocks, every millisecond counts towards finding a solution before someone else. But later on, I will be adding this messaging protocol also to the chatter between nodes, and nodes that have this facility will be able to identify each other and switch to this ultra-low latency gossip protocol transport. This means that Parallelcoin will be one of the fastest proof of work blockchains on the internet.

Oh! In other news, our lead web developer marcetin is back on the case, I had to update some of the wallet server parts that I hadn't updated to match the new hard fork block version scheme, but he has the required wallet server to go with the full node. Oddly, it turned out that the parts that needed fixing were not directly in the 'mod' wallet code at all, but rather, in the 'sac', which is an SPV node based on the SPV wallet being developed by the Lightning people. I didn't recall there being a dependency between them, but there you go.

The SPV wallet is something that I will be also working on after the release of Plan 9 hardfork. It's not so important now since the chain is only about 150Mb in size but it will grow faster after the hard fork and having a light version will be essential especially for mobile devices.

I'm going a bit slow at the moment for various reasons, but just wanted to  make an update as I have achieved something...

I am building a miner worker controller that will interface with the kopach miner to coordinate work for anyone running more than one machine (If you only mine with one machine you can use the built-in CPU miner).

It took a few tries to figure out what way would be the best to work it, and forking the cpu miner code was the simplest, as basically what it does is exactly what I need, except for to instead of run miners directly inside the main server process, it runs a server that clients send a subscription request, and then the worker tries to solve it, when a new block is received from the network, it pushes out new work to the clients, who then should abort current jobs and start on the new.

The miner controller service will be using KCP, a reliable UDP protocol with forward error correction and optional encryption. For miners running on a lan, the small extra reduction of latency not using encryption is an option, and if the workers are connected over insecure paths, it can use AES encryption to prevent mischief, and the pre-shared key used for the encryption also acts to prevent snooping and spoofing from a potential attacker.

Of course I don't advise using the internet as the transport for mining, as it will cost equal to several solution attempts in latency. This is because with 9 second average block time there is only a small window of opportunity to solve a block and submit it and have it accepted before other miners, and this acts as security against both pool miners and botnets, both of which will have a significant disadvantage in potentially up to 2 seconds delay in assigning new work after their main node receives a new block forcing a work restart.

CPU mining has different issues to deal with compared to other types of mining, and long block times allows a lot more scope for attackers to corrupt the data on the network. Plus, it is generally considered in the web application business that after 10 seconds delay, users feel that the remote system is unresponsive, and thus first confirmations typically being under 10 seconds means that real applications, and not just monetary ledgers can be used from this same base.

It's back online again... I am gently pushing to get the infrastructure in focus now, since I am closing in on a release complete with the hardfork and new mining protocols, it will be 100% reliable soon but for the moment it is working and you'll be pleased with how fast it is compared to most explorers. @marcetin is really good at writing super fast web apps using Go and AMP...

https://explorer.parallelcoin.info/