Topic: Get rid of "difficulty" and maintain a constant rate. (Read 19925 times)

I agree with you, since the difficulty comes from the system itself, constant rate will be determine on how many computers are there in the system itself and how will the network works on that matter.

Notice that you can say the same thing about all speculative buying.  Speculators perform the valuable function of finding market prices which, ideally, reflect economic realities.

Currencies need market prices which reflect economic realities, too - economic realities being the present and expected future degree of usage of the currency.

Bitcoiner, I'll post up a reply tomorrow (it's late here), but I've covered some of the points in the other thread. To summarise in one sentence, fluctuations will always happen in a free market, but restricting supply when demand is growing will not help matters.

As I said before, if you want Bitcoins to behave like digital commodities, that's fine. It may not make it the most stable currency though, which is surely what most people want from their ideal money.

[A bit of a tangent - BTW, this is also why a basket of commodities is often said to be better than a single commodity, as backing for money - they all fluctuate, but the hope is, overall they will be relatively stable, with some increasing in supply as demand dictates (like grain, drinking water etc). I have sympathy for that argument too, for similar reasons to the above.]

An electronic currency such as bitcoin is a poor candidate for stable value. Because bitcoins don't have inherent value, they work well in a system where they have a relatively stable price in the short term and can be transmitted easily and reliably, but in the long term can fluctuate in either direction to meet supply and demand. A vitally necessary commodity such as water works much better as having a constant value. The value may somewhat shift during conflicts or when new ways of producing it become prevalent, but in comparison to something like Bitcoin, it's value will be retained very well over time. There you have it. You should invest in companies that provide clean water, buy a water tower or buy and sell bottled water.

How does it make business and personal planning easier?


Again, why? It's not enough to say "we should do this because we should."


Ok, I'm glad to see that we see eye to eye about CPI and related measures. However, first, how does maintaining a Bitcoin/user ratio maintain price stability, and second, why is it more desirable than a fixed supply?


He's not made wealthier for doing nothing. He's made wealthier for making the decision to hold Bitcoins in expectation of increasing demand. This is not "doing nothing". At every moment he must make a decision, "Should I continue to hold on to my Bitcoins? Or are my needs and purposes better served by spending them in exchange for something else?"

There is also no guarantee that he will be made wealthier. If too many people hoard, then it will be hard to buy Bitcoins, which means that less people will use Bitcoins, which means that the value of Bitcoins will go down, which means that the hoarders ultimately lose out. The value of Bitcoin is not set in stone; it is determined by what people are willing to exchange for it. This is a self-correcting equilibrium.



Ok, now we have a metric. You are proposing that the ratio of Bitcoins to users should remain constant. Why would this be superior to the current system? How would you determine the # of users? How would you distribute the coins?


I can't read your mind; I'm sure you are convinced that what you are proposing is a great idea, but you need to formulate this in writing. You make statements such as "Bitcoins will be the best money if the supply flexes with the user base", but that doesn't actually explain anything to me. You are telling me what you think, but not why you think that way.

If the value crashes because people speculated and drove the value too high, then what's wrong with that? That's how things should work. Would you prefer that oil prices still be near $200 a barrel? Some speculators lost out, again, so what?

"If you just want them to become a digital commodity, then expect there to be swings in demand and value, which would make it less preferable as money."

How would fixing it to the # of users alleviate this, and how could we accurately measure this? Why are swings in demand and value a bad thing? If anything, they are how a market, through the collective actions of individual players, allocates capital most efficiently. This is based on the axiom that every trade is made in order to make each individual player better off. If Bitcoins rise and fall in value, there are good reasons for it, and we should not try to "hide" this or fight against it.

The point is to retain the same value. With a limited supply, but growing demand, each coin is going to be worth more. Companies, and individuals, want to know that 1 Bitcoin will be worth roughly* the same now as in many years to come. This makes business and personal planning easier.

If the global population was steady and everybody used Bitcoins, having a steady supply makes sense. This isn't where we are though - we have a growing Bitcoin user base, which needs more Bitcoins to match this.

