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.

It was there when Bitcoin Core still considered transaction priority in their relaying and miners still mined free transaction. It was removed once Bitcoin Core removed the logic as well. Don't see much point in keeping this as spending coins in chronological order is quite detrimental to the user's privacy as well.

Might seem paradoxical since the client leaks so much privacy but it's better than them not doing anything about it.

Sending to exchanges means that the principle that past experience doesn't determine your future experience applies. If anything occurs during your transaction, the onus is on Binance or whatever exchange you're using to solve it. There is pretty much nothing that could go wrong as long as you are sure you're sending to the correct address as shown. Even with less established exchanges, you never know if they'll pull a quick one on you after you send a larger amount.

If anything, sending it once and doing multiple checks is more ideal than sending it multiple, thus increasing the room for error as well as the fees.

We're not concerned about the potential of someone executing an attack but rather how much resources is required to attack the chain.

Reorganizing is equivalent to replacing the blocks. Yes, you will. The distribution of the hashpower isn't the main point here though, distribution of the current hashrate gives you the potential of the majority to execute an attack but it doesn't take into account the cost. Distribution is thus independent of the game theory which is whether they will attack the chain, given the cost and benefit of it as well as the decisions of the other stakeholders.

Back in 2017, the 50th percentile as mentioned by Bitcoinstats.com is ~2s but the 90th percentile will definitely take some time. It is to the best interest of the miners to be included as upper bound of 50th percentile. It is to the best interest of the miners to be as well connected to each other as possible, while centralization concerns are valid, it becomes less if the time it takes to propagate through the network is fairly quick and it isn't illogical to assume every miners will try to get the best possible connection.

Certain miners are more well connected than the rest as of now, either through zombie nodes or a similar implementation to FIBRE.

I don't disagree but that is assuming stales are still occurring on a regular basis. Since 10 minutes essentially represents 10 minute worth of PoW mining and thus a higher cost, doesn't it make sense for merchants to be still allowing 1 confirmations? The need for a 10 minute confirmation as a measure of security can be quite overblown at times; I find it sufficient for half or 10 times less of the current opportunity cost for something that costs $1.

Transactions are not invalid after getting mined in a stale block. In fact, large proportion of the transactions are probably included in both the blocks and thus no matter which fork prevails, your transaction has already been included in the chain. Stale blocks are not a very serious security risk, if the transactions pay enough fees,  then there is a high probability of them being included in both the blocks. It does make it easier for someone to double spend if merchants starting accepting 1-2 confirmations if stale are very prone, which makes it a risk and people can probably exploit it without much effort.


No. The cost of re-organizing the blocks is what matters. It doesn't exactly matter if I have 60% of the hashrate, I can easily do a 51% attack but there is no incentives as it is far more expensive than to just mine as an honest entity.

Secure element is designed to never leak the seeds or to at least make it inherently difficult and/or expensive to access it. Passphrase is used as an additional security measure against attackers if that layer of defense is broken, plausible deniability as well but using a passphrase is not desirable in all situations; not being covered by checksum, forgetting it, etc. AFAIK, CoolWallet has a secure element which makes it that much harder to extract the seeds in the first place.

The fork occurs if two different miners were to broadcast their own blocks and the propagation makes it such that different miners are working on different chain and one of the block gets continued. So assuming that, the time it takes for a block to propagate becomes a factor. If the blocks were to be propagated quicker than X, then the chance of a stale block occurring lowers significantly as well. That is assuming two different miners don't mine the blocks at the same time.

Now, there are implementations such as FIBRE which supposedly reduces latency to the range of milliseconds among miners who runs the node. It is unfortunately deprecated now so I can't find any stats on it. If we were to use it in conjunction with FIBRE, then there shouldn't be a very significant increase in the stale. Of course, there is a limit at which stale blocks becomes far more prominent but I'm sure that 10 minutes at 2MB is still quite conservative given the conditions that we have today.

Besides, it is to the miners interest to attempt to reduce their latency as well. I've not really seen a whole lot of stale blocks involving well known miners so much nowadays. It is almost always between a larger mining pool and some miner that didn't tag their own block. I wouldn't be surprised if the larger miners are far more interconnected than the rest of the network using some form of direct connection.

For the record, I don't think 1 minute block would be well supported and might cut too close to the threshold but I find that we could perhaps explore the possibility of capacity increase in Bitcoin either with larger block sizes or block intervals.

Double spending is impossible in Bitcoin if and only if you're looking at the blockchain alone; a single chain cannot have two of the same inputs being spent twice. You can however, choose to spend an input that has been spent before and is currently in the mempool. Technically, by being able to broadcast a transaction which spends the same inputs as another in the mempool is regarded as double spending it, though obviously the other gets kicked out.

This is not an accelerator as some of the users here are claiming. This is a site to broadcast two competing transactions by broadcasting a conflicting transaction after the other. This site isn't intended to help users to use RBF to unstuck your transaction but rather to help users intentionally replace a current transaction with their own. You can do so with any wallet that support RBF.

Yes. That is correct. You need to spend funds from that address. I'm under the impression that OP meant sending and spending. Nothing is achieved by just sending a small amount.

It is honestly better than nothing. There are loads of bots which monitors the network for any r value reuse. If they detect any, then they will attempt to push a competing transaction and thus stealing your funds. That has been the case for quite a couple of years... Especially since that Blockchain.info and those Android wallet vulnerability.

I would probably recommend people to use more well known wallets, but if they can't then it would be a good idea to check if it works in the first place. Using a wallet that isn't well tested is a security risk nonetheless.

The protocol itself might be working fine, totally understandable but you can't say the same for the wallet client.

The address has a checksum and can be valid. However, the problem lies if the client somehow generates a nonstandard address. For example, if your wallet client uses a non-compressed public key to generate a Bech32 address, the network considers it nonstandard. You need a miner to be willing to manually include it in a block that they mine. Or, worse off, if the transaction is valid but the developers accidentally makes the transaction reuse the r value. The latter is quite unavoidable and can happen after several iterations of the wallet but it is a good way to tell if the wallet is suitable from your first try.

It should not happen with most wallets, provided that the developers are competent at the very least.

It isn't always an option for users to only use Electrum when the network is not congested. Users have to actively use coin control to change their outputs. Consolidation transactions should only be done when it is not congested but normal transactions should not be treated as consolidation transactions. It is unnecessary and incurs too much fees.

In normal usage as intended, the user won't run into such issues. Electrum tries to get their users to use different addresses from each transactions. This makes it such that each bucket only has 1 UTXO as the address is only used once. Hence, the transaction would end up being the most efficient. If the user reuses their addresses, this won't hold true and the user has to adjust it manually.