You're actually looking to bruteforce about 2^160 instead of 2^256-1, as there are a theoretical 2^96 private keys to the same address due to the address (v1) being encoded in RIPEMD160.

Even if you generate a trillion keys per second, you'll take about 4.6343913e+27 years to hit 10% of that. You can calculate how long it takes at various speeds and you'll find that it'll take quite a while still. If your keys were generated in a non-random manner, then it would be trivial for someone to compromise your address as the entropy is significantly lower.

I know but there is nothing stopping them from mining on your "censorship-free" chain as well and thereby censoring your new fork. As with everything that Bitcoin has done so far, any algorithm shift cannot take place overnight. I really wasn't implying that it would be done on a moments notice. Even a simple soft fork requires miners signaling which can take months, or even a year .

I would think that intentionally excluding blocks mined by specific miners would be far more dangerous. In the first place, identifying the blocks mined by them would be a difficult task if they remove any identification of it in the Coinbase. Reaching a consensus on which of the unidentified block to be excluded from the main chain would also be difficult. Miners orphaning blocks would also result in far lesser network security and possibly have to ensure that everyone waits for a few more confirmations, just like 2015's SPV mining.

A paper wallet has quite a broad definition and I would think that storing the important information which gives you access to the private keys or a set of private keys would be considered a paper wallet as well. If you're using a BIP39 compliant wallet (or any other wallet which provides a mnemonic), then there is really no reason for you to be using an electronic medium to be storing the wallet files or the seeds, unless you're looking to store the stuff that isn't covered by the seed (labels, request invoices, etc). The data loss on a paper would be far more obvious than on a USB drive, for which you won't know until you open it.

Storing a backup of the wallet on a USB flash drive doesn't necessarily make it a "flash drive wallet" or rather I've never really seen anyone calling it that.

So, we'll be more concerned about the security and the storage medium doesn't really matter as long as it is stored securely and has multiple redundancies. You'll be more concerned about generating the keys securely, which is needed no matter how you backup your wallet. You can do so by making your USB drive into a bootable USB, boot into it and use it to generate a wallet. The benefit of doing so is that you're able to achieve a somewhat of an "airgapped" setup though the environment may not always be as sanitized as you would like it to be. You can, however sign the transactions on it and is arguably more important than trying to determine what kind of terms should you use to describe a backup.

-- I personally don't necessarily consider a paper backup as a wallet. It serves its purpose as a backup but it doesn't function like a normal Bitcoin wallet with all the features but the terminology has more or less been ingrained and there is little point in changing it. Could see an argument if you define a wallet as something that store your private keys, then the terminology isn't wrong.

Also, paper "wallets" may not necessarily be better than your normal wallets. It all boils down to how you generate it.

This is too dangerous to be executed so the former is probably the only thing that should happen. I'd assume a change from SHA256D to something else, there isn't anything preventing them from mining on the new chain either.

Most block explorers do not classify the blocks mined by Marathon pool yet. You would have to look at the hashrate of those in the unknown instead. The problem with having a small amount of hashrate is that you're subjected to far more variance than others and you have to wait quite a while for it to be considered accurate at all.

They're also still in the process of deploying, AFAIK.

Right, I think there were several mining pools with specific preferences for transactions and this is a similar case as well but with a far worse motives. This is more of a concern than what it appears to be.

With MARA's compliance to government rules, it also means that other mining pools within their respective jurisdiction could possibly be forced to comply with their own set of rules as well and that is not limited to censorship. If there isn't any repercussions to their actions, then we could possibly see more mining pools adopting such measures or worse still, having the farms come after such regulations as well. Once 51% of the network comes under said regulations, something needs to be done urgently. Hopefully, that doesn't happen but it is still a possibility.

2FA is only secure if the initial setup was done in a secure environment. Most TOTP requires the secret during the activation of the 2FA to be secure. Coinbase vault is only secure if you are able to keep all of the accounts involved in the authentication secure. I don't think the funds are insured if it gets compromised due to the user's incompetency either, CMIIW.

