Did you even read the thread/OP? Thats completely irrelevant.

---

This applys for the 'receiving' address of your nano s.
This is to ensure the private key which is necessary to spend funds from this address has been created by your nano s.
That step prevents malware from manipulating your screen (to mislead you into sending coins to that 'faked' address).




You have to verify your address (when receiving coins 'to your nano s') to make sure it has been properly created by your device.
When sending coins you will have to verify the transaction details on your nano s.
If you always carefully check whether the details on monitor / nano s screen match, you are good to go.

Theoretically there isn't a 'mix of both'.

Cold wallet: Wallet which holds private keys which have been generated on an device, never connected to the internet.
Hot wallet: Wallet which holds private keys on a device which is (or was) connected to the internet.




You should be in control of your private keys with every wallet you use.
Regardless whether its a cold or hot wallet.




No. Some web-wallet provider might controlling their users private keys.
But hot wallets in general (e.g. mobile/desktop/etc..) do NOT share the private keys with any server, etc..

The answer to this question (which by the way is: YES) is completely independent from the type of segwit addresses..
It is always possible to transfer btc's from a non-segwit wallet to a segwit wallet.




This statement is illogical and contentual wrong.
SegWit was implemented as a soft fork. If somehow it wouldn't be possible to send/receive to/from 'old legacy' addresses, this would not be called backwards compatible.
Backwards compatibility is a requirement for a soft fork.

Additionally, not every address starting with a '3..' is a nested segwit address (P2WPKH/P2SH).
Simple multi-signature addresses also do start with a '3..'.

There is no 'official' wallet. Each wallet is a 3rd party wallet.
The real 'official' wallet would theoretically be the last version satoshi uploaded.

The developer of core are not the 'official' developer of bitcoin. Bitcoin is an open source protocol.

• It takes long to initially sync the blockchain
• It needs a lot of HD space (if pruning: the problem of rescan/reindex as HCP mentioned)
• After a few weeks without usage: syncing again

