Nope. It's not a protocol implementation. I think you can probably integrate it on top of Bitcoin Core though.

It works by having multiple parties spending their UTXOs in the same transaction to multiple output. It requires a coordinator (someone to collate/distribute all the parties and their information) for this to work. An example transaction would be as follows. A spending to B and C spending to D, E spending to F.

TXID:...
UTXO(0.1BTC, A)                           Output (B 0.1BTC)
                                  ->
UTXO(0.11BTC, C)                         Output (D 0.1BTC).

UTXO (0.22BTC, E)                        Output (F 0.1BTC)

                                                   Change(C, 0.01BTC)
                                                  
                                                   Change (E, 0.12BTC)

Since B, D and F are the intended destination, there is no way to tell that A is spending to B and so on so forth.

Yes. There is no way for you to consolidate all the small UTXOs unless you spend all of them in a single transaction. If you want to have some form of privacy, you can possibly try to segregate them from each other and only spending the UTXOs that are associated with the same addresses/ a small group of addresses only.
That is inevitable. Consolidation transactions are best done when the fees are relatively low so that it can be confirmed sooner. If the fees are consistently high, then it'd be better for you to spend specific UTXOs for the transactions that you're making.

The only way for you to preserve your privacy, when spendlinking is inevitable is to consolidate and send them to a mixer or use CoinJoin. If not, then it'd be better for you to use each of the inputs individually.

They do. It's a P2SH address and it should be the one address type that should be compatible given that it was introduced so long ago. Bech32 is also supported on Binance.

Electrum has an option for 2 Factor Authentication with TrustedCoin and that is a paid service, the client itself is free. It's open sourced and the community contributes to the codes[1], Electrum doesn't make money. The 2FA fees are paid to TrustedCoin only for their 2FA codes.

[1] https://github.com/spesmilo/electrum

I don't consider Blockcypher's explorer that accurate: https://live.blockcypher.com/btc/tx/6520a0cdd0e36df5d377852736c35b2a4ae31934f4473650207a06c36cf8d98c/.

Transaction is obviously non-final but it got broadcasted to their explorer anyways. Seems like they're omitting some checks before pushing the TX. Blockexplorers are not a reliable source of information when it comes to propagation, even if you can see it on a blockexplorer, it doesn't mean that it has a good propagation.

Do you even know what you're talking about?

Miners do not know the wallets that are being used. Miners sees the transaction the same way as every single user sees the transaction. There is no indication with regards to which wallets is being used or accounted for. If miners can see which or how many wallets are being used, your privacy would be gone in the first place.

5 is the uncompressed WIF keys and 6P is the prefix for BIP38 encryption.

The string starting with 1 is the address, the third being the private key. I have no idea what is the second unfortunately. The closest I can think of is an ECDSA private key which is only 64 characters. Nonetheless, you will be fine as long as you've swept the funds.

I'm assuming the 52 characters line is the string that starts with K and that the 33 characters starts with 1?

Go to your Electrum wallet, at the top left, go to Wallet>Private Keys> Sweep and key in your private key in this manner.

Afterwards, you should get a dialog that shows the transaction information, at the bottom left, there should be a slider that lets you adjust your fees. Depending on how long you want to wait, the current somewhat optimal is about 30satoshis/byte. Click Finalize, check again and then Sign and Broadcast.

I'm not sure how Bitbargain works. Did they give you a bunch of phrases, a private key starting with 5, K or L or 6P?

Please do not share your private key with anyone on the forum, no matter how trusted they are. You should at most reveal only the first 2 characters of the key for others to determine what type of key it is.

For receiving addresses, you'll always see at least 10 un-used change address while for receiving address, you'll always see at least 20.

If for some reason, you decide to skip the addresses' order and not use the address in the chronological order, then there'll also be at least X unused addresses after that specific address, depending on whether it's change or receiving.

Other than the difference in the timezone, Blockchain.com is displaying the actual time that it was relayed. Both Blockchair and Blockstream are displaying the time whereby the block that includes the transaction was mined. I think both of the other blockexplorers changes the timestamp to the block's timestamp after it gets mined and discards the relayed time.

