Segwit is in effect a block size increase in a manner that ensures older clients are still functional.
Block size is a tradeoff between security and scalability, with the security factor decreasing as time goes by due to the far more efficient network. It is incorrect to say that we will be far worse off in terms of security and decentralization given a block size increase.

If you want Bitcoin to scale, you need a block size increase in conjunction with a 2nd layer payment network. You have to initiate the channels, in LN with an on-chain transaction and an on-chain transaction to close the channel as well. You cannot accommodate for those without having to increase the block size or make transactions more efficient.

The problem with solely increasing block size alone is that it is not a panacea for the scalability problem. You cannot increase the block size to compete with the next best payment processor. There is a limit till block size becomes excessively large and it won't be feasible to do so then. ECDSA signatures has to occupy that much space in a transaction while data compression is possible, I doubt it would be able to truncate the data to that extent.

Useless? I really doubt you can justify any lifestyle product as being "practically useless". If it is really useless, then there is no reason why anyone would be spending thousands of dollars on them. The electrical usage by those products are often quite negligible as compared to Bitcoin. There is a problem with Bitcoiners; they seem to draw irrelevant examples to justify the huge and frivolous usage of electricity on Bitcoin mining. Common examples includes: Carbon footprint on consumer products, electrical usage by banks, Carbon footprint on transport. Unfortunately, the utility provided by those products far outweigh those using Bitcoin.

The transaction volume and the practical usage of Bitcoin is fairly small, far smaller than your competing payment processors. In this regard, then your marginal utility is already smaller than major payment processors and they are obliged to put an effort into environmental conservation as well. Let's face it, Bitcoin has a great concept behind it but you can't justify the current electrical usage because the adoption of Bitcoin is so low!

---

It's green washing. Miners feel that they have to explicitly state that they are using renewable or green energy because the media focuses on that too much. However, this isn't a one dimensional issue. What is the opportunity costs of something like this; are people in those regions more reliant on fossil fuels because Bitcoin miners are taking a large proportion of the "green" energy? What is the percentage of the energy being produced being truly "green"? Are they carbon neutral and do they have zero environmental impact? How much E-waste arises from Bitcoin mining alone?

Blockchain.com or any other service are not obliged to compensate their user's funds if it is due to the user's negligence. Even in Coinbase where your funds are insured, there is a clause which excludes compensation in the event that it is the user's fault.

Stop using Blockchain.com or any online wallets.
No.

You should never use a seed generated through anything other than the HW wallet itself if you're primarily using it on a hardware wallet. That is a non-issue as you probably wouldn't want to expose your seed (and passphrase) to an Electrum instance while using Trezor.

It's quite trivial to fool the full node trackers (bitnodes, etc) with your UA. You don't even have to run a node to do so.

Might be an attempt to fool those that don't know better, but nodes generally don't represent the sentiments of the community. That is precisely due to the ease of manipulating it, which is why most people didn't really gave much attention to it. Except those with a certain agenda of course .

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.