Private key, yes.
Should have 51 or 52 characters, does it start with a 5, L or K?
You shouldn't. The older Multibit wallets likely won't allow you to transfer the funds.
Yes. You should be able to extract is relatively easily if it's unencrypted. The format should have your addresses listed in one column and the private keys in the other, assuming multibit classic.
Electrum. You only need your private keys.

Possibly cents. It's important to note that opening or closing a channel would incur some fees for it's an onchain transaction. My funding transactions are always executed at lower fees so my recent funding transaction was about $0.1 or so for $100 of TX. The fees for transacting within the Lightning network is practically negligible.

IMO, if you really want to determine a fair fee, you have to evaluate the costs per transaction in terms of the resources used. For LNs, they are usually fairly low cost to run as compared to on-chain transactions. As such, if you're talking in the context of LN, then the fair fee to charge is probably just several cents.

---

On-Chain transactions are out of the question and I believe you're not talking about it in this thread.

Well, then I guess you're better off with airgapped storage. It really boils down to if you trust the HW wallet manufacturer in this case, if you don't want to trust anyone else. At the same time, you have to make the same assumption about your cold storage wallet as well as the OS.

I wouldn't say that it's hard to prove. I'll be able to see the various commits to the github page if I were watching it and it makes inspecting the code before updates much easier.

Might have some spyware, after all they tend to include a ton of spyware. I'll wipe them and just install Linux. The popularity and the design behind Linux based OS makes the chances for persistent malware infection harder.
Your use case would probably make hardware wallets more attractive.

If you'd like, you can just purchase 2 Raspberry Pis and use them as cold wallets. My personal preference would just be to put some funds in a hot wallet and bring it around. Even if I were to lose them, I wouldn't lose all my funds.

As your Bitcoin Core synchronizes, it indexes transactions that are relevant to the addresses within the wallet.dat. It periodically (or when starting up or shutting down the client) writes to your wallet.dat file the best tip which is the latest block so that it is able to keep track of the point whereby the transactions related to your wallet.dat weren't parsed.

The wallet.dat isn't readable as it's in berkeleydb but you can dumpwallet and see that it does actually indicate the hash of the block where your client has synchronized to.

Block transaction as in censored? The only way for censorship to be 100% effective is for someone to gain a majority of the hashpower.

If you're asking for blocked transactions as in transactions that are not mined,they're typically submitted to a mining pool and the mining pool will include it in their next block, when they mine it and there's not guarantee of the timeframe. A miner mining as a part of the mining pool usually don't have a say in the transactions that is included in the block being mined. The only way you can confirm a transaction is to mine a block which includes that specific transaction and for that to happen, you need to generate a block which fulfills certain criteria and that is very very difficult.
Mining pools usually get a block more often than solo miners is because the hashpower are "pooled" together and thus more hashes are generated per unit time, resulting in a greater probability of getting a hash that fits the current target. When the miner includes a transaction specifically, they will (not necessarily manually) insert the transaction into the set of the transactions that they're mining and build a merkle root based on that. If and only if they mine a block then your transaction can be confirmed.

Mining softwares are usually connected to a pool or node of some sort which will feed it with the information required.

The mining software will obtain the information needed to build a block header from the program. The ASICs merely hashes the block header twice with SHA256 to obtain the block hash. The variables within the block headers are changed with every attempt to ensure that the output is a different hash for every attempt. Only when the hash meets the minimum target, it will submit the correct block header to the mining pool. The mining pool will relay the block across the network and the reward becomes spendable after 120 confirmations.

There's no such thing as a verification node sending coins. Neither will the mining software interact with the coins, it's primary purpose is to supply information to the ASICs. When you're building your block header, you'll assemble a set of transactions and in that set of transactions, there should be a coinbase transaction which would consists of the coins being sent to the address that you've specified.

You have to Sign first before you can broadcast the transaction. Remember to not tick the box in the Bump Fee dialog to make the transaction final. It should still be replaceable.