Of course, this also means that you'll inevitably lose a lot of privacy when you're relying on a third party for the security of your funds. Hardware wallets or any airgapped wallets would be far more secure than trusting a third party, insured or not. Being in the sole control of your own funds would be a far better idea either way. I find HW wallets easy enough to use unless you're absolutely illiterate when it comes to computers. I also find the 48 hours waiting period quite ridiculous.

Nothing new. The miners have always been able to do so and perhaps covertly by outright excluding certain types of transactions or certain transactions associated with nefarious activity.

If anything it proves that some pools are able to actively censor transactions at will. It will unlikely achieve anything beyond delaying confirmations by a block at most, given their fairly small network hashrate. Miners would probably not want to mine in a pools with censorship measures anyways, unless they support it too.

Yeah. I get your point, even from the first analogy. There would definitely be a certain degree of collateral damage. Just to provide a more thorough discussion; I'm only as qualified to give my own opinions but nothing that technical or something that evaluates all of the variables. Here's a discussion that I once participated (closely followed rather) and pretty much conveys my take on this issue: https://bitcointalk.org/index.php?topic=1469099.0.

I don't think the scale of that would be to the tune of 2 million Bitcoins. Of course you should not remotely brick any device, that is absurd and absolutely immoral. I also don't think the million(?) Bitcoins that Satoshi holds (and presumably never be circulated again) would be in any hardware wallets or generated by it. It is safe to assume that most users do still have access to their hardware wallets and that is up to them to move their own coins, so I agree on the HW wallet scenario with you. I find the QC issue something that is more complex than this and no change (CMIIW) would save ECDSA keys from being vulnerable. My idea would be to have the network switch to a new algorithm and plan a fairly long road map to completely deprecate those ECDSA bound keys. Something like this could be planned when QCs capable of doing this feasibly (and also cost effectively) is on the horizon (probably 10-20 years before), well of course in the meantime convince people to switch to QC resistant signatures by discouraging them from using ECDSA keys.

Of course, violating that very rule of Bitcoin sounds completely absurd, I'll be very honest with you. I maintain that burning them is still a possibility as the impact could possibly hurt Bitcoin economically and IMO both of them have valid points.


You do. I respect both sides of the camp, that is why I believe that it is a moral dilemma.

For the record: https://www.reddit.com/r/Bitcoin/comments/4isxjr/petition_to_protect_satoshis_coins/d30we6f/.

It is definitely an unpopular opinion and I rest my case.

You can't create coins out of thin air.
They run different algorithms. Altcoins are worth nothing at the start and they are usually not very well known or used so there is really nothing to gain by attacking the coin with a 51% attack to reverse transactions. The attacker would however be wasting their time trying to do so and would rather just mine a profitable or well-known coin or just mine legitimately.

I doubt they will be able to obtain a proportion that high under their purview, but yeah never really know.

51% attacks would definitely have far more repercussions than simple censorship. Reorganizing and opting out blocks that they don't like probably won't sit well with most people, more so than censorship within their blocks. If they're smart, they would either choose another pool or just sell their ASICs right away.

Yes, censorship and yes.
Yes. If there ever comes a day where the entire network is under regulatory control (if I may add, IMO highly implausible), you can't mix your coins if it doesn't get confirmed in the first place.

It isn't wrong to be talking about the reference implementations though. There isn't any reason for people to be messing with their default mempool size and thus it would be safe to assume that most people which runs the reference client (Bitcoin Core) do not change the various settings that doesn't directly affect them (minmempoolfee, minrelayfee, mempoolsize). Miners probably don't run the reference implementation but if a user creates a transaction after it gets dropped, it would probably have a higher fee and miners would definitely want that transaction to be relayed to them.

While the mempool is unique and specific to each node, your best and most accurate assumption would be based on the typical default behavior of the majority.

Hmm, then I guess though we do have agreements on most issues, we'll be on the opposite sides regarding this. My take is that the unusual circumstances of this warrants the need to violate certain tenets of Bitcoin, for the betterment of the community at the very least.

