Depends. How did you generate the wallet? Did you properly segregate your cold wallet from any internet connection? Did you validate your Electrum instance?
Your seed phrase is used to generate the private key, you will always be able to generate the private keys for the corresponding addresses. There is no way to disable this feature; the seeds generated by Electrum is only supported by Electrum but since the method of generating the BIP32 seed (and subsequently the addresses) is known, there is no risk of you not having access to your coins. Of course, barring any sudden network changes that prohibits the address standard you're using which probably won't happen.

Without authentication, it would still be vulnerable to MITM attacks. As long as you persist your MITM throughout, it won't be detectable without the parties authenticating. I don't think it is possible to authenticate effectively between Bitcoin nodes, especially since there is no way to validate each others identity.

Self-signing certificate is as good as not having a certificate at all. The purpose of a CA is to provide assurance that the certificate given is valid. If it is self signed, there is simply no way for them to validate the certificate. Even if you do have a CA, the reason why ISPs would be spying on you probably involves your government as well. CAs can be compromised and issue rogue certificates as well.

I agree. If you are afraid of your ISP eavesdropping, then you should be running Tor or some VPN in the first place.

There is another proposal under another BIP. I don't think it is officially merged into the BIP repo.

The reference client (Bitcoin Core) will validate the transaction to check whether it violates any of its policy, validity of signature, fees, UTXO existence etc. Reference client builds their own chainstate which contains the UTXO and they don't need to use merkle proof to verify if the UTXOs being spent are in the chain.

If a chain gets reorganized by a rogue chain, then the block rewards of those in the replaced chain would disappear, it would be as if they've never existed. They have been replaced by the rogue chain.

Yes, transactions are returned to the mempool provided that they stay valid, none of the UTXOs were spent in another transaction in the rogue chain. Reorgs are not that uncommon, stale blocks occur once in a while.

You need to include at least one transaction, the coinbase transaction. That can contain your block rewards, witness commitment, etc.

But yes, the number of transactions doesn't affect your hashing speed.

No. The hash given by notify is structured with respect to the block height the transaction is in, hash doesn't vary with confirmation increment.

You'd have to use the RPC to find out how many confirmations a transaction has.

Your wallet probably won't allow you to make another transaction that spends an input that has already been spent. However, there is nothing stopping you from constructing the transaction and pushing it yourself.

When a node receives a transaction, it'll get validated and the node will remove the UTXO involved from their UTXO set. This means that every other transaction that spends the same UTXO will be invalid to the node as the node has already removed it. However, if you were to broadcast the transaction to two half of the network, then assuming equal propagation, each half will see different transactions. This is known as a race attack, where in a scenario that a merchant sees TX A but infact TX B with the same inputs and sent back to a different address is also propagated on the network. In this case, then whichever transaction that gets included in a block first wins. The premise of 51% attack or any of that sort usually will have the attacker building a chain alongside the honest network.

For example, if the transaction gets included at block height of 2, then the attacker will start mining at a block height of 2 with a rogue transaction until they outpace the network. Afterwhich, they broadcast that chain and they're able to effectively overwrite the other chain as it has a higher PoW.
When a transaction gets broadcasted, it stays in a memory pool of nodes before it gets mined into a block. This state is different from each and every node; if you were to push two conflicting transactions equally to two nodes, they would perceive the state differently with them regarding the first transaction received as valid while not accepting the other transaction into their mempool. As a result, there is no consensus here at this stage.

Don't think of Bitcoins as an account but rather each transaction spending a specific UTXO (unspent transaction output) which gets used and created in the transaction. The concept of PoW gives whoever having the larger hashrate the liberty to choose and include either transactions, the number of nodes the attacker hold is irrelevant. As long as Jon is able to create a block that includes the transaction that he desires, then that transaction will be included in the longest chain.

Since no consensus is involved before the transaction is included in a block, then accepting a transaction with zero confirmation is riskier. PoW defeats double spending by achieving a consensus whereby each unique UTXO can only be spent once and once only in the same chain and an agreement by the nodes agreeing on the chain with the longest valid PoW.

Comes as no surprise, really. PayPal has long been supportive of the government and are otherwise quite complicit with whatever the government wants to do. While it is true that centralized services exposed you to risks like this, especially when their operation hinges on the government regulations, it doesn't mean all are bad.

There are still services which are far more transparent and are willing to challenge the government for the sake of their user. Anything to do with financial systems will always be under government influence, unfortunately. Except Bitcoin of course , not most exchanges though.

We don't. There was a BIP (BIP 151) which was proposed for end-to-end encryption but even that assumes that the certificate was exchanged in a secure manner. You cannot just trust certificates announced by your peers, you need to ensure a secure connection to obtain them. It'll be better for the user to just run it on VPN or Tor. DH exchange would be useful for situations like this.
Self-signed is not necessarily less secured than CA issued. There were cases where CAs were helping governments to sign certificate to spy on their own citizen. It is nothing out of the realm of possibility for this to happen if the government wants to do so. Electrum stores the certificate of the servers in their own data directory. I'm not sure how the certificate gets obtained but I guess it comes pre-bundled with the installation. I'll check the codes later and modify this if needed.

I mentioned this quite a while ago and received quite a few interesting responses: https://bitcointalk.org/index.php?topic=5271316.msg55064535#msg55064535.

Sorting by name that is arranged in alphabetical order helps you to bunch the same users together. It is quite a nice way for me to filter out the messages and credits is due to the original answer in that thread.