Right click the unconfirmed transaction and select Bump Fee. You should be able to see a dialog to see the fees for the replacement transaction. If you do this, the transaction will be replaced with a similar transaction with a lower output amount and a higher fee.

There's no guarantees that there are possible backdoors or vulnerabilities that could be intentionally or inadvertently inserted as well. If it's of any assurance, some hardware wallets are actually audited regularly and/or has their schematics and firmware open source online. That's the reason why I bought a ColdCard.

To be fair, NSA did try to backdoor Linux quite a few times. Doesn't make it any more safer than an opensource firmware which certain HW wallet manufacturers provide.



You can build and compile the firmware yourself. You can also build your own ColdCard[1].

IMO, verifying something is often referred to comparing the hashes and/or using the PGP signature file to authenticate authenticity. When such an argument about security (with a high degree of paranoia) is put forth, the rational thinking is to assume that everything is compromised, not being able to trust the OS and thus reading through the entire source code and understanding how everything works. In this scenario, I would prefer to scour through the firmware of HW wallets since they're relatively light weight and more transparent than most.


[1] https://github.com/Coldcard/firmware/tree/master/hardware

They are. The transaction will be quite big with a large number of inputs and outputs so I inferred that OP could have been referring to that and people could be doing repeated CoinJoins. I can't tell what it is unless OP states the addresses.

Thanks for the topic. I've had quite a few discussions with the community here regarding this and I've maintain my stand that hardware wallets are better than airgapped wallets (at least perhaps till this thread).

Don't get me wrong, airgapped wallets are probably secure, enough for normal use anyways. I don't think there is a major risk of anyone getting their funds stolen through this and I've personally been using a Raspberry Pi airgapped till now, well if my ColdCard arrives and it wasn't lost in the mail.

I think the main argument that I've seen so far is that they don't trust the hardware and the internals of the hardware wallets. Well, to be fair I don't think you would specifically open up your computer to inspect the internals as well, given that most of it is proprietary and some of them are hard to decipher. Most hardware wallets are fairly open about what they use and the reason why I chose ColdCard is because I wanted to see the internals for myself and the fact that it's open sourced does give me extra assurance and the ability for me to inspect it further.

If you want to seriously compare the security of airgapped vs hardware wallets, then the sidechannel attacks are impossible to defend though I think secp256k1 is less susceptible to some of it than others. Hardware wallets are usually hardened against those. When I use cold storage, I always compare my Electrum implementation to an actual hardware wallet. Truth is, it is very hard to bruteforce the hardware wallets, given that the secure chip will almost definitely brick your device after X attempts. I can probably clone my SD card for my RPI wallet and spend some time trying to crack it. Well, it's hypothetical because I do take extra steps to secure it but I think bricking a device would make it impenetrable. Of course, plausible deniability is a huge plus for HW wallet as well.

Now, I can definitely see some points for airgapped wallet given it's more traditional approach as well as the fact that you won't tell the whole world that you have Bitcoins (erm Ledger) and that it is much cheaper. I think there are arguments to be made for both sides but I think in terms of both it's absolute security and it's balance between both, hardware wallets are still a compelling option.

As for the exploits that you see, I think Trezor got unlucky but they tried to mitigate it still. I don't think anything is inpenetrable but given how their business is centered around the security of their wallets, I would still trust that they can try to detect and mitigate most vulnerabilities that would appear, more than a cold storage definitely.

The database leak for Ledger was a giant facepalm and I was quite disappointed as well. Using a reshipper or a PO box could be useful when buying things online.

Lightning network. I've used it quite a few times and it was simple to use and saves the fees significantly.

Whilst I've long thought of the risks of unconfirmed transactions being fairly manageable, I don't think that's the case anymore. Opt-IN RBF has to be mandatory in case the fees are too small. Lightning network is mature to the stage whereby it's safe to accept payments using it and it'll be an attractive alternative to the onchain transactions.

