1.) Reducing the difficulty exponentially makes it easier to find blocks. Ironically that actually increases the probability of forks since with a lowered difficulty it is easier to find blocks.

2.). The high difficulty of the bitcoin blockchain is a result of its massive hashrate.
This actually secures the network by making it hard for an attacker to rewrite the chain.

So if the difficulty is consistently low (compared to what it is now) it means that the hashrate of the network isn't nearly as high which means it'll be easier to attack the blockchain.

3.) There are plans for secondary off chain solutions like the Lightning Network which removes many transactions from the base layer so there are less transaction fees overall.

4.) The distribution of bitcoin supply is not expected to end until 2140, so there's still more than a hundred years to figure something out. A lot will have changed by then.

It's not a "problem" per se.
It's a feature, not a bug.
Like I said earlier, transaction confirmation/finalisation in POW coins is probabilistic, not deterministic.
Each confirmation increases the probability that a block that includes a transaction will not be overwritten by another due to a double spend, 51% attack or blockchain reorganisation.

I reckon it will still be the same on the protocol level.
In this case, the Coinbase transaction will only include the transaction fees.

That's not how mining works.
The difficulty has nothing to do with the block reward but adjusts itself every 2016 blocks to the median hashrate of the network.
Also, not every "try" generates a block, which is why (bitcoin) mining is competitive.
The bitcoin network has a collective hashrate of 24,785,843,885 GigaHashes per second.
1 GH/s =  1 000 000 000 hashes per second
Do the math to see how many trials to create a block goes on in the bitcoin blockchain every second.

Soft fork = backward compatible change to protocol.
Legacy nodes can still (mostly) verify transactions and blocks and do not necessarily need to upgrade immediately.
Used to introduce new features to the code

Hard fork: also used to introduce (of remove ) features to the protocol, but it's not backwards compatible.
Causes a divergence because new rules aren't compatible with the old ones (eg a 2MB block size increase in bitcoin isn't compatible with the current consensus of 1MB block size, so legacy nodes will reject any block greater than 1MB)
If it isn't contentious -- eg, in Monero-- then (almost) all nodes upgrade to the new chain  and the old one dies a chain death.
However, if it is contentious, and not everyone migrates to the new chain then there will be 2 different chains with 2 consensus rules. This is called a chain split.
I assume you're referring to a UTXO fork here where coins (or precisely UTXOs) in the legacy chain are present in the new chain.
Technically all hard forks are UTXO forks as long as it's not just a codebase fork.
Since the 2 chains share the same block height then they'll share the same transaction history and UTXO set.
So, yes, if you make a UTXO fork of a coin, they will be present on the new chain automatically.

It's called a block CHAIN: there can only be ONE valid chain.
The other chain will become orphaned (the chain with less proof of work)
That's why you're told to wait for x confirmations (usually 6),
A "confirmation" means that a miner has built upon the tip of that particular block, and the more confirmations a transaction has, the more secure it is.
After a few confirmations you can be rest assured that there was no double spend.
That's the thing though; you can't know which block will be orphaned unless you're the miner that mined (both) the transaction.
When a block is orphaned, its transactions will be anulled and added back to "the" mempool of unconfirmed transactions, and since there's a conflicting UTXO that has been spent, that transaction will never make it into a block.
So it's equally possible that in the event of a reorg, that your payment to the merchant will be in the valid block, and your double spend attempt will be orphaned.

But theoretically, if your double spend transaction was included in the valid block and the other transaction that paid the retailer was in the orphaned block and the retailer already released the goods, then yes, the retailer lost the bitcoin you were supposed to pay.

