You don't need to panic.
Your wallet (blockchain.info) is a HD (hierarchical deterministic) wallet, meaning that it can generate all the private keys (and hence addresses) of your wallet with the 12 (or so) word phrase you were given and told to store securely.
You don't need to know the private key itself as your wallet already takes care of that and you can always generate all your addresses with the seed phrase by importing it into another wallet.
However, if, for whatsoever reason, you wish to see the private key of the address in WIF, then follow the instructions posted by TryNinja above.

Greenaddress IS a multisig address.
2 of 2 means that BOTH signatures are needed to move funds in the wallet -- one of the user, and the other by green address.

TXID is like any other transaction, with the address starting with 3 indicating a p2sh address
This is a sample TX ID of a transaction made by a GreenAddress wallet:
.https://blockchain.info/tx/e801ef473ed1f5e0fb541d5c8cfccc2418e3af2f5d398dc303ec60949fa2d15c

Look at this post for a list of wallets in different platforms that have Segwit support:
https://medium.com/@rogermagno/segwit-wallets-02-07-2018-76d836bccbc9
Although the post is a bit outdated seeing that the most recent version of Bitcoin (0.16.0) has segwit support out of the box.

For better compatibility it's better to use a segwit address that starts with "3" as the segwit addresses that start with "bc1", even though they have the least fees, are not generally adopted so they are not compatible with most wallets.

You can simply use an address translator to "translate" the segwit address to a format that Bittrex will understand.
Just paste your Segwit address that starts with M here: https://litecoin-project.github.io/p2sh-convert/ and you'll be given an address that starts with 3.
They're both valid as they correspond to the same private / public key.

Tweak the instructions present here to fit your purposes:
https://medium.com/@CarpeCrypto/apis-google-sheets-picking-out-microcaps-made-easy-c1e847371af2
It's for Google Sheets, not Microsoft Excel.

I seriously doubt it is that much.
The Us Government has been known to consistently sell the bottom of their seized Bitcoin.

The only reason why you can be "high on" a glaring Ponzi scheme is if you're one of the administrators or participants.
Which are you?

Yet another crypto Ponzi scheme like Bitconnect,Davor, Regal coin and so on.
You know how they all ended up...

If the addresses are the correct ones then the seed is correct.
I'm not familiar with Token Pay but as long as the seed is correct you can try restoring it on another device.

Use a local password manager.

If the password is for a BIP 38 private key, then use a passphrase.
Those are easier to store, and you can write them down , or split them into parts using Shamir's Secret Sharing Scheme.

What do you mean by "they are not showing up"?
Do the addresses show up in your wallet when you type in the seed, but not the coins?
Or does the seed generate a different set of addresses entirely?
If it generates a different set of addresses then you're typing in the wrong seed.
BIP 39 seeds are in small letters throughout with just one space between them. Make sure the syntax is correct and you're not misspelling any word.

According to this guide here when the wallet is initialised there are 2 addresses shown that are not derived from the seed. Did you send coins to any of those addresses?

RGBkey has answered your first 2 questions so I'll answer the last one:
Bitcoin uses a fairly long difficulty retarget time to prevent miners gaming the system like what happened in Bcash last year
As you noted, if you have short difficulty retarget time, a miner with large hashpower could mine blocks quickly to reap rewards, wait for difficulty to adjust, then repeat.
With Bitcoin the miner would have to sustain the attack for about 2 weeks which is prohibitively expensive.

Also block generation time is like a lottery where it's possible to find many blocks within the expected block generation time or not find any within that time, so if this happens you do not even need a miner with large hashpower to destabilise your network, just bad luck.

However there are altcoins that have a difficulty retatget time with a different algorithm, such as Kimoto Gravity

This transaction has been confirmed and has had more than 8,000 confrontations.
It was included in block 502842 which was mined on the 6th of January, so it has been confirmed for more than a month now.

The point of the block chain is so that you wouldn't have to believe the words of another person -- you can always verify by yourself.
The block chain shows the transaction has been confirmed, and you shouldn't believe anyone that says otherwise, no matter who that person is.
It is possible their node is not fully synced with the block chain which is why they haven't seen the transaction on their end, but this is doubtful as they have already spent the outputs in this transaction on the 24th of this month.

0-conf transactions aren't safe -- no matter what bcash shills would say.
It's even written in the white paper.
A transaction that hasn't been included in a block(i.e a transaction with 0 confirmations) can be spent elsewhere.
So if you are a merchant selling goods and you accept a transaction with 0 confirmation, after releasing the goods and the transaction still hasn't confirmed, the sender / buyer can spend the inputs for that transaction to another of his addresses and get to keep both the Bitcoins and the goods.
This breaks no consensus rules as the transaction hasn't been included in any blocks yet.

However, depending on your security model, you could choose to either reject 0 confs and wait to they have at least 1 confirmation, or accept the risk that you could be cheated before the transaction gets confirmed.

There's no publicly available email address, but you can open a support ticket here:
https://support.blockchain.com/hc/en-us/requests/new
However that support seems to be for matters pertaining to their wallet service so I doubt you'll get a reply.

For the mobile app you'll have to scan the QR code gotten from the desktop App to sign the transaction.

What's the setup of the multisig?
2-of 2?

Only Electrum so far supports Bech32 addresses so no other one will work.


It depends on how your wallet is set up.
If it's 2 of 2 or 2 of 3, and one copayer is  your desktop wallet, and the other is your Electrum for Android,  then you can generate a QR code from your desktop wallet and scan the QR code from the mobile Electrum wallet.

Yes, Core 0.15.1 is compatible with Segwit addresses.
In the next release, 0.16, segwit addresses will be the default.

Blockchain.info is a BIP39-supprted HD wallet so I doubt it will give you a WIF key because a private key only corresponds to a particular address and a different address is used anytime you make or receive a payment.
It should give you a list of 12 or so words (called the seed/mnemonic phrase) that a wallet can interpret to generate all your used addresses.
A WIF private key is an alphanumeric string that starts with 5, K or L, eg
If your private key doesn't look like this then it's not a WIF private key.
Also, while Bitcoin Core is a HD wallet, you can't import BIP 39 seeds directly; you can only import WIF private keys so you either have to use another wallet where you can import the seed directly (eg Electrum), or get the private key of your address{es} that contain bitcoin from the seed using Ian Coleman's BIP39 tool.

If you have a "missing python35.dll" error then either your download was corrupt or your antivirus deleted the python35.dll file when the installer extracted it.
If you have an antivirus active disable it temporarily and retry.

Also, check the source where you downloaded Electrum, it should be electrum.org, and compare the signature of the downloaded file with the one on the website.

I reckon the same seed will work for ETH via BIP 44.
OP could also import the seed into a compatible Ethereum wallet and restore access to his ETH -- ditto for BCash.