Sorry - you seem to be having some troubles understanding the conversation as I am not making any such claims whatsoever (and if I did you should assume my account has been hacked and that whoever is pretending to be me is in fact a scammer).

I have told you "no system is foolproof" - so that obviously would include my own system.

Hint - "trust no-one" (which kind of does make it impossible to safely secure your BTC when there is no way to do so without trust).

Unless some major change has happened (to either SwapBill or to the thinking of the Bitcoin core devs) my understanding was that the ACCT (based upon TierNolan's approach) is dependent upon nLockTime which is not likely to become standard any time soon due to the fact that it creates a very simple attack vector (i.e. just exhaust the memory pool of every single node by flooding the network with future nLockTime txs).

The point you are not getting is that there is no software that you can be sure won't go wrong unless a) you wrote it from scratch (and have a very thorough understanding of ECDSA), or b) you can fully understand every line of source code that someone else wrote before then compiling it yourself on your offline computer.

As I doubt you are capable of either a) or b) then you are simply going to just have to trust someone (no offense intended as at least 99.9999% of people are not capable of this).

The idea of Bitcoin being really "trustless" is actually not a very accurate idea (it depends upon a non-flawed implementation of ECDSA for a start).

If the software you are running offline has been compromised it doesn't matter whether you use air-gapped comms or not.

Very true - as we have seen recently from the blockchain.info fiasco ECDSA that relies upon *random values* is not such a great idea.

The CIYAM Safe (https://susestudio.com/a/kp8B3G/ciyam-safe) is designed to work with QR codes and cameras to provide 100% air-gapped safety.

Bear in mind this doesn't have the ease of an offline *wallet* or a device like a Trezor but assuming you have disabled all network connectivity in the offline computer it is arguably more secure.

I wouldn't go as far as saying it is "totally safe" though as you would next need to start thinking about things like Faraday cages to protect your offline computer from being spied upon through signal detection as well as any cameras you are unaware of being able to see over your shoulder, etc.

Hmm... well I know this is a joke but I do hope others know that C++ is not just C with some additions (they are almost as different as Java and JavaScript).

Hmm... I used to test potential employees with less than 30 lines of C++ that only one out of one hundred understood perfectly so I guess that you must be an extremely good programmer.

I never read that stability on Windows was a main reason for anything (but I might have missed something).

The tools that I used (admittedly many years back) were the MingW stuff for letting you use a basic GNU subsystem under Windows to compile stuff that had been written for usage with GCC and I found faults in it (then stopped using it because of those faults as it was corrupting my own DB system).

IMO it would be best to use MSVC for Windows as that is the best compiler that there is for Windows (I was never much of a fan of it until Borland proved to be a completely unreliable C++ compiler after their horrible 5.0 release - and they never got much better after that before they basically gave up on C++).

Understand that the Windows version is not built *natively* - being someone who has actually written a DB engine (a core part of my own project) I do recall problems in the past with file seeking bugs occurring under non-native Windows builds (not that I could say if that would even be likely to the issue here but just to point out that non-native Windows builds don't always work perfectly).

This is actually why I had suggested not using Windows (i.e. it is not being built natively for Windows so why do you expect it to work perfectly under Windows when the devs don't even use that OS?).

If you can show the issue to the devs under Linux then you might have a chance of getting some attention to this problem (assuming it is not just a tool issue).

Did you use some special tool to do this (as JavaScript has nothing to do with Java and I am pretty sure trying to change JavaScript into C++ would be no simple task without a very specialised tool so I can't see how changing it into Java would actually be much easier)?

From direct personal experience I can attest that dog meat used to be far more widely consumed in major cities in China years back.

Next time perhaps don't make a sweeping generalisation (as now you are changing your words to focus on the countryside perhaps you could explain how it is that you know so much about the eating preferences of the "nong min" - do you spend a lot of time visiting countryside areas of China?).

Hmm... seems I am having troubles reading tonight (for some reason I was only looking at the RHS column but yes now that I look at the LHS column it is indeed LISTENING on 8333).

So it's a toss up between the firewall still running and the corrupt blockchain I guess.

You can probably check running processes to detect if a firewall is running.

Hard to say why it messed up but presumably the upgrade had something to do with it.

I'm sorry I don't have a better idea - you could try working out which files from the blocks and chainstate directories to delete (before starting bitcoind/-qt) to minimise the resync (but I am not your guy for that sorry).

Of course if you delete files you are going to have to use the -reindex option at startup to repair (but that should be much quicker than downloading the entire blockchain again).

In that case - here is my theory - because your blockchain is screwed bitcoind/-qt is not getting to the point of listening at all (I haven't checked the source code to see if it does check the blockchain before starting the listening port so that is why it is just a theory).

If this theory is correct then you should be able to fix this issue by downloading a torrent of the blockchain (after deleting your current one) and restarting it.

The issues here are not with the Bitcoin protocol but with blockchain.info's poor quality software.

It would probably have been better that ECDSA sigs didn't rely upon *random* values at all (then none of this mess would have happened).

My guess is we probably have the NSA to thank for *encouraging* the use of such random values (being a great attack vector).

Hmm... that doesn't look good in regards to the fork situation (so you do have a problem with your bitcoin blockchain) - but I don't think that should stop your bitcoind/-qt server from listening.

Do you have a bitcoin.conf file?

And if so you need to make sure it doesn't have this:

nolisten=1

In any case you are going to have to fix up your blockchain.

That is admirable - your netstat did not show anything listening on 8333 (it only shows outbound connections).

Is your bitcoind/bitcoin-qt not configured to listen?

Of course - you could just "stop using Windows" and your problem will just go away.

Although you say you have stopped all firewalls, etc. this looks like firewall blocking to me.

Assuming it is not your router then I think that maybe you are running a firewall even though you think you are not (maybe some new sort of "net nanny" behaviour that Windows has that makes it impossible to disable the firewall?).