Which is why you're required to wait for a certain amount of confirmations before you accept a transaction as valid, depending on your risk exposure -- or aversion.
The higher the risk, the more confirmations you need to wait for.
A merchant selling gift cards or so can even accept 0 confirmations even though it isn't secure because his risk isn't high.
However, someone selling a house worth millions of dollars can choose to wait for 144 blocks (~ 1 day) because the probability of a chain reorg that deep is negligible.
Although there isn't deterministic finality in bitcoin transactions, the probability of a chain reorg or rewrite reduces exponentially as the number of confirmations increase.
The maturation time applies to the block reward; the block reward includes the block subsidy(the newly minted coins) and transaction fees.
The Coinbase transaction includes the transaction fees for all the transactions in the block, plus the block subsidy.
However, if a miner mines an empty block (a block without any other transactions apart from the Coinbase transaction -- for a block to be valid, the Coinbase transaction must always be present), then the Coinbase transaction contains only the block subsidy.
For example in this block you can see that the block had fees of 0.4739BTC and if you check the Coinbase transaction you can see that the output of the transaction is 12.9739BTC which is the block subsidy of 12.5BTC + the total transaction fees of ~0.4739BTC
Compare it to the first block that Satoshi mined that had no other transactions.
You can clearly see that the Coinbase transaction only has an output of 50BTC (which was the block subsidy at that time)

Most ICOs haven't delivered a working product yet.

As much as people hate ethereum, at least it has a working product: the Ethereum blockchain.

Not possible directly in the blockchain.
Smart contract solutions like Salt, Lend, etc require KYC even though they do not require credit score.

Of course you could leverage the power of bitcoin smart contracts (HLTCs, CLTV, and CSV) a la the Lightning Network, to create a multisig collateral but when assets not native to the blockchain are involved, nothing forces the participants to behave so the process is not fully trustless.

Bitcoin can't stop incoming transactions to a specific address.
However you can block transactions from an address; restricting UTXOs from being spent until a certain time passes.

Not worth it in any way.
Either it's a Ponzi scheme, or it's flat out unprofitable.
Stay away.
It's better to just buy the coin.

If you have the backup code, then install Google authenticator app and use it.
If you do not have it then you'll have to contact the exchange (Binance) to prove its your account.

Again, it's a feature, not a bug.
Mycelium warns you that the keys won't be added to your Master-seed backup and implores you to have a separate backup of it.

AFAIK NO mobile wallet will save two different seed phrases; usually if you import bitcoin private keys through a seed phrase it deletes the old wallet to prevent confusion.

Well you needn't be; read-only is just that: read only.
Anyone with the API key wouldn't be able to make any trades or withdrawals with it.

If you're still paranoid then use Cointracking's CSV import feature

Not possible.
The "flippening" will never happen.
Ironically ,ICOs are the undoing of ETH: they expose it to regulations and exert selling pressure on it.

Cointracking.info has CSV import feature and it even tracks your taxes for you


You can create an API key that's read-only.

It's not a bug, but a feature.

It uses BIP 44 to create different "accounts" with the same seed.
If you ever want to restore your other HD Accounts with the same seed then create new accounts when you import your seed into Mycelium.

Or use the following derivation paths:
for the default account
for the first HD account
Just keep incrementing the number depending on the number of accounts you have.

The decimals of a token or coin depends on its usage or supply mostly.
For ERC 20 tokens it's easy to see the reasoning: something like movie tickets can't be divisible and so can't have decimals.

Some coins (eg Electroneum) have 2 decimal places to mimic physical coins in fiat currencies, so the supply of such coins is higher to account for the restricted number of decimals.

Others eg NEO, Siacoin, IOTA (even though it's traded in Miota) are indivisible.

It's actually the other way around: ETC IS the original chain, but ETH wasn't cloned; it was a UTXO fork of ETC.

Another (complicated) way would be to use BIP 65 And create a CLTV transaction.
You can give him the private key to the address that holds the output, and he can't spend it till the specified time has elapsed.
The downside of it is that it's permanent and you can't undo any mistakes or spend the funds later of you wished to.
You could use BIP 112 instead to make a CSV transaction that can be invalidated in the future of you ever change your mind.

If you want to read QR codes, yes.
Scan the QR code from the offline computer with the online one.

Windows version of Electrum doesn't support QR codes, or it'd be easier than using a USB stick all the time.

Testnet is not available for Electrum on mobile AFAIK.