You can model the timezone of Satoshi if you were to analyze the code commits, forum posting patterns among other things and you'll realize that Satoshi mostly follows a specific sleep schedule. A possibility could be Satoshi turned off their miner as LoyceV has said but it could also be that his PC is just that slow and unstable to find a block. CPU miners were fairly unstable and slow, even for 1 difficulty blocks especially how optimized it was.

Regardless, the nonce of the block is pretty special and follows a specific pattern. Jlopp has a nice writeup here: https://blog.lopp.net/was-satoshi-a-greedy-miner/

You don't have to trust any of us and you definitely shouldn't. Whatever you're going to receive in this thread would be sprinkled with tons of FUD. If you want to get the most objective view, look at BIP102, BIP103, Bitcoin Classic and Bitcoin XT. Those are several of the proposals and softwares that permitted block size increase. In addition, you should see the whole fiasco about the User Activated Soft Fork which is part of the series of events that precipitated the adoption of SegWit.

Segwit was ready, and make no mistake it is still in effect a block size increase indirectly and still increased the TPS of the network.

You would realize that tons of politics were at play and there were tons of disagreement among the key renowned developers and community figures. You would have to skim through the mailing list as well and come to your own conclusion.

If you're using a phone solely for the storing of your coins, you should just get a hardware wallet. That is far safer and more foolproof than using a phone. I avoid using mobile wallets in general because they are often poorly vetted or designed and can have quite a big surface area for attacks. Using a hardware wallet is harder to mess up and provides you with the security at the same time.

It depends. Depends on how your system is designed, certain are cached beyond the shortlived timespan in your RAM. RAM access in OS differs and some are not overwritten properly after use. AES is a good encryption, DES aren't, so that has to be taken into account as well.

Regardless, that would still be a risky assumption to take. Unencrypting the wallet file and any processes that takes place should be accounted for.


It has happened before, and I have no doubt that it would happen again.
Not exactly. Entropy is often misconstrued when talking about the complexity of passwords. Its a term used to measure randomness. This can be flawed when taking into account password dumps, rainbow tables, common password structures, etc.

Miners won't like it. Transactions incur costs, often implicit that falls on the community as a whole, for eg. those who run nodes, those who mines the coin. The former already doesn't receive monetary compensation while the latter has always been receiving it in the form of fees. The cost of moving your coins shouldn't be discounted just because you want to encourage people to move to a new address format. The onus should always be on the user; if you don't want your funds to be lost, move it. We have no obligations whatsoever to encourage you to do so because it serves no benefits for the rest of us.

Also, replay protection is still needed regardless.
That encourages spam. It is unnecessary to implement, adding in the complexity and lowering fees for miners significantly. Having large UTXOs are already discouraged, by having fees proportional to the size. That is not ideal for the network and you'll face significant bottleneck for the rest.

The privacy preserving feature is something to be thought of and worked out when the time comes.

More likely than not, we might have something truly better than Bitcoin when ECDSA finally gets cracked, which is a long time from now.

Generally, entropy doesn't matter with passwords. It is just not feasible to bruteforce passwords in this manner, especially when you need the file as well. Malware will just steal the password.

Android phones and IOS usually operate their apps within their own sandbox which makes it more secure than other OSes in a sense. However, because they are such an attractive target, malwares are often catered to attack the zero days on the platform. Samsung Knox goes a step above the vanilla Android OS and does hardware level isolation and theoretically it should be more secure.

Regardless, I wouldn't consider anything that you're moving around with and having the potential of misplacing as being secure.

Do you have the access logs to your Ubuntu Server? Are you certain that nothing has accessed it, not even via hypervisor or anything similar? Things like these tends to go unnoticed when doing cyber forensics for most. I have my doubts that the generation of your seeds is the problem, I don't see any vulnerabilities in recent times for those wallets that you've listed and they are fairly well vetted unless it is zero day.

I highly doubt that Bitcoin Core would be the issue, other than the fact that RPC functions could be the culprit. That leaves both your server and seed generation to be weak, I'm not aware of any concurrent vulnerability affecting it but it is not maintained at all. Is there any RPC connection visible in your debug.log?

Anyways, it's not over 1000 addresses, a quick look indicates that a good portion of the funds belongs to this: https://blockchair.com/bitcoin/address/bc1qxs3ugdgda5ljt20uuqegljzlq8rnjcxnjrjj6h. Weirdly enough, the amounts being sent to the wallets are regular and around the same size before the attack.

Tons of reasons, controlling their own impulse, keeping it for long term investment, etc. The whole point of a time lock address is to ensure that no one can have access to the coins without waiting until the specified time frame. Private keys are not meant to be sold or traded, it is not wise to purchase any private keys. It would just mean that multiple people will have access to the coins when the time comes and whoever moves the coins first when the timelock expires will get the coins.

The main currency used around the world is still fiat. This would only make sense if the adoption of Bitcoin increases exponentially, such that you can easily use Bitcoin everywhere and in your everyday life. Otherwise, paying salary in Bitcoin would only complicate things and introduce extra steps to get people to convert their Bitcoins into fiat again. This would be just like paying your salary in USD when you're in Europe. No one would appreciate that.

BitPay has a service which does this however.

Nope, indirectly associated. I'm assuming a theory whereby circulation remains constant and all the other factors being invariable, which is often not what happens in real life. Bitcoin gets deflationary, fees increases, etc; Satoshi's rationale on reward halving may very well hold true assuming improved efficiency in mining and a compensation in fees. Reward halving doesn't encourage more miners to join, the fee compensation and the other monetary factors (real cost - reward, etc) are what makes it attractive.

