You can actually set your own hdseed through sethdseed. The hdseed that Bitcoin Core accepts is in WIF format so any new addresses will be generated from that. That is however not the recommended way to backup your wallet, backing up the entire wallet file would be far more prudent.

Mnemonic is meant for easier memorization and it is fine to memorize it ontop of your physical copies. However, if you run into the issue of possibly losing your wallet file, then you probably didn't ensure enough redundancy.

If you propagate an invalid block, then your node would just be disconnected and added to the ban list of each node. This makes sure that only the malicious block of nodes are segregated from the others but not the honest nodes. This doesn't actually affect the rest of the network as they would just wait to get an honest peer which doesn't propagate invalid blocks.

It is perfectly possible to execute a Sybil attack against the network, and the attack that can happen would be an eclipse attack. However, Core has countermeasures against it as well.

Satellite used by internet providers like starlink uses radiowaves to transmit information to their users. Starlink's bandwidth is sufficiently fast for Bitcoin nodes to operate so it would be perfectly feasible to run Bitcoin nodes using a constellation of satellite.

It might not be feasible for HAM radios to be used, unless you are talking about transmitting transaction data only (ie. SPV and block headers only). Depending on your setup, your bandwidth might be excessively low for anything like that to be feasible.

ScriptPubKey does not actually contain the public key. It is just the conditions that can be used to spend the funds, in cases like P2PKH outputs, you will find the HASH160 of the public key and only if you have the P2PK output, then you can see the actual ECDSA public key.

For normal scenarios like P2PKH, P2WPKH, since it dictates the HASH160 (SHA256 and then RIPEMD-160), the conditions to be fulfilled requires for the public key to be revealed. As such, you can validate that the public key hashes to the key in the unlocking script and for the signature to match the public key. With a public key, you can use it to produce the various scripts that requires your public key, and from there you can derive the possible ScriptPubKeys that corresponds to it.

Hmm, can't find it. The lowest I can find thus far would be 0 back in 2017. Maybe someone else can find it.
As of now, the only reason why you can get a block is if the hash of your block header meets the target. If you want any other conditions to affect it, then there will be a hard fork and the supply would be quite difficult to balance. Layer 1 won't be abandoned, settlement is done on it.

That is untrue. You can choose to fix a specific nonce and change something else in the block header. It is just terribly inefficient in most cases. Miners are entitled to claim up to the current block rewards, which is at 6.25BTC and the transaction fees. Any miners which is building a block can choose to include all of block rewards, part of it or none of the block rewards. This has absolutely nothing to do with nonce or the choice of it.

Let me know the block height, might've missed this before.

That is not a mistake. Did you sell your Bitcoins with the knowledge that the price of Bitcoin would grow even further after that period of time? If the answer is no, then you didn't commit a mistake. You merely didn't have the hindsight that Bitcoin would grow even further.

Contrary to this, if Bitcoin tanked before you managed to sell, then it also becomes a mistake, for you didn't manage to sell in time. That surge in Bitcoin price wasn't particularly predictable either so I wouldn't call it a mistake.

You probably won't notice, if your own pool can just send the work template for another miner. Of course, this isn't accurate by any means and would probably not be that ideal given how stratum and the mining software differs.

It would be far more likely for the assumptions to be made on the likelihood of a block being found given X shares.

Block withholding attacks has happened before. Eligius had an attacker that was witholding several blocks in the past and was discovered and the account was locked. It worked for awhile but it really doesn't make that much sense to attempt this on a pool. You would probably be subjected to the pool 'testing' your miner by sending parameters that would result in a block and you'll still be incurring costs in the midst of it.

PPS, FPPS and other schemes tends to pay lesser than PPLNS in certain cases so that is also a mitigating factor.

The risk exists across all of the platforms/devices and wallets. Your OS could've had the entropy being compromised inadvertently, or your wallet could've wrongly implemented the CSPRNG calls. The only real way to mitigate this is to review the code yourself to ensure that it isn't broken or to check if the signature of the firmware is checked and signed by someone you trust.

