You don't need for mining to maintain the same hashrate as today. The system works if it is more profitable to be an honest miner than to use their equipment to attack Bitcoin. The problem arises only if that condition is not fulfilled.
Once every ~4 years, so it'll be 5 halvings. Those are not the only factors; you have to include the potential for any on-chain capacity growth as well. I'd say this isn't an issue that Bitcoin really faces, you do have sufficient cushioning from rapid decrease in block rewards; decreases substantially at the start but then the fees gradually forms a greater composition of the revenue.

Oh okay. I stand corrected. I thought both of you were talking about importing using an xpriv key, since the topic is about using BIP39 in Bitcoin Core. Was thinking of using a workaround to use the mnemonic for that.

It isn't. The hdseed in the dumpfile is xpriv, you can't use the command with that.
Why do you need to rescan after flushing the unused keys?

This is incorrect. There is no encryption involved in mining or in the blockchain. Satoshi didn't encrypt anything and Satoshi also never designed difficulty to be the function of the block rewards/height. The difficulty is purely used to regulate the block intervals with each blocks. Miners merely finds the specific hash of a block header which meets the target. The hash is designed in such a way such that it is difficult to find yet easy to verify by the individual nodes around the network.

The only reason why pools are created is to reduce the varience of payout and rewards are proportional to the perceived contribution to the pool. Each share has a chance to form the hash of the winning blocks and the pools take it as such and rewards each share proportionally.
Block rewards is used to as a subsidy in the earlier days and doubles as a way to ensure gradual supply of Bitcoin, in exchange for the work being done. Miners merely tries to find blocks that are valid and include them into the Blockchain. They cannot arrange transactions in blocks after they have mined a valid block, nor can they re-arrange the sequence of the transaction in previous blocks. Doing so will invalidate the entire block.

If the transaction fees remains the same while value of Bitcoin increases, there will be a point where Bitcoin is no longer suitable for P2P transaction as it becomes too expensive.

The features are quite secondary. BIP39 has always relied on a list for the checksum which can be quite troublesome and presents a problem with the various locale that users may choose to use. The shortcomings are pretty much highlighted in the link I've posted.

There isn't any other viable proposal currently and BIP39 is probably the only finalized proposal out there. If there is an alternative proposal to that, then it won't be limited to BIP39. There isn't any point to making a mnemonic system specific to Bitcoin Core without providing an appropriate BIP for other wallets to adopt as well. I'm not saying Bitcoin Core should only be using an existing standard, but there has to at least be a BIP to better refine it before implementing it in Bitcoin Core.

Not a big fan of TrustedCoin but that isn't true. You're still maintaining 100% custody of your coins with 2FA since it is a 2-of-3 multisig and you hold 2 of the keys while they hold a single key. They cannot do anything without your approval but you can spend the coins as and when you wish, provided that you have access to your seeds. I'd argue that 2FA provides a marginal increase in security and I agree that an airgap setup would be vastly more secure than 2FA.
Your seed is designed to allow the user to access the coins with the seed only in the case of 2FA.

It depends on the passphrase. If your passphrase is long and random enough, there is very little chance someone would ever be able to be able to bruteforce it. I don't think Electrum limits the length of the passphrase. If it is long enough, then it would be equivalent to be bruteforcing without any prior information.

Yeah. But the current only standardized solution that we have is BIP39, don't think there is any other proposal within the BIPs and I assume Bitcoin Core would be primarily interested in having a mnemonic generated using a known standard.


I missed this part just now, sethdseed only takes a WIF key (ie. your private key), not the master key.

If you look at the BIP itself, it is actually unanimously discouraged from implementation. The reason is outlined here: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039.

Nodes will reject invalid blocks, no matter how many miners are complicit in that. Every full node in the network validates both the transaction as well as the blocks.

How would the UA of the clients affect anything?

Actually, with regards of a 51% attack, it depends. A state sponsored attack doesn't care about the profits or the economics of it and the seizure of mining sites should suffice for a significant proportion of the hashrate that can be used for an attack. Whether it makes sense for them to execute an attack like this, that is specific to each individuals. Pools can execute a 51% attack as well, the profits from an attack by a rogue pool far outweighs the costs. That is why Ghash.io faced a huge controversy in the past.

How are you using dumpwallet? You need to specify an absolute path.

For example: dumpwallet E:/Bitcoin/dumpedwallet.txt

This creates a file in E:/Bitcoin with a text file dumpedwallet.txt which you can open with any text editor. The master private key should be there. I'm assuming that your BTC wallet was created after the HD wallet integration, ie. there is a HD symbol at the bottom right corner of your GUI.

The users are paying 0.0005BTC per withdrawal. Granted that includes the fees from moving the deposits around, I would assume that the first course of action is for them to reduce the withdrawal fees for the user. Even if they decrease the fees that they are going to use, users are going to complain that they are skimping on the fees.

How ever much they spend isn't any of our business; it affects their profit margin and screws their users over. Them adding additional TXes into the mix doesn't necessarily bode well for the rest of us, there is another transaction to compete with the rest of the network. Even if they were to pay the high fees, it doesn't necessarily affect the remainder of the user. Algorithms don't look at the average fees being paid, rather, they devise their estimates from the bulk of the fees that the network is paying through fee buckets. Having a fraction of the blocks being occupied by a few high fee-rate transactions isn't a problem for the rest of the network, as long as the bulk of the transactions are still paying a normal fee rate.

