You seem to have some problem understanding the concept of transaction volume and the 'outflow' as described. Transaction volume and withdrawal is completely different concept. One involves buying and selling Bitcoins at specific prices and one doesn't involve any buying or selling Bitcoins.

Transaction volume has frequently spike but it depends on what's your candle frequency to determine the total amount transacted during that period of time.

If you are not importing any wallet.dat or private keys in the future, pruning is an option for you.

If possible, you can try transferring the entire data directory folder from this computer to the one that you're planning to run. By doing so, you can save on the time taken to synchronize the blockchain all over again. Just copy the entire folder and move it to another computer.

Your idea isn't new there are sites that can already help their user to embed messages into the Blockchain.

It is not cheap however. Transaction fees are fairly huge and even for 1 KB of data, it'll take up to 10K satoshis. Each transaction can have up to 80bytes of arbitrary data in the form of OP_return. If you were to split the file, it'll take quite a few transactions which will inflate your costs significantly regardless.

You're mistaken. 14,600 Bitcoins were withdrawn from Coinbase and this is a cumulation of all of the users that made a withdrawal from Coinbase within that timeframe.

The coins could've been bought by thousands of users and withdrawn by them from weeks, months or years ago. It is not a single entity.

You can buy a fraction of a Bitcoin with a fraction of the thousands that you would've spent for an entire Bitcoin.

In 2012-ish faucets were giving whole Bitcoins but that doesn't exist anymore. If any sites tells you that, its probably too good to be true.

It won't. Trust me, it's just terribly inefficient.

---

I think except for one or two well rounded response, none of them specifically answers the problem as to why switching to another algorithm will not work. Bitcoin's mining industry is huge and the ASICs being used is not cheap at all. Any attempts to change Bitcoin into a PoS will undoubtedly be met with opposition from all of the miners. Proof of work, as the name suggests entails that work is being done during the mining process. This means that effectively, mining is a way to give up certain resources in return for compensation in Bitcoins. In this case, the resources that is continuously being used up is the energy consumed by mining. This ensures that if any attackers were to attack Bitcoin, they need to have sufficient resources and thus potentially resulting in a largely negative ROI after the attack.

PoS is fundamentally flawed.

Whatever the majority of the network says doesn't matter at all. BIP is used to propose changes with detailed technical outlines and gives the opportunity for others to critique and refine the proposal as well. That is why you have various stages of drafting, finalizing, etc. The code merges are not limited by the people that opposes it, if so then Segwit would have never been included at all. Miners showed little support and there was an obvious rift that formed in the process.
Miners do not need to adopt the changes. If the nodes want to enforce the rules, the miners either follow or just continue mining on their own fork without the included change. That being said, it is not that miners are not important but they're far from the main stakeholders in issues like this where the community would be affected as well. Mining algorithm will not change, block intervals need not change either.

Not necessary as Bitcointalk already offers a whole section for it and not a lot of people actually discuss about wallets other than the occasional posts seeking help.

The use of address staking on Bitcointalk is only for the event that you have to prove that you're still in control of the account.
Staking an address means that the owner should be responsible for their own address and keeps it secure. You don't have to send Bitcoins to anywhere, we don't care  (rather, should not care) whether you own any Bitcoins or any altcoins. Sending sats periodically would be expensive and just spawns a bunch of practically useless outputs.

If someone wants to make an altcoins, it would take more than modifying the block generation parameters. Implementing a new magic bytes and dns seeds or nodes would be necessary as well for them to be connected to each other.

If you're able to modify a client that way and people actually use it, that is how BCH is spawned (albeit with quite some modification).

Probably. Does any wallet still use that format right now?

Timestamp can help to a certain extent but the proper use of signed message is to have a clear purpose being outlined within the message itself by the user. When I've signed message in the past, I've tried my best to make it as unambiguous as possible to prevent someone else from using it. Timestamp can serve to prevent misuse in the further future but making the message valid for a certain purpose would solve the problem in its entirety.

Yes.
Your funds are not stored in the wallet. Your private keys to the addresses are what makes them spendable for you. As long as you're able to control your private keys (or your seeds), you are able to control the funds. As for the interruption of outgoing transactions, if it crashes before it gets broadcasted, then you will have to create another transaction again; it'll be like as if the transaction has never been made. If you have already pressed broadcast and it was done successfully, your transaction will show up as per normal.

Nope. Transaction labels, payment request, address labels, etc are all stored within the wallet file locally, they cannot be restored using the seeds only. It is important to note that while you'll be able to restore your addresses with the seeds alone, you need to have a backup of the wallet file if you are using Lightning Network and have an open channel.

It is not. Your full node should have the code that enforces the specific parameters pertaining to Bitcoin's rules. You can verify that you are infact enforcing the 21 million rule by checking the rewards halving, difficulty re targeting and block rewards within the code.

It is easy to change the parameters, whether anyone wants to follow your fork is an entirely different issue.
They don't. Seems absurd that you think Bitcoin is within a control of any single entity and is still surviving at this point.