* Don't mistake this to be some CPI, price index type tracking (like central banks have attempted over the last decades) - this is just about total coin and user quantities. The reason price index tracking is flawed, is that it is trying to measure the near impossible, because peoples' propensity to spend or save changes all the time. However, it is simple to consider why price stability is important (future planning) and it also follows that more Bitcoin users fighting for a constant Bitcoin supply is going to affect the price (think supply/demand).


In keeping 1 Bitcoin worth roughly the same 1, 5 or 10 years later, to help future planning (and therefore, business/savings/security etc) as mentioned above. If you have a growing Bitcoin user base, but a fixed Bitcoin supply, 1 Bitcoin will be worth more YoY. The holder of the Bitcoin would be made more wealthy from doing nothing. This isn't a great basis for a vibrant economy.

The real kicker? The only way demand will grow in the above scenario, will be if the newcomer thinks that there will be someone coming in after him (or they have just assumed 'prices only go up', perhaps because 'there are only so many bitcoins out there'). Classic pyramid/bubble stuff.


B = Bitcoins
U = Bitcoin users

Inflation = B/U

In other words, the number of bitcoins should be proportionate to the number of bitcoin users.


It's why I suggested there may be an argument. I'm fairly certain that the number of Bitcoin users would be the better metric. However, the swarm would surely know how many transactions were taking place, should this be a useful metric.

[/quote]

Just think it through. I'm sure there are papers on this, but it's just a logical chain of thought - new users competing for existing coins will create additional demand, per coin. Either new users simply won't bother to use Bitcoins or they'll buy in, hoping the price will continue to rise... until one day it doesn't and the value crashes.

If you want Bitcoins to be the best money, then the supply needs to flex with the user base (demand). If you just want them to become a digital commodity, then expect there to be swings in demand and value, which would make it less preferable as money.

Why would we want to retain a steady, neutral value of Bitcoins? This would mean we would artificially decrease the value of each Bitcoin when more of them were demanded, and artificially increase the value of each Bitcoin when less of them were demanded. This seems completely inverse to what supply & demand is telling you.


Ideal in which sense?


How is 0% inflation defined?


GDP is a poor and unreliable indicator. How would you track the number and value of transactions taking place? How would you quantify non-monetary aspects of the transaction, that can only be measured subjectively by the actual players involved?


I'm sorry, but I don't agree. I've seen a lot of "we should do this and that" with no backing arguments. I'll need a little more than just assertive statements to be convinced.

You get more wealthy for doing nothing, just for being one of the first users of Bitcoin. The more people join, the less they gain from this, until there are few new entrants. It's like a pyramid scheme in that sense - you're being rewarded for doing nothing.

Sure, the currency can be easily divided. Sure, people can use alternatives (Hayek, Denationalisation of Money - good read), but I don't think that helps the Bitcoin to become the best money and will prompt its replacement.

BTW, as the Bitcoin supply will grow for decades according to the current plan, this isn't at odds with my POV. I just don't think that it should stop growing if the user base is still growing; that would be counter productive. I also thing the rate of this growth could be optimised better, rather than being arbitrary.

EDIT: P.S. It's nothing to do with keeping a price index like CPI steady (like the central banks try to do). That's something quite different and I would agree that it's flawed and probably an impossible task too (as most Austrians would agree).

This is simply the Monetarist desire for the rate of monetary increase to equal the output increase of the economy.  It is a false argument the Austrians have debunked for years and is one of the factors which has led us to the situation we currently have.  That's been the FED's policy... to match money growth to economic growth....it's one of their primary mandates, price stability.  NO NO NO.  Price deflation is a GOOD thing.  Your money buys more per unit.  You become more wealthy not only by investing in interest-bearing projects but through the increase in the value of what your savings (which pay no interest) will buy you.  It leads to thrift and investment in projects likely to have a higher return than the rate of price deflation.

There could be a good argument for increasing the rate, along with the number of participants, forever.

