Output, not transaction. If a transaction has multiple outputs which belong to you, you are able to spend one without the others.

tl; dr: The target time span between blocks, which for Bitcoin is 10 minutes, is an important design parameter. Since it is difficult to determine the optimal value in advance, it may be desired to have it dynamically set by the market rather than hardcoded - and this is possible.

Introduction. The Bitcoin mining difficulty is adjusted so that a block will be found, on average, once every 10 minutes. This figure appears in Satoshi's whitepaper, but not much motivation is given for this choice. It is a compromise obtained from considering the following points:

Advantages of long time span:
1a. Less time wasted trying to continue an old chain while waiting for new blocks to propagate, which would give attackers an advantage.
2a. Less overhead for transmitting and storing block headers.

Advantages of short time span:
1b. Less variance for miners (and you should care about miners).
2b. Less time merchants need to wait to receive a given level of security of a transaction (there are some subtleties and much confusion about this point, but it's basically correct).

There is no guarantee that the value of 10 minutes is optimal, and some alternative blockchain-based currencies ("alts") have tried their luck with a different target. It is also likely that the optimal value will change over time, so it may be desired not to have it hardcoded, but rather have a system that allows market forces to determine it dynamically. In this post I will propose just such a system.

I will first focus on the scenario that the block reward consists entirely in new generated coins, without any transaction fees, and on the respective advantages 1a and 1b of long and short time spans. The general case will be considered afterwards.

I don't know if the block target time is considered to be a part of the Schelling point of Bitcoin which must never be changed, or if the proposed system is too much trouble to implement now that the wheels are already in motion. At the very least, it could be something to consider for a well-designed alt.

Basics. The network will still have a target hash value such that finding a hash lower than the target would be done once every 10 minutes on average. However, when mining a block, the miner can choose a target hash specific for this block which can be distinct from the network target. As long as the block hash is lower than the specific target, the block is valid. The specific target is part of the hashed block header, so the miner can only choose the target before he starts mining.

Branch selection will be based on the total work contained in the branch, obtained by summing the inverses of the specific targets.

The block's weight will be the ratio between the network target and the specific target. An easy block with a higher target will have less weight. The amount of new generated coins will be the normal block reward multiplied by the weight. A block which is ten times easier to find than a normal block will only give a tenth of the bitcoins as a reward.

Various landmarks which are now triggered by a certain number of blocks, will instead be triggered by a certain total weight. The normal block reward will be halved whenever the total weight reaches a multiple of 210000. A block which crosses the threshold will be rewarded proportionally based on the portion of the weight that rests on either side of the crossover point. This guarantees that the total bitcoins generated remains 21M, and on the same schedule (though with different granularity).

The difficulty (the network target) will be adjusted every 2016 weight units, so that the time to find 2016 weight units is 2 weeks.

If miners in general end up choosing a weight higher/lower than 1, this will have a similar effect as hardcoding a time span longer/shorter than 10 minutes.

Market forces. Choosing a weight different from 1 has no effect on the theoretical expected reward from mining. However, it affects variance and efficiency.

A miner will not want the weight to be too large, as that would mean a smaller chance to get a higher reward, which increases variance. If the default time span is so large that the variance is costly, miners will tend towards choosing a lower weight.

A miner will not want the weight to be too small, since that would increase the chance that it will be rejected. Suppose the average timespan is so short that forking is a matter of course. If two miners find a block at the same time, the one that chose a higher weight will be accepted, because the resulting branch is longer. Thus the higher weight miner will enjoy a higher percentage of accepted blocks and higher average reward, and this will push the market back to an average timespan where conflicts aren't that much of a problem.

The same considerations exist for mining pools too, who for the sake of their users want to minimize both variance and invalid block rate.

All in all, this will allow the market to reach an equilibrium point which strikes a balance between variance and forking.

Attacker manipulation. The incentives of an attacker are different from honest miners. He will not care about the variance in long time spans, and choosing higher weight blocks will make an attack easier. In fact, it can be shown that if the attacker can choose an arbitrarily high weight, any double-spend attempt is guaranteed to succeed eventually, whatever the hashrate of the attacker and the honest network. Being able to choose a very small weight makes Finney attacks easier.

Therefore, some limitation on weight selection will need to be placed. For example, it can be bounded from above and below by some multiple of the mean weight of the recent blocks. This will still allow the market to gradually converge towards a different time span, while preventing an attacker from choosing time spans much higher or lower than the rest of the network.

Future work. The resulting equilibrium may be such that merchants will suffer from needlessly long confirmation times; miners can choose short time spans that while not causing many conflicts, overload the blockchain with numerous headers; and the proportional relationship between block weight and reward is not at all clear for a scenario when transaction fees are significant.

I believe all of these issues can be solved within a reworked framework of the way transaction fees work, which I think is needed anyway. In the future I may write about that in a separate post.

CONTINUED:

Transaction fees. When the transaction fees become significant, the procedure described above loses the direct proportionality between block weight and reward, twisting the incentive structure and favoring shorter blocks. This can be solved by using the continuous version of rollover transaction fees, which pays out transaction fees not to a single block but to several blocks based on their weight. The proportionality is thus approximately reinstated.

If the decay is fairly fast, this still gives a higher reward per weight unit the lighter the block is. This gives Bitcoin users some control of the miners' choice. If the confirmation speed leaves something to be desired due to block times too long, they will typically pay a higher fee to expedite their transactions; if everyone does this, transaction fees become proportionally higher than coin generation, which increases the incentive to mine light blocks which negate the problem.

This effect no longer holds true when the coin generation becomes negligible, in which case transaction fees are the only significant component of the reward, and increase fees does not encourage shorter blocks. Finding a mechanism to allow users to encourage shorter blocks in this case is an open problem. One idea is to not use only an exponentially decaying function, but give the user a choice between functions with a different kurtosis.

Block header upkeep cost. Every block generated creates a burden of the network due to the need of every node, even SPV clients, to download it and store it. Thus the miner should pay for the resources consumed by his block. This can be of the form of a fixed cost deduction from the block reward, which will be added to the long-term fee pool described here. This will prevent miners from choosing very short blocks which overload the network.

Contested transaction fees. Because transaction fees decay, miners could be incentivized to intentionally reject a valid block and try to find their own heavier block, allowing them to collect more fees. This can be solved by the principle that contested transaction fees are deferred - that is, in case of a fork, the fees which the blocks have in common are not paid to either of them, bur rather suspended and added back to the pool until blocks are found with a total weight equal to the current maximum weight. This applies only to fees and not to coinbase. This way there is no incentive to create a fork when you know you will lose the reward you tried to reclaim. This also makes unintentional forks that much more painful, but this will be compensated by the deferred fees that will exist at any time.

The implementation of this could be tricky, and requires among other things that invalid blocks will be considered in the calculation of the block rewards of the valid chain.

It's not theirs either. Here is a June 2011 reference to it, and I doubt it's the first.

We take it into account, occasionally... Even without QC stuff, ECDSA could very well be broken. I wonder what is the proper procedure to handle this - let the first person to build a working ECDSA breaker take all the lost coins? Or, when cracks in ECDSA are found, set a widely publicized expiration date that would force long-term savers to move to a secure address, while keeping truly lost coins lost?

http://en.wikipedia.org/wiki/Utility is a good place to start, as is http://en.wikipedia.org/wiki/Decision_theory. The usage of a logarithmic utility function is just common sense (it basically means that a person worth $100K is as excited to gain $1K as a person worth $1M is to gain $10K) and was suggested as early as by Daniel Bernoulli; the formula given is just a straightforward calculation (second-order Taylor expansion of log combined with neglecting of E[X]^2, then optimizing the resulting function) (I reproduced the calculation from memory and I had a small error which I now fixed).

Since the approximation only deals with small deviations anyway, changing the utility function doesn't materially affect it, but it does change the effective value of T, which corresponds to the risk-aversity.

In general, no matter how risky an investment is and how risk-averse the investor, as long as it has positive expectation, it will be attractive if scaled down enough. Insurance can serve a purpose when it is impossible to scale down the investment (and in some other cases), but simple uninsured pass-through bonds can be scaled down.

Details: Utility is generally considered to be fairly accurately modeled as the logarithm of the total net worth. If the initial net worth is T and the gain from an investment per BTC invested is a random variable X, then the expected gain from investing a is

E[log(T+aX) - log(T)] ~ aE[X]/T - a^2 V[X]/(2T^2)

This is maximized when a = E[X]T/(V[X]). The approximation requires that E[X] is relatively small, so may not be applicable precisely to the problem discussed.

The insurance is a gimmick. Buying X bonds with 25% insurance at Y BTC each is equivalent to buying 0.75X uninsured bonds at (4Y/3 - 32/75) BTC each. This means that, all else being equal, buying X PPT bonds at more than 1.07 BTC each is dominated by investing 0.75X BTC in pirate at the same MPR.

The bonds in general are good for people who can't invest in Pirate at all, or too little to enjoy the higher interest rates; but assuming everyone is rational, the insurance shuffles some numbers around but it ultimately has no effect on who should buy them and what they gain for it.

Edit: Actually, I've neglected the time value of money in this calculation (which I think is fairly insignificant as far as BTCST investments are concerned). A more accurate decomposition is: Buying X bonds with 25% insurance at Y BTC is equivalent to buying 0.75X uninsured bonds at (4Y/3 - 32/(75(1+r))) BTC each and investing 0.32X/(1+r) BTC in 100% insured bonds with a return of r. If there are no other investment opportunities and money has no time value, r=0 and we go back to the previous case.

Then I think a rescan won't be necessary, it should pick up relevant transactions as it downloads the block chain. Reassess the situation when syncing finishes, the final balance shouldn't be affected.

PS a change address is generated whenever you send coins, so if you sent more than 84 times there could be a problem.

Then there shouldn't be any lost coins, though I don't really know if the GUI handles this gracefully. Did you run with -rescan? Do you know if the balance currently displayed is the same as before?

Lest my comments be misinterpreted, I'll clarify I'm not taking a side in this debate.

That's exactly what a person running a ponzi would want you to think.

At what odds? If it's anywhere near 1:1, I think nobody would take that bet. Even for someone who is 100% sure Pirate will default at a uniformly random time between now and Jan 1 2013, investing some amount in his program is an economically sound decision (maybe not legally/ethically) - let alone someone who believes he will not default in this time period, who would rather invest funds in pirate than offer collateral for this bet.

About the USD denomination, that even further complicates things, and you should consider instead hedging against currency risk by extending your short position on Bitcoinica.

The most important thing is the private keys, the wallet file has a buffer of 100 keys so unless you created more than 100 addresses (including change addresses) since the backup you should be good. If you did you could be in a serious problem; wallet backups should be done periodically.

Transaction information can be obtained from the blockchain. It may help to use the -rescan parameter when starting Bitcoin the first time.

Any sending addresses in the address book, and labels you gave to your receiving addresses, which were done after the backup, will be lost.

From a game-theoretical standpoint, zero-sum is identical to fixed-sum.

You are correct that the primary effect is that higher valuation increases the incentive to mine, and hence the total hashrate and network security, and that a common myth is that the primary causality is reversed. This doesn't mean the reverse effect doesn't exist too - at least some people, when making decisions about investment in Bitcoin (both buying bitcoins and taking part in the economy) will want to know that the network is secure, thus improving security with independent means will increase the valuation.

I don't know the current status of that; I don't think it counts as an attack; and yes, we should also avoid changes that make it easier for botnets.


First, I consider p2pool to be a type of pool, and it reduces variance and is in no way centralized.

Second, even a centralized pool can allow miners to have control over blocks, a setup sometimes called "split pools" or "smart miners". The miner composes a block himself, or receives it from an independent party, and credits the pool in the generation transaction; he submits to the pool the Merkle branch of the generation transaction of every share to prove that he works for the pool.

Third, it's not necessary that 3-4 pools will be >50% of the hashrate. There are several ways to keep miners' variance low even with many small pools.

Yes, increasing block frequency would reduce variance. But it will also increase effective network latency (point #7). I'm getting ahead of myself, but I'll hint that the reason I'm making this post now is that I want to talk about block frequency next.

High o and low c does not result in low r. Even in the limiting case o=1, c=0 (which is exponential PPLNS) you can have r whatever you want. r is determined by the ratio between how close c is to 0 and how close o is to 1.

I was trying to make a case for there being a good reason, in general. The specifics should of course be considered on a case-by-case basis.

Unless someone explicitly agrees to follow Crockers' rules, how you say something is as important as what you say.

Can I assume you never said anything wrong in your life, or that you had no problem being humiliated when you did?

tl; dr: The easier it is for honest miners to mine compared to an attacker, the more secure is the Bitcoin network.

This is a point which seems completely banal to me, but if even Bitcoin's lead developer can be confused about it, it deserves a post.

Mining is indeed a zero-sum game for miners. The total amount of bitcoins to be gained by mining is fixed by protocol and by the transaction fees users are willing to pay, and if it's easier for one person to mine, what he gains will come at the expense of other miners.

Mining is not a zero-sum game for Bitcoin, and this is evident if we recall the main reason mining exists, which is to secure the network. The more people are able to mine, the greater the total honest hashrate, which makes it that much harder for an attacker to overtake the blockchain. Also, more miners means more decentralization, and more difficulty in commiting attacks by compromising specific mining entities.

Note that this isn't a one-to-one "helping X GH/s worth of miners join increases the total hashrate by X". The new miners will increase the difficulty, causing some old miners to leave; a new equilibrium will be reached, which has a higher total hashrate than before.

Following up on the "zero-sum game" theme, doesn't making mining easier also mean it will be easier for an attacker? Well, that depends on how exactly we make mining easier. For example, if some change is done that doubles everyone's hashrate, it will apply equally to honest miners and attackers and thus have no effect.

But any change that gives honest miners an advantage over attackers, by addressing difficulties that honest miners are more likely to care about, can increase the total honest hashrate without increasing the hashrate that can be amassed by an attacker at a given expense, thus making the network more secure. Some examples of things that can help honest miners (especially at-home miners) more than they help attackers are:

1. Reduce mining variance. An attacker won't have much relative variance, because he is big enough to carry out an effective attack; and he will not care much about the reward or its variance, since the mining reward isn't his main objective.

2. Make mining technically simpler for various use cases. An attacker isn't going to care about technical difficulty; he will hire the best engineers and do it at scale to reduce the amortized cost. For an at-home miner, even a trivial inconvenience can mean the difference between starting to mine or not.

3. Support mining pools. An attacker isn't going to use pools, because he doesn't need them and because he wants control over the blocks. At-home miners must use some form of pool.

4. Make efficient mining hardware available to the masses (or make the hardware available to the masses efficient for mining). An attacker is possibly going to develop his own ASIC solution to be deployed at scale; smaller miners can't afford this luxury, so they should not be left behind in this arms race.

5. Make it possible to leverage existing resources. An ability to mine on the idle CPU of a computer, or a mining device on a PCIe card which can be added to a PC and utilize existing computing, electrical and physical resources will help at-home miners more than an attacker, who will need to make a dedicated purchase of the entire infrastructure.

6. Offer mining assets such as companies and bonds. These will allow people without the means to physically mine to put more funds into honest mining, while being completely useless to attackers. The issuing entity will need some accountability to make sure that it is not itself an attacker.

7. Reduce network latency. The more time it takes to learn about new blocks found, the more hashes wasted on old blocks. Attackers will not suffer from this, because they mostly mine on their own blocks, which they can be instantly aware of.


This also means that some ways to make mining "easier" can arguably actually help attackers more than honest miners, and thus harm network security. Computation/hashing rental services, which give the renter full control of the contents of the computation, if done at scale, can allow an attacker to make a blitz without investing in a long-term deployment.


So if you want the blockchain - the major technical innovation that separates Bitcoin from anything that predated it - to properly do its job of securing Bitcoin transactions, then you should care about mining, you should care about miners, and you should care about changing the Bitcoin ecosystem (which also includes the core protocol) in ways that are beneficial to the typical miner.

Some of the responses here were quite harsh, and I think your post, as opposed to many similar posts, deserves credit for identifying and addressing some of the issues.

But the point remains. There isn't much of an upside, there is absolutely no problem with coins that are lost. Recycling certainly does hurt many, many ways of using Bitcoin (think for example about Casascius physical bitcoins, or wedding rings with a private key).

More importantly, even if the modification was advantageous at face value (and could be used in an alt), the economics of Bitcoin must never be changed, as that would destroy the Schelling point "the economics of Bitcoin will never be changed" which is the source of the confidence in Bitcoin investments. While more benign than relaxing the 21M cap, destroying bitcoins and creating new ones to replace them is certainly an economic change, and is thus ruled out.

And this is also a good opportunity to point out that the technical means to achieve the economic principles are fair game, and must change as needed if Bitcoin is to succeed.

I wouldn't say that. In the language of the triangle, lowering the dropoff moves you away from the black line and into the blue line; while the black line is characterized by low maturity time, it can still be arbitrarily decreased on the blue line.

The main advantage of using aggressive parameters (high dynamic fee, low leakage) is decreasing the variance of small pools.

Based on the comment 3 posts above yours, it's 5%.

Well, the official name is whatever I call it, so yeah

The full name is "the double geometric method", I originally shortened it to double geom, but I picked up DGM when I saw it used. DGS is "double geometric scoring" (or system?), which is descriptive but I don't support its usage.

Then you need to read up on how transactions work. An input to a transaction is the output of a previous transaction. If you want to send an amount smaller than the output value, you need to send back some to yourself as change.

No, blockexplorer.com reports the transactions as they are.

No, it makes it seem like 0.02 + 0.0005 equals  0.01 + 0.01 + 0.0005.

From an output, not from an address.

The logo is the Lorenz attractor as I stated in the OP, and I see no mention of this. Async labs almost certainly based their logo on the Lorenz attractor; I don't know what is the relation between Async and BFL, but I wouldn't be surprised if BFL independently came up with the idea of using the Lorenz attractor. Even if the BFL logo was inspired or inherited from the Async logo, it was done with full knowledge of what it represents.

Nice. It didn't come up in search because of the underscore.