Terrible idea. You can implement something like this with existing cars, that should not be a feature which entices people. Think about it, if you have an EV, you're going to want to eliminate any frivolous energy consumption which reduces both the range and the lifespan of your battery. Why would you need to include something like this in a car???

Your energy efficiency is going to be even worse than before. Just buy a miner and a car, you'll be better off that way. Trust me.

BIP141 is the Segwit specification, most wallets actually use 84 as the index for Segwit. Electrum uses the derivation path as stated, though saving the seed should generally be enough. Only Electrum will be able to restore the seeds and given that it has a version byte, the derivation path wouldn't matter all that much.

No. BIP39 is the mnemonic standards for some wallets, Electrum doesn't use BIP39.

I assume the address that you gave is 37U6mb9bepC5LpW25xCvHAj4wAZCccyLdL. The other address with 82BTC is used as their change, that doesn't concern you.

Since the transaction has 5 confirmations right now, you should be able to see the transaction confirmed in your wallet. Is the bubble at the bottom right green or red?



Lightning network is only beneficial if your recipient is also using lightning network as well. It is an off-chain settlement and is cheaper as it doesn't take place on the Blockchain itself. There is a more comprehensive topic written by Rath_ and probably the best material to start with; https://bitcointalk.org/index.php?topic=5259973.0.

No doubt. The next one we'll see will probably be forced by regulating bodies.

They did say that they're updating it only this week in the video. I'd say give them sometime to do so, not like they're in a hurry anyways or anything would change.

Read the asterisk (https://github.com/lukechilds/howmanyconfs.com/blob/master/README.md#how-are-these-values-calculated). The site measures the work done needed for each confirmation which may or may not correspond to the possibility of a majority attack on the network. It does not outright reflect the security of the network as attacks has to be done with its profitability in mind.

Distribution or rather decentralization is not an accurate way of predicting the possibility of a 51% attack. Any adversary would not openly state that they have the majority of the network's hashrate but would attempt to distribute it in such a way that it is not obvious. Either that or they won't openly state the blocks that they mine. It is wrong to assume that attacks would only be carried out with a singular entity. It can also be done with multiple entities colluding as well.

Not possible. You need at least a master public key and one of the private key of the addresses.**

The most you can figure out from the addresses is the public key, which requires breaking two one way functions.

** This allows you to derive the master private key of a non hardened derivation.

It doesn't. The article doesn't state that they are not censoring transactions specifically due to Taproot but that they're upgrading without including any censorship features to filter the transactions. Likely just a decision that they've made and has nothing to do with Taproot.

They've probably realized that openly filtering transactions has gone wrong and lowered their profit margin without any censorship effects. Continuing their own practices this way would get nothing done and just make people unhappy. However, filtering transactions covertly would not.

In the scenario with any attacker holding 51% attack, the attacker can reorganize as many blocks as desired but that mostly depends on the profitability of doing so. The concept of 6 confirmation just means that the attacker needs to at least be able to outpace the network to be able to reorganize more than 6 blocks.

You need lesser hashrate for lesser confirmations as you're looking to reorg lesser blocks and thus having a better success rate. In the unlikely event of competing blocks, then it is completely possible for a transaction to be double spent, depending on the fork that forms the longest chain. 0conf transactions is less than feasible now... Trying to accept them will put you at a significant risk.

Depends on your risk analysis, fee market tends to fluctuate quite wildly. You likely would be safer with non-RBF and a high fee but that comes at an expense of having your user pay more and potentially get their transaction stuck. Not an issue that I recommend people to be dealing with.

No you can't. Even a confirmation is difficult. Every confirmation basically means that a block has to be rolled back, or another block has to be mined at that height. This requires either the network to be on two different forks, with one of the fork containing your transaction and eventually accepted (in the case of competing blocks at the same height) or if a miner helps you. 6 confirmation is the amount of confirmations required that makes it improbable for an attacker without 51% of the network hashrate to reverse your transaction. So no, unless you're able to get a miner with significant hashrate to help you and attack the network, it is not possible.

It is statistically improbable.

The combination of words has to be in the correct permutation for your wallet to be recovered. The complexity of being able to find a set of seed phrases that has been used is roughly the same as finding a used private key as well. Provided that your RNG is random enough. If the length of the seed phrase is at least 12 words long, you're fine.

If you have opened someone else's wallet, then there is a problem with your wallet, probably generating seed phrases insecurely.

Not really. SHA256 isn't used in everything; for example, passwords usually uses some KDF to provide some resistance against bruteforcing. In comparison, if we figure out P = NP, the cryptography and possibly most things on earth will fail. Not really related to topic but just a nice tidbit.

Anyways, the nature of how Bitcoin uses SHA256 makes the issue not as serious as it seems. The possibility of collision or preimage attack would introduce forks by blocks or TXID with different content but same hash, tricking people into signing unintended transactions, etc. SHA256 is strong as it is currently, the complexity for something like this is still out of reach.

Electrum does give a warning if the fees is outrageously large when compared to the amount that is supposed to be sent. That should be sufficient.

If the transaction size is too big, and the user ends up paying too much, then the user will notice and adjust either their fees or their inputs accordingly. If it doesn't trigger the warning, then the fees should be within an acceptable amount and since it is a consolidation transaction in a sense, it is still beneficial to the user as it can potentially save more on the fees in the long run. While there is nothing wrong with a dialog or a popup, users tend to be quite myopic and won't see the point behind specific client behavior such as this.