If every generating node maintains the same constant rate of minting per CPU cycle (ie. more powerful CPU => more minting), then the coin base will grow along with the node base - which is the user base, which gives us a handle on coin demand. This has been touched on a few times on this forum, but I sense resistance to this.

The reason for doing the above, is not to create an inflationary environment, but to keep the number of coins relative to the user base. Failing to do this, will put deflationary pressure on the currency; remember, increasing the demand (number of Bitcoin users) for the currency, is the same as decreasing the quantity (of coins in a fixed Bitcoin user base). If you want to retain a steady, neutral, value of Bitcoins, then this needs to be considered.

Therefore a constant rate relative to the user base would be ideal. The faster the rate of adoption, the more coins should be created.   The reverse could be handled by natural wastage (lost coins), although this could be 'sticky' in the extremes (although destroying a proportion of the transaction fee would speed this up).

I'm sure an algorithm could be formulated to achieve the above, with the constant rate not being so high as to be inflationary - the target would be to keep the number of coins proportionate to the user base, thus creating 0% inflation*.

* I know this seems counter intuitive, but in a currency with a non-fixed (hopefully growing) user base, it becomes very important.

[NOTE: There may be an argument for the minting rate to track 'GDP' or some such - perhaps based on the number and value of transactions taking place? If people are economically active enough to have their node minting coins, maybe the user base may be sufficient/better in creating stability. This is probably another debate in itself, but the above point needs to be agreed on first.]

The client makes at least 8 connections, kind of random. One would need to control all of those entry points. Not impossible of course, but one rogue client is one thing, but a bunch of good clients, how to do you formulate attacking all of them?

The lowness of accepted blocks would be a measurement of difficulty and network computational power.

The biggest issue with this idea except for the bandwidth, is that you won't have a good idea of how many computers are generating in the network, or how hard it will be for generating.

This kind of information is useful when buying/selling bitcoins, as it has an effect on the price.
Also, I wouldn't know myself how easy it will be to generate, possibly wasting CPU power and electricity in my computers.

I rather stick with the system in use today.

The problem you outline exists in the current system. You restart your client after it's been off for a week. It immediately connects to Mallory's client and asks it for the last week's block chain. Mallory responds with one or two blocks, each with an appropriate hash. Now mallory can control your view of the network and transaction history. Oops.

Same problem.

With my scheme when you connect to a 'good' node later, you take the chain with the higher total difficulty instead of the longest block chain. A reasonable measure of the total difficulty under the current proof of work is the total number of zero leading bits in all the block hashes. In the case you mention, the attacker generates a better single block that some particular historical block but because it's followed by a bunch of easy blocks the total number of leading zero bits is much lower than the real block chain and hence the attack fails.

ByteCoin

The biggest problem with this approach is you can't audit it after the fact. Consider the case of restarting your client after it's been off for a week. It immediately connects to Mallory's client and asks it for the last week's block chain. Mallory responds with a chain of super-easy blocks, each exactly 10 minutes apart. Now mallory can control your view of the network and transaction history. Oops. And even if you connect to a 'good' node later, you have no way of sorting out which block chain is real, unless you take the higher difficulty - but this raises the problem where an attacker could spend a long time generating a single block, more difficult than some particular historical block, followed by a bunch of easy blocks. It'll take a while to generate, but then Mallory can rewrite history for the entire network.

Personally, I think this is not worth it, because:

1) We'd be complicating the algorithm, making it much harder to verify that the code is correct and potentially introducing new ways of attacking the network.

2) We'd be introducing new points of failure because clients with wrong clocks wouldn't generate new coins, also NTP packets can be easily forged, and you shouldn't trust the clocks of other clients because they can also be forged

3) We'd be introducing potential new scalability problems. With the current algorithm, it's easy to predict the total bandwidth needed by the network per unit of time: on average, sizeof(block)*number_of_clients*connections_per_client per 10 minutes. With the proposed algorithm, it's harder to calculate, but it'll definitely need more bandwidth (I think much more, but I have no proof).

4) You will never make all the clients agree on a common 10-minute window of time. There will be clients who will be a few seconds off, there will be some a few minutes off, some a few hours off. How do you decide when a time window starts and when it ends?