Wouldn't the process only work for values within the blockchain which has a certain fixed pattern, like first few bytes of block hashes. But that wouldn't be the case with signatures, UTXOs, TXID etc within the blockchain which doesn't necessarily have a fixed value? I would think 20% is quite hard to achieve and minuscule optimizations within the block hash and more fixed values within the blockchain could possibly be compressed.

Current value. No exchange would want to lose money and risk having to wait for your BTC to confirm.
Free transactions are not realistic any more.

The main difference between different wallets is the way they handle the transactions. Electrum does offer features such as easy RBF, CPFP while giving the user the control over their fee with the native segwit. That's why it's often recommended because it's UI is easier to use than most. Fees wise, given the same conditions (address type, mempool, etc) , there shouldn't be any fee differential between wallets.

I'm conflicted. Significant portions of my investments were cashed out pre 19K levels and I was hoping for a drop so I can buy it back but at the same time, a drop wouldn't be good for the rest of my Bitcoins as well. I've been expecting a correction since 22K but it never came. Oh well, HODL and hope Bitcoin goes to the moon. 

Possibily mixers, or CoinJoin transactions. They are used to obfuscate the origin of the coins by intentionally adding hops to transfer the funds over many addresses and thus making it difficult to track the addresses. CoinJoin transactions typically has many outputs and inputs as well. Or exchange's addresses as mentioned.


Or, though unlikely could be someone trying to push up the mempool's fees by artificially inflating the number of transactions. Could you send a link to the address? It'll make it more evident.

To be more specific, the signature is contained in the scriptsig, together with the public key. The validation is done then with the signature in the first ~70ish bytes and the public key at the end. There's no hash but the nodes will calculate the signature with your raw transaction and your private key. The signature encompasses the entire transaction and as with public key cryptography, you only need the public key to match the signature.

---

I don't think factory reset will necessarily cover all the malware there is, some malware can exploit the privilege escalation to plant itself into the firmware and factory reset won't remove it. It seems pretty hard for the malware to really transfer information anyways so it's not that big of a deal even with malware.

I think using Tails on a USB would be quite convenient as well.

Depends on whether you want to trade storage space for CPU and/or IO. In addition, the main bulk of the data doesn't come from the block headers but the transaction. Trying to save on block header wouldn't provide any size savings in the first place.

More often than not, the bottleneck doesn't lie in the storage space nor the bandwidth, those has gotten relatively cheaper throughout the years. IO speed and CPU are usually the main concern for most. Compression won't help in this way and it's a hassle to decompress the entire blockchain when synchronizing and/or rescanning.

It doesn't really matter all that much in this aspect. Giving more people access to the source code does not automatically mean that more competent people would be available and willing to audit the code completely given that they "likely" lack the financial incentive to do so and close source projects are more likely to consists of certain proprietary aspect and it would be to their advantage to get more competent people to dedicate their time completely to work on it. I bet most of the major tech companies has more people working full time on their projects with more experience, and obviously more funding to operate bug bounty programs.

Obviously, an attacker can better see the codes and see if there's any bugs or exploit within the code and use it to their own advantage instead of working to fix it. ShellShock was undetected for more than a decade.

Not to say that open source projects are bad at all, there are certainly valid points that I would get behind, especially the point whereby transparency can be ensured. An open source project is not necessarily more "free" of vulnerabilities and bugs than a close sourced one.

---

I think one of the main benefits of open source projects, other than it's transparency is it's ability to allow people to modify the codes to suit their own needs. If you don't like certain features, want to add some features but the repo maintainers don't like it, go ahead and fork it.

How do you think AI would affect ECDSA or more specifically public key cryptography? AI (or rather machine learning) does analysis based on certain trends and using passwords/dictionary attacks usually results in the algorithm being fed with big data and finding association and possible passwords based on the targets. If you want to bruteforce using this method, you could find success with leaked database but most likely not with sites that are designed to deter such attempts.

Now, back to the topic. Public key cryptography uses randomness generated from sources to generate the private key. Since the generation methods involves large amount of entropy, if given a public key, how would you use AI to tackle the algorithm and solve for the appropriate private key?