Generally, when the private key is imported into a wallet which has been connected to the Internet, it is not considered airgapped anymore; it is possible for the private key to have been exposed to a third party via the Internet.

Of course, exceptions exist and your wallet would probably still be safe if you employ the use of an offline computer to sign the transaction before transferring it to an online computer to broadcast it. But that would be too much of a hassle and it is generally not recommended to reuse the paper wallet.

It really boils down to how low your electrical fees are. I would recommend you to try using a calculator to calculate how much you could earn and how long it would take for you to ROI. You have to take into account the halving and the difficulty increment. With so many variables in play, it would be hard for it to be worth your time. If you look around, there are some used ASIC miners in the computer hardware section. If you don't mind, you can try to start getting the equipment from there.

I would recommend holding your coins instead of day trading though. Trading is really not for everyone and it is hard to master it.

You'll just be inflating the prices in the short term while doing nothing to help in the long term. Bitcoin needs more adoption and use. If you can't convince the general public to be using it, it wouldn't be beneficial for us to just purchase more Bitcoins for the sake of inflating the demand. It isn't feasible for us to purchase Bitcoin just to increase the price either.

With most wallet configurations, importing an address means that the change would go back to the change address. Spending all the funds in a paper wallet is better for security as the paper wallet would've been exposed to the internet. The more serious repercussion with that is the loss of privacy; it would be fairly easy to tell which is the intended address and which is the change, thereby resulting in a decrease in privacy.

Maybe next time, if I need this again .

---

---

Loan received. Thank you! Locking the thread till repayment.

I'm looking for a 0.1BTC loan for a period of a month (8/11/19). The repayment amount will be 0.11BTC.

Message:
Address:
Signature:

Hardware wallets are mainly designed to be protected mainly against digital attacks (malwares, etc), not physical attacks. They are supposed to be stored securely and safely. Using the location feature requires an internet connection and cold storage are supposed to be isolated from the internet to reduce the attack vectors as much as possible. I don't think using a phone would be suitable as a cold storage, especially given their poor security track record.

No. The node does not keep track of the transactions that has been dropped. They wouldn't know that they've had the transaction before in their mempool.
Technically, no. Nodes would still drop your transaction after some time but if you rebroadcast it periodically, you'll ensure that their mempool would contain your transaction for most of the time.
No. A mempool is unique to every single node; it is possible for your transaction to exist in only some of the nodes on the network and not on the others. Keeping track of the entire network's mempool would be impossible.

The mainstream implementation of the OTP system is mainly with SMS based and time based. Since SMS based systems obviously will require a central party, it is out of the equation.

With time based OTP, the secret is shared with the phone which should be kept safe. It wouldn't work if the malware were to be active during the point at which the OTP is activated. In addition, for the server to validate your OTP, they would require the secret key. This means that every node (and thus everyone) would have access to your secret. It wouldn't make sense and it would make the blockchain even more bulky by storing all the data on every node.

The current implementation of 2FA wallets with multisig is the best compromise between security and feasibility.

For people to validate the validity of the information, they would have to verify the whole block chain from the start of genesis. Else, it wouldn't be very effective for Bitcoin to exist. Centralisation wouldn't be ideal either, it would make attacks on Bitcoin easier and less expensive.

For most, I would think that running an SPV wallet would suffice while people who would want to support the network can run Bitcoin. The size would arguably be less of an issue with technological advancement and the various BIPs (Lightning network, schnorr signature etc).

Your PC does not have your private keys which means that it is not vulnerable in that area. The only place that the hacker could somehow compromise is the Nano S that is connected but since its secure enough such that there's no known vulnerabilities to access the private key inside the device, the hacker can't get to your private key either.

With the confirmation on your Nano S, your transactions are secured since you can tell if the funds are going to the correct address.

TLDR: You are safe. That's what hardware wallets are designed to do.

They can't. AFAIK, the only reason why Ledger Live can see your balance is because the list of addresses is known by the app once you connect your Nano S to it. No one can steal your balance because your private keys aren't stored in Ledger Live; they are only on your Nano S.

