But if the only way to increase inflation is to steal other outputs, I'm sure that less than 51% of miners will allow this. If this is still a concern, let the client track its own coins: if they're stolen, it begins its "verify all transactions" contingency plan. The only other concern here is if miners decide to target known lost coins, but I believe such a cabal to be unsustainable (there are, after all, only so many known lost coins).

Either way, this model still provides much more security than a lite node. It may be useful for merchants and laymen who may not have the time and resources to upgrade Bitcoin often.

That's an interesting standpoint. Taking it a step further, do molecules have a tendency to not destroy others? In other words, are reactive compounds much rarer than inert ones?

I guess (from my limited chemical knowledge) that they are. But then wouldn't the universe become progressively more nonreactive? Maybe I should pay attention when I'm supposed to learn about entropy, because that sounds similar.

</thinking_out_loud>

Either way, this is getting too deep. Let's take the analogy into the other direction: if we find other societies (e.g. aliens), is peace the best solution?

I guess that means that the transactions need to be processed too. The blockchain is already necessary to monitor attacks, so I assume that is present (this is not a lite node). Could this (transaction processing) be done in a reduced fashion?

If I'm not mistaken, every output is a script and a number, not solely a script. The script doesn't need to be processed to retrieve the number. So the only way a miner could trick a node is to act like the inputs are valid, which the client assumes. But this will cause the block to be rejected by other miners, who do preform full verification.

So, could the client simply refuse to process the scripts on all but the Generated transaction, while processing all the numbers?

Nah, that's not how it works. The brain cells are without self-interest themselves, and work only because of chemical interactions. The analogy doesn't even apply.

In case you were wondering, I was joking.

But isn't an individual just a collection of brain cells and their slaves? Maybe each brain cell should seek their own satisfaction. And additionally, each molecule their own.

My bank account is insured.

Why couldn't they check the Generation transaction in this scenario? As long as the outputs sum up correctly, I don't think that the miners can successfully conspire.

I guess my point wasn't clear. SUPPLY is not changed (it is constant). However, DEMAND changes. This follows from the point you make:
If I need 600 BTC for whatever reason, I must provide a service or commodity to gain the 600 BTC from somebody else. If the difficulty is too high, I will not be as inclined to provide the "Mining" service. I must provide another service or a commodity (maybe another currency) to gain my BTC. This means that I am more inclined to purchase BTC with another currency, driving the demand for that market up.

This is better illustrated by a direct logical deduction. If one decides to bump the difficulty up to twice its value instantly (ignoring anything that may have caused this), many people would be forced to "buy rather than mine".

This is an effect of an open (non-closed) system: a decrease in demand for one industry increases the demand for others. Effectively:

Because mining doesn't directly affect the price (as you stated), the decrease in demand for mining does not decrease the price. Therefore, the price is increased.

A CPI is computed by taking the change in the value of BTC when compared to a basket of commodities, to measure the net inflation that the consumer takes. These commodities are divided into categories, so one can see the inflation rate of BTC compared to those categories. Would such an index be useful for Bitcoin now, or is it much too early?

I understand that many merchants price their goods in USD that is converted to a BTC price in real-time, so the Bitcoin CPI may resemble the USD CPI for a while yet. But I do see some utility for it, because some goods are priced in BTC directly and others may be based off other currencies. What do you think?

Sorry if this isn't the right section, please notify me if it isn't. If you happen to be a mod, please move it for me instead.

Mining is an industry, and they earn profit from their work just like any other. If their profit decreases, especially if down to the point that it is below production costs, deflation will occur. Check this page for a more in-depth theory.

This isn't nonsense, it's a valid effect and will continue to be one until mining becomes a negligible industry.

Increased processing power provably increases Bitcoin value. There are many methods of obtaining Bitcoin, and one method is mining. With a higher processing power, and eventually a higher difficulty, this method decreases in effectiveness. The net result is an increase of Bitcoin value.

This was the conclusion that coined the term "difficulty drives price", which is a fundamental principal of Bitcoin's market. However, although its converse principle "price drives difficulty" is expected to remain useful, DDP is expected to decrease in strength as the mining industry becomes relatively smaller compared to the rest of the Bitcoin economy.

The "image based" BTC can be emulated by using combining characters: B⃦.


