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.

The way Electrum functions is that it primarily tries to group the UTXOs into "buckets" with each bucket containing UTXOs associated with the same address. If any coins is being spent from a specific bucket (or address) in this case, then Electrum attempts to spend all of the UTXOs that are grouped into the same bucket as a way of consolidating and avoiding privacy leakage. A second bucket or more buckets would be selected if and only if a single bucket cannot fulfill your requirement. You have to manually select the inputs to spend via coin chooser if you want to spend specific inputs or avoid spending all of them.

With your example, all of the inputs are grouped into the same bucket as they are all associated with the same address and also all confirmed. Electrum thus selects to spend that bucket and it has to spend all of the UTXOs.

Electrum tries to maximize the user's privacy in this case. There isn't anyway to disable this kind of coin selection AFAIK. Interesting to note that other than this, Electrum also tries to only spend coins from the same bucket or select buckets which would produce the change that has the closest value to the recipient amount.

Yes.
ECDSA is associative. Remember that G + G = 2G, this is the same concept. (G being generator point).

(2K + 4K)G = 6KG

6KG being your ECDSA public key.

2K + 4K = 6K

K3 being your ECDSA private key.
You don't give the pool your private keys. Multisig requires two keys that has no relation.

Yup.

I'm referring to the article that you've linked, which references the research paper for the value.

I can't really find the methodology other than the mention of relating the price and the economic mechanisms doesn't always hold true for something as volatile as Bitcoin where economic decisions are not always as rational as they seem. The paper isn't peer reviewed as well, I'll take that with a pinch of salt. Modelling rate based on historical figures doesn't make any sense either.

The fact that you're using Coinbase pretty much means that your privacy is already compromised. You don't need a block explorer if they're not concerned about transactions that doesn't involve them.

Even if you do, then I can't fathom why using Tor isn't an option. If you are able to search each addresses individually with different Tor routing, then there isn't an issue right?

You're picking at one of the least significant issues out there. The node count is fairly high, even if you only count listening nodes. Why should nodes be compensated? You're running a node and the benefits lies primarily on the user using it, the positive externality is small if you consider the number of nodes out there right now.

By having to pay the thousands of nodes something, you're either making Bitcoin more expensive or Bitcoin to be less secure. What 'little' code update do you propose?

No. If you concern is only about broadcasting transaction, that is why the airgap exists. Your private key doesn't touch the online computer.

The most prominent one is the HTML phishing which poses a security risk at the very least. Versions in the earlier 3.X are intentionally DOSed to try to prevent them from connecting to any servers.

For the JSON RPC attack, I'm guessing if it doesn't have any authentication, then someone can use CORS to call your RPC and get your xpubs as well. Even if there isn't any attacks that are of concern right now, there are outdated modules within Electrum which could allow for exploits as well. Nonetheless, the potential headaches from anything happening with your Electrum or your computer really makes updating a no brainer. There is a plethora of ways to compromise someone's security, directly getting the private key is just one of them.

Mining is already fairly centralized and smaller miners tend to just use a pool for it. It isn't as feasible to be running your own server at home, hosting it in a data center with greater bandwidth and latency is better. Bandwidth requirement does not increase for the mining farm itself then.
Given the fact that connections has increased so much and that the bandwidth has improved as well, doesn't the argument weakens? Miners almost always attempts to connect to each other directly to avoid stale blocks. The lesser hops there are, the lesser chance of stale blocks. The situation of having more stales is less prominent than when Bitcoin didn't have these many optimizations.

Probability increases assuming the blocks has to propagate through several hops though, which is how most forks are formed nowadays, with at least one of the pool being less known. But wouldn't it make sense for some compromise as well?
Depends on the probability of fork occurance. Wouldn't it be more secure primarily because it takes more work to get a confirmation with a 10 minute rather than a 1 minute block interval?

Taproot is implemented with a soft fork. Legacy and normal Segwit is still supported.

There's quite a few security risks with Electrum 3.X and I really can't recommend anyone to be keep using it. Though it is a watch-only wallet, I still consider it more secure to be using one that is newer. Are you still able to connect to any server with 3.0.X?

If you don't make the Blockchain public, then there is no transparency.

Bitcoin is designed as such and the user has to proactively ensure that they're able to break the link or use privacy preserving techniques (mixers, Tor, etc). The responsibility to preserve privacy should lie primarily on the user themselves. Whatever currency that you're using can only do so much to try to preserve the user's privacy. Bitcoin was designed to try to preserve privacy by pseudonymity and that is achieved. Mixers and CoinJoin helps to break the link, which makes whatever links that IRS or the government has established pretty useless. Bitcoin or any other currency can't really help if you're going to associate your transactions to your own identity by sending mail to your own address.

I'm not really sure why we need to incentivise people to run a full node. Full nodes primarily benefits the user that is using it.

Sorry. I meant rate of increase in supply.

That is for the general trend at least. It is impossible to accurately measure the coins that were lost.