Receiving addresses are always generated for you when you go to the Receive tab and generate a new request. The addresses are only picked from those which are labelled as such.

When you're sending a transaction, the change would be the Total amount in the inputs - Total amount in the outputs - Total fees. The remainder (change) are sent to the one of the addresses which are labelled as change. The main difference between how Electrum handles both kinds of address lies with the generation; the addresses in the change address are generated from a slightly different derivation path from the receiving address but this is transparent to the user.

Check the tokens docs, https://github.com/3rdIteration/btcrecover/blob/master/docs/tokenlist_file.md.

You'd be able to customize the settings to use space by %s and use positional anchors for the positions as welll.

I'd understand if it's Blockchain.com, they're very terrible at what they do.

But in the case of Coinb.in, would that still be the case? Assuming 9 (bech32) inputs and 1 output, it would be about ~651 vbytes and ~1616 bytes in actual size. However, the error appears to show that the min fee is only slightly above 2x of the required amount which would pretty much be within the margin of error for 1sat/vbyte to 2sat/vbytes.

I just tried it with Coinb.in and it shows 110 < 186 but in raw size, that should be 218.5 vbytes so that would still be below 1 sat/vbyte (if it's calculating by bytes, then it should show 110 < 218.5). I'm a bit confused with their logic to calculate the min fee. I'm thinking that they're actually calculating by the vbytes but the current mempool cutoff for those nodes are slightly above 1sat/vbyte.

Go to Menu at the top left. Click on Network Monitor and you should see Peers and Blocks. Afterwards, click on the Blocks. Check what is the time of the last block. It should be above 668843.

Let me get this right: Are you sending from the Android wallet or to the Android wallet? If it's from the Android wallet, check the address on Binance and if it matches the one stated in the transaction.

The current mempool size appears to be 100MB, might be slightly bigger. The actual ram usage should be about 300MB after accounting for the overheads. It is also the default max mempool size for most, most nodes would have the same mempool size. It may not seem like much but if you had to factor in the resource constraints of such servers, it would be pretty reasonable. Blockcypher might be able to broadcast your transaction but it won't mean that it would have a very good propagation; nodes are evicting the lower fees transactions and probably wouldn't accept anymore transactions under 2sat/byte.

The time that you see on Electrum or other wallets are displayed as per the time relayed to them. This means that each block explorers will have a fairly significant disparity in the time received. When you're talking about a TPS of 7 tx/s, you'd be looking at a few hundred transactions to filter out. You can use blockchair to filter the unconfirmed transactions though: https://blockchair.com/bitcoin/mempool/transactions?s=time(asc)#, https://blockchair.com/bitcoin/transactions?s=time(asc)#.

I would take the above results with a grain of salt, some blockexplorers doesn't even see the transactions until it's mined. It could have been made days ago but the blockexplorer can only show the timings based on the time that the block was mined.

It's a cold storage. The version available on Tails is sufficient to generate the seeds and it shouldn't go online at all. Using outdated Electrum is fine, there isn't any concurrent vulnerabilities present in the installed binaries on the latest Tails that would impact the security.

Paper wallets are actually not very great to use. You'd have to use a printer without any wireless connectivity, ensures that it isn't stored in the ram to ensure that the paper wallets remains as an offline cold storage. If you don't print it out, then you can't store it without the persistent storage either. If you were to use an OS for that already, might as well just use the Electrum that is provided on it. Needless to say, Bitaddress doesn't even have Segwit on it and it's arguable that using an offline Electrum *could* be potentially safer than trying to download a script online to use it in a browser.

How do you know? Did you ask him?

Evidence suggests that the extra nonce appears to be in line with the behavior of the Bitcoin-qt 0.1.0 at that time. You cannot find a distinct pattern with the ECDSA public keys present, the patterns with the private key will not hold to it's corresponding public keys and there isn't any evidence to suggest that there is.
Ok. Believe what you will. Do update us when you figure out the private keys.