Would it be possible for it to be implemented in a trustless manner on the protocol level. Doing something like this requires the user to expose their seeds and subsequently the private keys to someone, it wouldn't work if it is to be implemented on the network.

Really? I saw estimates that they're 30% of the hashrate coming from China. XinJiang's climate isn't that terrible, it still has a seasonal weather and certain parts of it are still fairly cool.

Cooling probably isn't the main priority nor do they really care. Paying extra on cooling is mostly redundant, you get fairly marginal benefits from overclocking them anyways. Ambient temperature delta is not that substantial to warrant additional cooling, if you consider the cost of installing them.

Are they exempted from the tariffs? The cost to ship the ASICs to the States would definitely be more substantial than having to sell it locally. If the profit margin makes sense, then there isn't any reason to not sell them.

Indeed, its a moral dilemma but either of the solution will make sense.

However, if it reaches that point; it gets easy enough to attack ECDSA within a reasonable period of time and with a good cost/benefit ratio , your coins would be stolen anyways. Either you prevent people from stealing Bitcoins or you allow people to steal those Bitcoins and potentially ruin Bitcoin as a whole, eitherways the Bitcoins would probably be stolen/made inaccessible somewhere in the future. Is Bitcoin still really worth X, if 2 million coins (potentially more as we near that phase) can be siphoned from those addresses at will?  Moving to a quantum-resistant algorithm can be done years before it becomes feasible, thus giving those people a few years to recover those coins before finally switching to that algorithm completely. Great thing is: you can choose to support either of this forks in the future and choose which side you would side on.

IMO, it doesn't really reflect anything negative on Bitcoin. Locking those coins probably doesn't benefit anyone and the issue at hand is quite obvious, any decision made can be quite justifiable.

Most wallets allows you to remove the transaction and thus avoiding any rebroadcast. Doing so will not prevent someone else from rebroadcasting that TX for you.
Not really stuck per se. Just that any "conflicting" transactions will have poor propagation if it doesn't signal RBF and meet the RBF requirement. Even if there is a poor propagation, there is still a chance for miners to be able to see your transaction if the propagation just so happens that it reaches the miners. The nodes are just intermediaries which increases the chances of a good propagation.

If you want to have any privacy, Electrum is not the wallet to use. The nature of Electrum will leak privacy and Tor only obfuscates the IPs but will still result in the addresses still being linked to each other. The Tor feature would probably be better to circumvent any internet restrictions instead of privacy.

You need a coordinator, which is what Wasabi has.

If you want privacy or anything like it, don't use Electrum. There is nothing that preserves or attempts to preserve your privacy to any significant extent included in Electrum.

No doubt that it would be equally easy to find something that displays in the actual decimals but my node returns the values as it is: http://163.172.57.208/getmempoolinfo.txt.

Feel free to refer to that if needed, it is running at default settings as well.

Anyone can rebroadcast the transaction as long as they have the raw transaction (which is something every node has once it is propagated). But yes, that is basically the reason why.

Your wallet is not the only one that can rebroadcast the transaction. Anyone with your raw transaction will be able to do so and that includes your recipient as well.

There is really no guarantee that your transaction will ever be drop due to the fact that anyone can rebroadcast your transaction at their will. That is why we normally use opt-in RBF to replace the transaction if it gets unconfirmed for far too long. Some wallets don't check the mempool to see if your transaction has reached its expiry, violated the min fee, etc. In those cases, the transaction can very well remain in your wallet as unconfirmed even when the majority of the network has dropped it.

You might want to consider using Tails for a far easier setup.

Some software that you might use would probably not be open source. If you're using it for a single purpose only, then its probably quite possible to only install things that are open source on it. It really doesn't mean much if you don't verify it and compile yourself; there were plenty of instances where supply chain attacks compromised well known programs and installed their own backdoor into it. Whenever possible, minimize the applications that you're using on the computer.

Eavesdropping on your network is possible, whether you're using WiFi or not. Fact is, most sites uses TLS which really just negates the risk. If you want to protect your funds, just get an airgapped wallet or a hardware wallet. Maintaining security of any device that is connected to the internet is a tedious task.