The symbol: $ is often universally used to represent money, even when a dollar or peso is not the official currency. For example: earning $. B$ to represent Bitcoin money can also be used as an alternative.

Is it legal tender?

The thread title here may sound unrealistic, but I believe this necessary for future Bitcoin adoption.

Currently, the client checks a lot. It ensures the blocks are under 10 MB. It has complex rules about what timestamps for blocks are legal and what timestamps are not. It even tries to make sure the transactions within the block are all correct. (correct me if I'm wrong about any of these)

These checks, and undoubtedly more, are absolutely unnecessary. As long as the miners make sure to follow the correct rules, the client should automatically follow the majority of the network. In fact, these checks are bad: they make changes that will inevitably be needed in the future require hard forks. This is a problem because of two reasons: 1), the client will eventually reject blocks over 10 MB once we need them (needing a hard fork), and 2), the client will reject new types of transactions that it doesn't understand (also needing a hard fork).

Of course, the client needs to make sure it isn't being fed a completely bogus blockchain. Therefore, the client does still need to check the block header's hash and the Generation transaction, as well as listing new blocks as unknown until they are confirmed by 2+ confirmations (by which time the client displays the standard "n confirmations" starting with the block. This should prevent any additional wait times (3 confirmations by most standards), avoid a bogus view of the blockchain, and maintain the trust-free nature of a full node.

There are some issues with this, however. One in particular is the improved utility of a 51% attack. Rather than simply a double-spend opportunity, the attacker might fake some transactions (since the client no longer processes the scripts) and downright steal in the minds of the client. This is definitely a major problem, so I propose the following:

• If the client finds an abnormally large amount of reorgs, it begins checking the blocks (this code is included in bitcoind, so it would not be extra bloat).
• If it finds issues with the blocks, it will compare its version with the median version of its peers. If this median version is much higher than its, the client will disable all functionality and call for an upgrade (this can be manually overridden).
• If it believes that it is up to date, it displays a warning that the network may be getting attacked and begins applying strong checks to blocks. At this point, all transaction-accepting functionality is disabled (because double-spends may be in progress). This can be both manually overridden and automatically overridden simply by waiting a few blocks.

Another major issue is the DOS attack caused by an attacker isolating the client by forcing it to connect to the attacker's version of the network and only the attacker's version. This is called a quarantine, and already has disastrous effects. However, these effects are all the worse when the client is not performing verification, as it, along with many things, will give away the fact that it is quarantined. This issue is compounded because the attacker's peers can trick the client into thinking that it is up to date. In this situation, little remedy exists, but there is one giveaway: a comparatively slow hashrate.

Unfortunately, the network does tend to fluctuate and a slowing of hashrate may not be easily exploited. However, unless the attacker also happens to have a large hashrate, the client can assume that something is wrong if blocks are being found for a period of time slower than an hour per block. Because it is still verifying difficulty and headers (this is necessary), it can launch a warning to be handled by its parent that it may be isolated.

At this point, the client will begin verifying blocks again. If it discovers inconsistencies, this is a definite sign of an outdated client that is under attack. It may elevate the warning to a forced shutdown and an upgrade notice, only capable of being overridden manually.

There are likely countless issues with this approach that my non-technical mind has failed to enumerate, and I do not suggest this be immediately implemented. However, of course after extensive theory and testing, it may be an excellent improvement for the network. I would like to note that this patch not only does not require a hard fork (old clients do not need to upgrade), but also prevents most sources of hard forks in the future. Hard forks are known to cause chaos, and a solution to the problem is needed (but not urgent). Miners will, of course, need to react to hard forks still; however, in this changing atmosphere from "everyone's a miner" to "mining is a profession", it may be time to stop treating clients like miners.

Notice this.

The bar represents the "open" (first trade that time period) and "close" (last trade that time period). The top line represents the "high" (highest-priced trade that time period), and the bottom line represents the "low" (lowest-priced trade that time period).

Hope this helps.

But it affects the prevalence of the moved thread. The redirect is on the first page of the original board, and points to the thread.

You must have included the USD values too then; that would explain the discrepancy. Since the USD value fluctuates, I would suggest excluding them.

Additionally, since some paybacks have occurred, I would write the value at 2211.07786728 (the one I used at my thread).