Download Electrum(electrum.org/#download) and verify it[1]. When you start Electrum for the first time, you should be greeted with a screen which asks you to create a new wallet, choose Import Bitcoin addresses or private keys. In the box, insert your private keys in this format:
Just make sure that for each line, p2pkh: is appended before the private key.



[1] https://bitcointalk.org/index.php?topic=5240594.0

Signal and Telegram are not encryption, neither are they used to secure data. They are messaging applications.
Nevermind, might've misunderstood it. They operate on a need-to-know basis, messages are encrypted from end-to-end.

The hardware wallet company needs your personal data, or else your hardware wallet will never reach you. Unlike passwords, which allows for websites to only store hashed and salted database, you cannot store an encrypted shipping address (without it being decrypted at some point in time), because that is useless. At some point in time, your shipping data will be made known to the company and that is the time frame for which it can be compromised. Problem being, certain company was found to have stored the data for longer than necessary (ie. after the device is shipped).

Sure, hardware wallets can definitely do this. Use a flawed RNG at any point in time when you're using your device. This is why independent audits and having their firmware being open source are necessary. The way most hardware wallet is designed makes it such that it is difficult to embed malicious codes without changing the chips themselves, ColdCard for example does a check on the firmware on every boot and its bootloader only takes in signed firmware.

Still, there is a certain level of trust which can really never be eliminated. I'd probably still support a well-known manufacturer though.

Paper wallets are fine, but most people don't know how to use it properly. For the sake of simplicity, I'm answering from the POV that both HD and single address paper wallets are the same.

I skimmed through the video, so forgive me if I got any of it wrong. Cold storage are offline methods of storing the keys, but it doesn't guarantee any degree of security, or at least without the user intentionally practicing good security habits (generation, and spending namely). I've long advocated for most people to use hardware wallets, because they are designed to be secure. They are convenient in the sense that they dumb down the security for most, to the point for which it is harder to make common mistakes which can compromise the security.

If you can correctly and securely establish your own air-gapped wallet, then sure, you should use it by all means. That eliminates the costs going into it and also the degree of trust into the device and the manufacturer. However, if you know that you might unintentionally make any mistakes which can compromise your security, or if you're unsure about what attack vectors that you're trying to guard against (and if you can eliminate them effectively), then please use a hardware wallet.

Personally, I've used a RPi as an air-gapped wallet for quite a while but the hassle of it doesn't really appeal to me, though I know I can properly generate and use the cold storage. I opted for a well-known and transparent hardware wallet and have never looked back since.

It cannot be recovered.

The original intended address AFAICT from the Twitter account is bc1pfdjlc5p92pxzvacgc5nhn3vgtt54e98472ymxgtejaa0ttdx8lkqzn304u, but the funds were sent to  bc1qfdjlc5p92pxzvacgc5nhn3vgtt54e98472ymxgtejaa0ttdx8lkqgy3xdq. Notice how they changed the address type (P2TR to P2WSH) to ensure that the checksum is correct and that it becomes a P2WSH address. The problem with this is that you cannot interpret a tweaked public key in P2TR as a script hash. Hence,  you can't just fulfill that criteria because it is now treated as a P2WSH instead of a P2TR type.

You can, actually. It just requires a few more steps (from P2PKH to P2WSH and from P2PKH to P2WPKH). Even so, it shouldn't be done because there would be ambiguity to which the funds should be sent to. There is no address standard that strictly mandates 2 or more private keys being required for spending, you can optionally include it as a requirement for your P2WSH.

With regards to the post, Binance made a mistake and burned the coins.

Mining is more profitable when there are high fees, because blocks are always filled with transactions and the average fee rates are a lot higher. It doesn't necessarily mean that the network becomes insecure; sure it becomes relatively less secure, because certain miners find it unprofitable to mine but it doesn't make for an insecure network.

The transaction fee is a function of many factors, the most important variable at play is the transaction volume in terms of size. It hasn't been that high since the peak a few months ago and you can get away with much lower fees if you want a reasonably fast confirmation.

It isn't increased to 4MB. Best estimates in real world scenario puts it at about ~2MB, a little bit higher maybe.

Not really. Taproot does help to scale but it doesn't have as much impact as the others. Taproot is relevant in specific scenarios but doesn't bring about a scaling across all of the different uses.

---

The thing about scaling is that it won't really be solved, just alleviates the problem at a certain stage. LN is not the solution that magically solves the problem with on-chain capacity, because it merely shifts to 2nd Layer settlement which still requires on-chain transactions. If you need scaling, then you have to either increase block size or reduce the size of transactions, for which the former is easier.

Again, for the record, using it solely to scale or viewing on-chain scaling as the only solution to our problem is not correct. You will hit the wall at a certain point which makes it infeasible to scale further.

Nope. It shouldn't be difficult to decrypt if OP knows the passphrase.

OP can just decrypt it locally and import it into a wallet, but IMO it isn't really worth the effort. It would be far easier to just import it using their online utility, and in this case probably wouldn't warrant so many extra precautions because of the extra effort that comes with it as well. Blockchain.com has HSTS so there isn't a huge risk of MITMs, at least that easily.

If the address was a well-known service, then you can use walletexplorer.com to check which group of addresses it is connected to.

Your exchanges. The nature of Bitcoin makes exchanges loosely regulated and that there isn't proper regulations in several jurisdictions. There has been cases of exchanges intentionally influencing Bitcoin's price (MtGox), not that there is really any concurrent manipulation but that isn't out of the realm of possibilities.

Dumpwallet can help you narrow down your range of addresses. You might want to use listreceivedbyaddress RPC and specify your own parameters to dump the appropriate addresses.