There are quite some reasons why people (especially newcomers to btc who don't directly want to contribute to the network) could choose
a better option than core as main wallet.

I think thats a pretty clear line.
If its accessable by everyone (without any limitations) = public
If only a specific circle of people has access / if access is granted in dependence from properties = private

I guess you could call it 'page' under given circumstances, yes.




Thats not how it works.
Blocks are 'created' when a miner finds a valid hash (linking to the previous block).
A miner can inlcude as much unconfirmed transactions as he wishes into a block (block size (non-witness part) has to be < 1 MB).
In addition to the unconfirmed transactions from the mempool a miner (usually) includes the coinbase transaction (block reward, currently 12.5 btc).




A new block is 'completed' each time a miner has calculated a block.
When a new block is published all miner start working on a new block (with a link to the previous block).
Basically its a probabilitygame. The difficulty of the network adjusts to have a block generation time of about 10 minutes (on average).

MAC might be a bit more secured against ever-day malware (95%+ of all malware is written for windows).
But the overall security regarding a targeted attack is just minimal better (not really noteworthy).

A dual-boot system with different partitions (different drives would be even better) for your OS's seems to be slightly better.
Use one system (e.g. windows) for every-day stuff and one OS (e.g. linux / mac) for crypto-stuff only.

Segwit transaction don't behave different than non-segwit transactions.
They are structured differently (witness/non-witness) and have a lower size (better: weight). Therefore the overall paid fee is lower while the fee rate (sat/B) stays the same.

Never heared from such an idea 

I think this depends on how the ransomware is coded. It might be the case that the ransomware is going to encrypt the whole HD (not just all files, but all sectors of the hard drive).
In this case this wouldn't work, unfortunately.

Additionally it also depends on whether the deleted files already got overwritten.
Assuming HDD (because recovery is extremely difficulty on SSD's):
If you move your file into the trashcan and empty it, the file is not really 'deleted'. The space (where the file was) is being released.
Depending on how much space your HD has and how much you are writing onto your HD, the timeframe in which the file is still available varys heavily.
For example: If you 'fill' your harddrive completely, your file is no longer available on your HD, for sure.




At least that could work in such a case
But i'd still recommend a 'standard' backup (e.g. move to USB's) instead of deleting a copy in the hope of being able to recover it someday

Actually an attacker woulnd not need to know an address from this wallet.
An attacker could easily just derive the priv-/pub- keypairs from each valid seed (using the most common derivation paths), and then check (e.g. via API) for unspent outputs.
Knowing an address of the wallet does increase the speed of this attack. But its definetely not necessary to perform such an 'attack'.

It is still testing phase. If you want you can already open a LN channel and get used to it.
It is recommended to use LN on the testnet (funds may get lost, etc.. ) and not on the main net until all bugs are found and sorted out.

Current stats:
Mainnet: 993 Nodes - 1869 Channels (https://lnmainnet.gaben.win/)
Testnet: 1885 Nodes - 4822 Channels (https://explorer.acinq.co/#/)


bcash fellower are trying to FUD the hell out of BTC. You should not listen to them.
Those guys still believe increasing the blocksize to 8Mb was a 'scaling solution' 

On-chain scaling (like increasing blocksize) is and will forever be one of the worst attempts to solve the problem.
Don't get caught by scam/pump 'n dump coins like bcash.




I don't think core developer are directly involved into LN (correct me if i'm wrong).
Additionally i don't think you will be able to 'access' the LN from the core client.
The LN is a second-layer protocol which works 'on top of bitcoin'. There will be new wallets to be able to operate on the LN (e.g. zap: https://zap.jackmallers.com/).

No update of core is needed for LN to go 'live'. It doesn't change anything regarding BTC tech. Its just operating one layer above BTC.

Ransomware is coded to encrypt the whole HD (somtimes: except from a few directories to still show desktop, ransom notice, etc.. ).
Usually there are no unencrypted files anywhere on the hard drive left.

Since recuva is a software to restore deleted[1] files, this unfortunately can't work out.


[1] deleted in terms of removed from the trash bin, but not yet overwritten on the HD.

I would never suggest doing this.
You can't be 100% sure whether:
1) the implementation of the encryption is flawless
2) their server don't get compromised

What you are doing when backing up via online services is: You trust a 3rd party.
Cryptos are made to be functional in a trustless system. Don't rely on someone to keep your backup.




There already has been a vulnerability which allowed people with physical access to the trezor to get the seed out of the device (without pin).
Hardware wallets are safe, yes. But not 100% secured. Nothing is 100% secured.




In all of these scenarios a second (paper) backup in a different place would be the solution.
No need to upload your encrypted private key into a cloud.




With physical access (and known pin) to your own trezor you could simply just create a new seed and send all of your coins over to your new (non-compromised) trezor seed.
If a (paper) seed backup gets stolen, simply create a new one and send your coins over (since you have physical access). No need to backup your seed in your trezor itself.
If you can access your trezor, you can access your coins. So whats the explicit reason to store the seed inside trezors password manager?




This actually (storing the seed of cryptos not supported by trezor inside trezors password manager) does make sense.



I would never suggest to store private keys (or any other sensitive information) online.
Every encryption can theoretically be attacked. Quite a lot keys already got compromised because of bad implementations (e.g. bad pseudo random number generator).
You can never be 100% sure this won't happen with the encryption algo you are going to use.
My advice would be to keep all of your private keys offline.

This is due to Endianness (https://en.wikipedia.org/wiki/Endianness).

When communicating via a network, you don't know how your counterparty is 'reading' the values.
Most significant bit at the most left or most right position?

Big-endian (most significant byte has the lowest address [left-to-right reading]) is also referred to network byte order.
Depending on the system you are using your pc might use big- or low- endian format. But when communicating via network, always big endian is used (IPv4/6, TCP/UDP).

Thats the reason for the mysterious reverse order.

After just cloning the source code you won't be able to run it. You need to compile it first (source code -> object code) to be able to run it as a program.

Make sure you have all dependencies installed:

To compile:

The Lightning network IS an implementation of hashed timelock contracts (https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts).
The preview release of RC 1.0 already happened 3 months ago (6.12.2017).

Zap - a wallet for LN - already is in beta: https://zap.jackmallers.com/
The LN already can be used/tested on the test- and main net. Its running on the mainnet for quite some time now.

How (and why) should an online service (like localbitcoins) 'censor' a transaction just because it didnt get broadcastet by OP's node, but someone else's node?
I don't see a single reason why someone would 'block' transactions just because 'a 3rd party' broadcastet it.
Im not even sure if thats completely transparent (who exactly broadcastet this TX first; IP maybe? )?

Im pretty sure it should work to import more than 30 private keys at once.
What are you trying to accomplish? Do you want all of your addresses being visible in the address tab?
Or do you just want to check the balance/sign TX/etc.. ?

You might use the console to check whether your private keys got imported. listunspent() will list all addresses with balance.

Yes.




What you did (when downloading an app in the ledger manager menu) is to download an application onto your nano s.
You can access your bcash wallet via the bitcoin chrome app. You will be asked which chain you want to use (BTC/BCH).

When you have your BTC app (chrome) open, you can click on 'Settings' -> 'Blockchains' and choose BCH.
Then you will have to open the bcash app on your nano s to be able to actually send BCH.

Thats a pretty safe option. But note those two things:
1) USB sticks can break (UV-light, temperature changes, etc. can harm the device)
2) Your PC has to be clean when inserting the USB-stick. Malware could easily grab the seed as soon as you plug it in.

With the correct handling its an ok option to store a backup on an USB stick. But you have to be careful.