I mean they aren't wasting any money, the user foots the bill.

Poorly implemented ones or those that don't know any better and has a fixed fee rate.
If you're in a hurry, it is simply not an option for you to increment fees slowly nor is it for those services where withdrawals/coin movement are time-sensitive. You can't really compromise in this aspect; if your algorithm guarantees a confirmation within the next block, your algorithm should suggest a fee which does exactly that. Slowly incrementing the fees for the algorithm simply won't work and would probably result in far longer wait before a confirmation for most. There should not be a scenario where the algorithm suggests a fee that risks not hitting the target, some services doesn't really have a choice; CPFP makes the TX unnecessarily expensive, RBF is not an option. The penalty for them is unnecessary costs with their transaction and the user has to be the ones boycotting them.

Currently, Bitcoin Core suggests a fee of 1sat/vbyte for a confirmation within the next block. Not all algorithms are flawed. If they are paying fees that are excessively high, then they probably already know about this and would rather spend more on the fees than to change the algorithm or having users complaining about their withdrawal.

Incorrect. For an attacker to purchase coins, they will influence the market with an upward pressure on the price as they try to accumulate that much percentage of the coins. This makes the attack exponentially more expensive. The problem with it is there is nothing at stake; you don't lose anything by supporting any forks. Allowing those who control a larger proportion of the coins makes them richer for virtually little to no cost.

Moving it all the way to the right pretty much guarantees a confirmation within the next block, because of how high the fee rate is. When you are shifting the slider, a dialog will appear telling you the estimated number of blocks it takes for a confirmation and the fee rates being paid. You should see the total fees paid getting increased as well.

As I've said, ETA is designed to overpay and for obvious reasons. Use mempool as an estimation if you're not worried about when it will confirm and ensure that the transaction is replaceable. You will be able to increase the fees later on if desired.

Most service providers are quite vulnerable to social engineering, and an experienced fraudster would be able to circumvent the security protocols quite easily, by collating the personal information of the victims.

Telegram offers an authentication ontop of the SMS OTP. Use it and you should be safe provided that your password is strong enough. I'm not sure what made the guy transact so much in Bitcoins, doing any transactions without another form of authentication is just bad in general. A typically case of something preventable, it was just a social engineering attack by masquerading as someone trusted.

Look at the resources needed to attack Bitcoin, a PoW coin. Attacking a PoW coin entails huge costs and resources. Given how you are constantly expending resources with PoW, there is a certain security through expending the resources.

PoS incurs no actual costs. In the event of multiple fork on the chain, attacker can choose to follow any chain without any real costs being incurred. Conversely, miners have to make a conscious decisions about the forks to follow with PoW coin. Following the wrong fork expends resources for nothing.

Bitcoin will not shift over to PoS. There is no reason why it has to.

It is designed to do so. If you want to base your fees using the position in the mempool, then there is a mempool option as well and that is approximately the same as any other mempool histograms.

IIRC, Electrum takes the ETA data from the server but can build the mempool histogram. I found it to be quite consistent with Bitcoin Core's which tracks the time it takes for transactions in their mempool to be included in a block and is calculated based on that. While this can resulted in a very conservative fees, it'll take into account block times, intervals, etc and give the user a better chance to hit the estimate.

Mempool.space's priority estimation, I think (maybe I'll take a look at their code in the future, not now) uses the mempool and the estimated transactions that is included in each block. Does it take into account the time elapsed from which the previous block was mined? This results in a far more responsive target but also doesn't average out the irregularities in block intervals. This will strictly be cheaper but it is definitely not as accurate.

What wallet were you using? Any well-designed wallet will not provide any estimates without a reasonable certainty that the confirmation would be met within the target. Floating fees in the wallets are fairly well-designed and users shouldn't face a problem using it. In fact, I would recommend for newbies to be using Electrum's ETA if they have no idea what they're doing. Simply looking at the mempool graph doesn't take into account all of the factors that would affect the time it takes for a transaction that it takes to get a confirmation. Floating fees are designed to be dummy-proof and we wouldn't include it if we can't consistently meet the target.

Mempool.space's estimation is quite vague, as compared to both Bitcoin Core and Electrum's which gives you the estimated number of blocks it should take.

Bitaddress does this for you, if you don't want to hassle yourself with the headaches if you do it incorrectly. You'll have to get the correct WIF as well, by the way.

Download the github repo: https://github.com/pointbiz/bitaddress.org. Validate it with the PGP signature file and open the HTML with your browser. Go to Wallet Details and Enter your private keys > View details. You should see both uncompressed and compressed addresses derived from the priv key. Run it on a clean computer with a clean browser (ie. no extensions).

No if you don't have your private key or ECDSA public key.

Do you think the community wouldn't react in a way in a timely manner to counter any potential malicious re-orgs and negate the impacts caused by them? The reason why 51% attack is so dangerous is mainly due to the financial motivation, where there might not be enough time for people to react in a timely manner. If you kill off Bitcoin, great! Another crypto takes it's place. So what now?

I believe that the costs for an attack like this, if it is currently on-going has ballooned to the neighbourhood of about 287 million dollars. I've already mentioned it quite a few times, you don't want to do a 51% silently. Proving that you can consistently annoy the hell out of the community by re-organizing blocks every now and then rather than doing a very expensive block re-org achieves the same thing.