If you were to modify your Bitcoin Core with a different block interval, different block rewards or halving, you'll effectively change the total possible coins generated. This would only apply for those that is running the client with the same modification as you. So no, anyone can change the limit but it won't be followed. It is already happening with the altcoins that are forked from Bitcoin. The consensus that you've mentioned effectively means that those who runs that modification consider theirs as 'Bitcoin'.

As with the limit of 21 million, it'll probably not be called Bitcoin because there really isn't any real reason for it to be changed. The original Bitcoin should still have 21 million as its limit.

Keyword is consensus.

When Bitcoin transactions are made, they are not sent to another central authority but to a Bitcoin node[1]. Due to this, each node will see a transaction at a different timing. As such node A may see it first while Node B can take a few seconds (say 5s) for it to be finally relayed to it(TX A). In this short 5s, since node B hasn't seen the transaction yet, it allows the attacker to spend another transaction and this time its a different transaction (TX B) that spends the same inputs but the outputs have different spending requirements (or to be sent to different address). The problem now is that since, 50% of the network has seen TX A but not TX B and vice versa. Essentially, they cannot agree on the same transaction that is relayed first. To both, TX A is first seen by half and TX B is seen by the other half and both think that they saw it first. Since you would very much rather not trust what another node says, there is a fairly significant deviation from the unix time for most of the nodes and thus the time received by each node cannot be taken as is. Nodes are independent entities that do not trust each other.

What mining essentially does is to ensure consensus by making everyone follow the same set of Blockchain with the same set of transactions. The disagreements are now solved by this common Blockchain that is recognized by all of the nodes as valid. By enforcing the rule that the Blockchain with the longest PoW is valid, you essentially makes it such that for someone to alter the Blockchain, they have to expend resources to make an alternative chain with a different transaction at that point to make nodes accept it as valid[2]. Since it is more expensive for an attacker to reverse a transaction than to just mine with the honest miners, the game theory makes it such that people are disincentivized to attack.


So for example, TX A is included in the Blockchain at Block 10 and the current Block height is 20. The attacker will create another blockchain with a block that includes TX B in Block 10 and attempt to mine 11 blocks after that. As a result, the attacker has to expend additional resources just to outpace the network by at least one block. Such attacks won't usually go unnoticed and would probably cause a price crash which makes this attack much more unprofitable.


[1] Full node being defined as a client that validates transactions and blocks and enforcing protocol rules in the process, usually running Bitcoin Core or similar implementations.

[2] See 51% attack.

Do you consider people who buy Bitcoins as a speculative investment with the intent to hold it for as long as possible, Bitcoin users? They don't use Bitcoin but only hold it.

If you don't consider that, then the adoption is not significant still. As you can probably see, the fees makes normal transaction expensive and LN is not getting adopted by most of the merchants.

It is not a fee per se but it is a restriction of the transaction fees.

1sat/byte wasn't the minimum fee in the past, free transactions were possible. As long as your transaction cannot meet the criteria of a free transaction, there must be a minimum fee for the transactions to be relayed by the nodes with default parameters. Since it's defined in the default settings, changing it by the owner would also result in some transactions being accepted (if decreased) or some transactions being rejected (if increased). This is specific to individual nodes but the 1sat/vbyte is assumed to be adopted by most of the nodes on the network and thus it is the minimum fee for a good propagation.

Doesn't most credit cards give you the option to settle your payments online? Cashless society is a thing nowadays.
If you see Bitcoin as a speculative currency that can spike in value at any time, it would never go mainstream. No one would use a volatile currency. Trading is *NOT* easy, you're most likely going to lose money unless you have experience and is able to commit a lot of time to it.
Fast? As in 10 minutes or more if your fees are low 'fast'?

---

Every single point that you've mentioned so far is exactly why governments don't want people to adopt Bitcoin. It would be way easier to evade taxes as well as to launder money. If you think that any nations are willingly adopting Bitcoin, you're completely wrong. It's far from being accepted as a legal tender.

Other than that, there are far more technological limitations that inhibits the growth of Bitcoin. How many users can realistically use Bitcoin, if they only make a single transaction a week? As much as I support Bitcoin, there are obviously shortcomings that has to be addressed (or not) which would make it less desirable for governments or normal users to adopt it.

Signing the same message results in the same signature, provided that the r value is deterministic. Even if it's not, it is fine as long as the r value is not reused. I don't think signing the same message would expose you to any risk.

I assume you got the information from the research papers?

It was pretty outdated and that is probably not the case anymore. You no longer have to send the whole block over to the peers with compact block, you're at most sending the primary data concerning the block and only send the transactions that are requested by your peers. While there will still be some delay, you can't measure the mean delay and take it as it is. Some nodes are bound to be more well connected than others and skew the results.

Bitcoin is popular, the rate at which (unconfirmed) transactions are being made is much more than the actual capacity of the network in terms of the transactions that can be confirmed. Transaction volume is currently a technical limitations, by the concept of weight units and making it more popular will not help. So if you want to tackle the people trying to bash Bitcoin by drawing comparisons from carbon footprint per transactions, the argument would be to solve the transaction capacity problem instead. I'm sure the profitability of mining would increase with more fees or adoption?

Proving that Bitcoin's utility outweighs its cost is far more important than saying its environmental damage is unsubstantial.