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.

Don't use static. If you don't know what you're doing, you're going to pay fees that are either too high or too low.

ETA is very conservative and nets you a confirmation within the specified number of blocks almost all the time. This also means it tends to overpay for the fees.

Mempool, is only indicative of the fee rates at current X MB from the tip of the mempool. It gives a spot reading and does not actually reflect the current network conditions. However, if you aim for 1vMB from the tip of the mempool, you should get a confirmation within the next block or in a few hours. That varies depending on the circumstances.

When you use a slider, there should be a box which is displayed and that tells you how many blocks before you can get a confirmation or X vMB from the tip.

Sliding to the right means that you will pay more for the fees and a potentially faster confirmation.

Oops. I was thinking of using Grover's which works for both. Point stands, the security of addresses isn't reduced more by quantum computers through the possibility of collisions as opposed to cracking the ECDSA directly. Finding collisions of RIPEMD-160 is still difficult enough, combined with the fact that there is SHA256 hashing prior to it and that you're finding a very small set of keys.

You might be able to find a collision of two addresses far in the future but it still probably wouldn't be worth the time

Exchanges are a service, they are not representative of the security of Bitcoin unless everyone only uses them when they're using Bitcoin. The security comes from whoever is holding the keys for their funds, which is ideally themselves.

Banks are more like your wallet, where you can park your coins while those exchanges are solely meant for users who wants to exchange their coins for another currency. The security of their platform is this largely dependent on their competency. It's not like banks hasn't been hacked before, see Bangladesh SWIFT hack. You don't see banks getting bankrupt because their activities are often fairly low risks and if something goes wrong, the government would probably bail them out anyways.

Use quantum computers to crack the ECDSA keys for those. Collision is quite a lot harder.

That would never happen. Satoshi probably won't appear again nor touch those coins.

Speed up for symmetric algorithms are far smaller and probably wouldn't be sufficient to find specific keys. It's not like there is a huge portion of known Satoshi keys.

I think you meant using QC to directly crack the public keys.

Again, this is pure speculation. Bitcoin's reach is mostly bounded by the ability of the people to use it, given the high penetration of internet and internet connected devices, it wouldn't be a stretch to assume that there isn't loads of growth to be made in that aspect. I mentioned in my previous post about the difference between adoption and investments; adopting entails actively using it as a currency to serve its purpose. I would argue that it doesn't really matter until bigger economies start to endorse and accept Bitcoin. Based on the resistance by the various government, I'm not so sure if it'll happen soon. Firms are largely also investing in Bitcoin in hopes for it to rise, which defeats the purpose of Bitcoin as a currency and making it a speculative asset as well.

In 10 years, anything can happen. Will Bitcoin finally be able to scale, with little conflict? Will the government or firms still be willing to endorse Bitcoin once the FOMO blows over? It's completely uncertain; everyone saw the true colors of Tesla after a couple of weeks, perhaps everything that has happened so far is a facade for a different agenda. It'll be a sweeping statement to assume that Bitcoin will rise in the long term; it can very well be but there are obviously various shortcomings of Bitcoin that are either innate or difficult to solve.


The price is not indicative of the adoption rates.