Personally I find the current algorithm much more elegant than the proposed one. A slight improvement we can make is to do a more dynamic difficulty adjustment like proposed here - https://bitcointalksearch.org/topic/dynamic-difficulty-adjustments-463 - this will more gradually mitigate the problem of blocks taking a much shorter or longer time when someone adds or removes a large amount of CPU power to the network.

Still, I think that this is only a problem while the network is still small. When bitcoin becomes more popular, it will be much harder for any single entity to influence how long the block generation takes on average. But in fact, I don't even consider this a problem, because the network should work just as robustly, regardless of the rate of block generation. The actual rate of block generation should be an implementation detail, not something a user has to worry about. All he should know is that it may take a variable amount of time to confirm a transaction, even though in the future this variation will keep being more and more predictable.

You wouldn't need to wait until right before the ten minute mark to compare hashes. Ideally, hashes would be compared continuously, for the whole ten minutes, so when the ten minute mark approached, all nodes would already have a pretty good idea of who was going to get the block. I think I2P has a swarm based clock and from what I understand, it's a huge complicated mess trying to accurately achieve and maintain an accurate time, but if somebody did want to go that route, the code is available. I imagine if an attacker had enough nodes, he could manipulate the swarm time to his advantage. Slowing down time when he doesn't have the lowest hash and speeding up time when he does. Of course, if you waited until right before the ten minutes are over, I suppose that probably wouldn't be possible. I don't think a giant rush of hashes being compared, would really bog down the swarm, since each node is only sending out their hash if they haven't received a higher one and only spreading the highest received hash. I think the total time it would not take would be more than the amount of time for the lowest hash to be checked by each node, because it would always win when compared to against other hashes and so it would always be propagated and never held back. Of course then the issue arises that competing nodes have an incentive to lie, but I imagine that's the case under the current system. If user X is only connected to attacking, lying nodes, then if he gets a lower hash than the attacker, then the attacker just refrains from forwarding his hash.

Not to mention we'd also add another two new points of failure - the centralized timekeeper (presumably a network of NTP servers) and the automatic rejection of all valid blocks from clients which don't have the clock set correctly, either because they don't have an NTP service configured or because a firewall is blocking the NTP packets.

Just making a presumption on this particular issue, and I don't have any sort of commentary on what would be a "triggering" event to create these kind of blocks, but here is at least a strategy to keep the network from getting completely bogged down with candidate blocks:

Each potential candidate would obviously have some sort of "fitness" metric to suggest which one is more "fit" than another.  If you are generating a block and the "event" trigger occurs, that node would "broadcast" its candidate to all of its immediate neighbors.... and keep track of which "neighbor" (direct connection to another node) has already had that candidate block transmitted.  It only gets transmitted once to a neighbor (with acknowledgment).

When a node starts to receive candidate blocks, it would perform this "fitness" test and either dump the current block (it has failed a fitness test) or keep the block.... continuing to contact adjacent nodes that have not yet acknowledged receiving the candidate block.  If a new candidate is found that is more fit, it wouldn't re-transmit back to the original source of that block (whatever direct connection sent that block), but it would try to share that with other nodes.  If the node receives the same block from a neighbor, it would consider that node to have also acknowledged the block until all neighbors are essentially working with the same block.

While it would be chaotic at first, the network would calm down very quickly in this situation and settle upon a new block that would be ultimately accepted into the chain.

I do agree that the main triggering event would be the big problem with this kind of scheme, and that would imply some sort of centralized timekeeper to create the events.  I also think that such an event driven block creation system would ultimately give out about the same number of "new" coin blocks as the current system, and it would create much more network bandwidth trying to negotiate "winner".  It would also introduce scaling problems that currently don't exist in the current network.

How do you get thousands of computers to agree when is the 10 minute mark?

Ideally you want the algorithm to rely on synchronized clocks as little as possible.

Another problem is that if you'd use your strategy, at every 10 minute mark the network would be swamped with a flood of candidate blocks.