Regardless, discussion about this would be diverging from the issues that is being discussed here. Would be more of an economics question rather than technical.

Network difficulty is not directly associated with reward halving, in fact the hashrate should decrease in theory. Increasing the difficulty has nothing to do with what we are talking about here, unless you're talking about a pre-image attack. For which, a pre-image attack on SHA256 would go beyond speedups on hashrates which would only concern the first pre-image attack. Collisions and second pre-image attack on SHA256 are by far more potent with regards to the security of Bitcoin.

Checksum are used to check for the correctness of your seeds, or addresses, WIF keys, etc. They are included in data where mistyping is prone. Your BIP39 seeds include a checksum as a part of the last word which is used to check if the seed is valid. If it is not, you have typed something wrong in your seed. The same goes for the address, where there is a checksum which tells the user whether they have mistyped anything. This is not foolproof however, there is a chance where you've mistyped something and the checksum still checks out.

Checksums are usually included within the string, where the checksum is usually a hash that corresponds to the first X bytes of data. Since each hash are likely to differ if any of the character in the first X bytes of data are wrong, the checksum is able to tell the correctness of it, but not the position where it is wrong.

Entropy is a part of how you generate your keys and seeds. For an ECDSA keypair, entropy is used to determine the private key and for the BIP39 seeds, entropy are concatenated with the checksum and segmented into blocks of 11 bits, where each block corresponds to a word on the wordlist. Entropy is required for your addresses and seeds to be secure, as they are basically random inputs to ensure that your addresses and seeds is random enough such that no one can feasibly guess your keys.

Take BIP39 seeds for example, if the entropy used is not random enough, the blocks of 11 bits becomes predictable and thereby any adversary would be able to guess those words that you've used for your seed.

OP_CLTV is different from OP_CSV (absolute vs relative). It allows for the locking of Bitcoin to be evaluated either by unix time or block height, the latter for which is up to >9000 years while the former is until 2106.

Eh, that's pretty normal. I've had a lot of block-less days without any blocks when I was mining and I never really had to shift away from the pool. The profits in the long run would be the same anyways, just select one that has the lowest fees. Pools' payout system discourages pool hopping.

The directory is hidden and is only accessible if the Android phone is rooted.

Electrum does not allow for importing of wallet files within the app, IIRC. You have to import the wallet using the seed generated or the private keys that you have.

Most of which are lost, because people couldn't be bothered to have a backup for them. Satoshi is known to have a million Bitcoins at least, and there is probably more than that in terms of non-Satoshi but lost coins. In addition, there are also coins in exposed P2PKH addresses. These could add up to a few millions when the time comes. Of course, these are just vague estimations but that is more than likely to be the case.

Precisely. Giving anyone information on how they store it exposes additional attack vectors that people could exploit if they were to find any weakness with it. Most exchanges would throw different terms like "military grade hardware", "military grade encryption" but they would never tell anyone how it is stored exactly. Even if they were to tell, they could lie about it in order to mislead any adversary and keep their funds safe. Having lesser knowledge of how it is stored gives them extra time and increases the complexity of any attacks.

Hence, any comments on their security model, be it how it is stored, where it is stored, who has access to it, are sensitive information which no one knows and any comments on it should be treated as a speculation.

Actually, still somewhat easy. If you were to simplify it, Bitcoin addresses are merely hashes of script which defines the spending conditions. They are indexed after evaluating each transaction for the script in their output before tabulating and indexing them. If the usecase is big enough, most explorers would index and keep track of them.

Some blockexplorers have indexed them as well: https://blockchair.com/bitcoin/address/d-30b1cfee5f36b0282531ab681452c910.

The actual answer is that no one knows. It is the best interests of exchanges or any major services to keep sensitive details like these secret. I would be rather concerned if anyone were to thoroughly understand how the security of each exchange is designed.

Some exchange store their fundson Multi-Sig, Bitmex being one though they didn't say how the keys are being stored. Coinbase, Gemini, etc all say they hold the majority of the funds offline at different secured facilities on hardware modules and they are not disclosed at all. Any employees working for the exchange, or just any financial institutions in general are required to sign an NDA. If any "ex-employee" were to disclose, they would be getting a nice lawsuit served to them.

Besides, what's the point of them saying? You should take those at face value, after all, most of their claims might not be credible most of the time. The handling of keys and transactions are not verifiable.

Same as the rest of the community, I believe that there will be more versions of Bitcoin, ones with the old P2PK being burned and the ones that are not. I believe that there are merits to both sides of the camp, but I personally stand on burning them. I can understand the dilemma behind this and what your POV is. It'll be quite interesting to how it pans out, pros and cons for both directions.

By the time ECDSA actually gets broken, there might be more than a few million Bitcoins that are vulnerable still (forgotten or lost used P2PKH, just normal P2PK, etc) . A sufficiently long time for transition would be required, though arguably you're right in a sense that it does rob people of what is rightfully theirs. In the worst case scenario, an adversary gets access to the majority of the Bitcoins and wreck havoc in the markets. While in the best case, they get access to only around 1-2 million, ie. 5% of total possible circulation, not accounting for burned ones.

Regardless, we had this conversation quite a while back: https://bitcointalk.org/index.php?topic=5335069.msg56971465#msg56971465. Recalled it from the top of my head, I guess our position on this issue hasn't changed very much throughout the years.