Also No. Think of Bitcoin addresses as mailboxes. People can send mails to your mailbox without getting your key but the only way to get your mail is to open it with a key. It works the same for Bitcoin. You don't have to connect your hardware wallet to receive Bitcoin, you only have to do it when you want to spend them.

IMO, the difference between synchronizing across your LAN and the network's nodes would be negligible. In fact, synchronizing over your LAN would yield a worse result. You can only synchronize with one peer at any given point of time if you were to use your other LAN node as opposed to getting the blocks from several peers simultaneously.

Without considering the download speed, your synchronization could still be slow with the main bottleneck being the parsing and verification of the blocks.  Following Loyce's advice would expedite the whole process and make it less complicated.

Returned early due to unforeseen circumstances. TXID: b9a43078c719a8da82b3bb6e043e730157c1e668d94e7174fbbc8e0f88bc2fbe.

Thanks for the loan!

You can't import wallet.dat into Electrum. You would have to extract all the private keys and import them into the client. Its a tedious process and many things could go wrong.

Rescanning your wallet.dat shouldn't take that much time. The only thing that is time-consuming should be your initial block chain synchronisation and rescanning is basically just a matter of searching through the UTXO database which shouldn't take long.

That isn't secure either. Even running a full client isn't enough. Bitcoin Core can be compromised in that scenario too. The problem here isn't with the validation of the transaction. I don't agree with that either. The difference between SPV clients and Web wallets is huge; SPV clients still do give you full control over your private keys. IMO, SPV clients gives its user the balance between convenience and security.

If you want to protect against the scenario that you've described, you have to review and build the client from scratch. This isn't something everyone can do.

You can use the createrawtransction command and specify which UTXO to be used in the transaction. You can use listunspent to find out the specific UTXOs to use. Thereafter, you can just sign the transaction normally.

Since labels don't have a balance associated with them, you can still group addresses together by labels but it would be troublesome to calculate the total balance.
Do you mean settxfee? That command interprets 6 as 6BTC/KB and it doesn't have floating fee. You can use estimatesmartfee to get the floating fee and use another command to set the fee.

---

While creating the raw transaction, you can just select UTXOs with its total value that equates to the total output value. You can use fundrawtransaction to have the client add UTXOs for the fees.

Does your donation system explicitly require the tracking of the various donations?

If not, you can just set up a static address for donors to donate and it would be much simpler. Else, you can consider trying out Electrum. While Electrum is not a full node, you do get the liberty of having full control of your funds and they do have a RPC interface for you to use and track the donations. You wouldn't have to synchronise the block chain at all and there is no need for an excessive amount of storage space either.

Request For a No Collateral Loan
Required BTC Amount: 0.12BTC
Estimated Loan Duration: 1 month
BTC Address: 34HqRCrQV8ZysB4Pt9z11CYgr3wGE43LfU

---

Signed Message: This is ranochigo and today is 28/7/2019. I am requesting a loan of 0.12BTC from DarkStar.
Address:1Yzig3e8vx79XyYMjJShk4yBPp1YcvPbQ
Signature: H7evJYMOKUhmlaf6ijjyLBFj3AewYZHqI+oOFfJ7QKG1S59fyNDIm8DTUY551griIGflWNj9HsDrn8C8xftqqHg=

This isn't exactly a problem at all. Address collision remains very impossible with the sheer amount of computing power needed to even get a funded address in a thousand years. Making it collision proof would be unnecessary and fairly difficult to implement.
It's the problem with the mindset of the people. Bitcoin remains an attractive alternative to fiat and it isn't something that we can control.
Unless we somehow make mining less favorable for people with a vast majority of resources, there pretty much isn't any way to prevent centralisation of mining power.
The current block reward system aims to maintain a steady deflation while ensuring a limited supply of Bitcoins. It isn't possible for the block rewards to remain the same or increase in the future. The main feature of Bitcoin is the existence of a fixed supply and it isn't possible for the supply to remain the same throughout.
Lightning network can help to alleviate this problem. It's a matter of time when more people starts to adopt this.