Ahahaha~ you didn't say the vote closes if it happens, so I voted yes! ヽ( >∀<)ﾉ

I have no idea where the price will go within the next month. Up? Down? Crash? Google joins in? Can't pull myself away from following Bitcoin news.

Bitcoin is more versatile, but gold will probably remain more stable for a long time. Gold also has the advantage that it's shiny.

If I ever get rich, I might trade some for gold as fallback. Not a lot, just a few percent. For the case some madman cuts the trans-Atlantic cables or fucks up power supply. Can't pay in BTC without functioning internet.

Haha... you want something from people who know game theory, but by game theory rules, they shouldn't play your game. Say, my theory is correct on both accounts. I now need another person applying game theory to review my statement, but then I'm getting the money. So, being proper in game theory, he won't do it. (Okay, maybe you'll find reasonable game theory experts, ahaha~)

My try on an answer: remember the thread I linked in the beginning of this thread? There's a lot of discussion about the topic there. It's a little chaotic at first, but I think the main dynamics are analyzed there. Sorry about it not being very formal, but this way more people can read it. Here's a summary of the conclusion I came to, and use as an assumption in the thread we're in now:

• The fee system as it stands is dominated by transaction demand over hard-coded transaction supply, unless a miner cartel can force prices for speedy transactions. But that is an external factor, it depends on too many things outside Bitcoin to be included in a game theory analysis. The point is: we cannot rely on the cartel, as nobody supplied a reason why it is likely to appear. (Also, the cartel is a danger in itself, but that's beside the point here.)
• No block limit and no enforced transaction prices: just write a formal version of the thread linked in this thread's first post. frankly, prices converge to verification cost, which is close to zero. That's it, plus again the cartel thing again, which encounters the same problem as in the other model.

I don't really want to unfold this here, that's why I try to keep that discussion in the other thread. I know that's annoying to those who don't agree on that yet, but it's better if the discussion isn't stopped at that point until everyone is convinced.

(Sorry @double post, not editing more in case people subscribed by mail. This frequent editing is a bad habit of mine.)

Your argument relies on this statement, but I have not seen it proven. I did not manage to construct a substantial link between fees and the cost to attack the network on the current code. The problem is that your argument needs further assumptions on how much Bitcoins are moved, and how many rich people exist who would find doing an attack worthwhile. A simple block size limit or partially enforced transaction fee is linked to the quotient "BTC value in attacker's hand / difficulty" in a very nontrivial way.


Edit: I don't see your attacks against the Web of Trust problematic in a real-world situation. Let me take them on one-by-one.

• Node identity spoofing is the same as Bitcoin target address spoofing. If this is possible, Bitcoin is already broken.
• 'scorched earth' only works as long as the Web of Trust is small and holds only few connections. Otherwise, the risk falls exponentially with the number of connections. Say the chance of a node following the single, world-wide long-planned attack is P < 0.5, and N are connected. Well, do Bernoulli, or Gauß approximation, whatever, it's exponential. Fails hard if the attacker has less than half the network.
• We can keep a certain amount of "proof of work" up, to construct a starting point limiting the amount of enemy nodes. Then use any reasonable probability for a node planning to turn evil in the future, and from what I know about math, it'll turn out we're fine as long as the remaining amount of miners or connections aren't absurdly small. And connections are VERY cheap.

I see no problem. Your attacks can apparently be thwarted neatly.

If you want a default fee, better hard-code it into the protocol, that's at least reliable.

But this thread still has the open question: isn't there a much better solution, that can work on the very small power required to check transactions?

Could you please explain the problem instead of... writing that kind of message? Also, please estimate damage -- the current solution also subdues to attacks, the question is how likely and expensive the attack is. If fees are not held up by volunteers, it will be of the order of confirming all transactions. That sounds small to me, one might call it "broken by design", so if the WoT system breaks under less problematic conditions, the trade-off might be worth it.

Sure, db is right, voluntary micro-donations can make quite something on a big network. But those could be used for a different good purpose, so we better make sure the enormous waste of processing power is necessary. Also, there might still exist an even bigger supercomputer, and Bitcoin gets vulnerable again. We have no viable model of how much fees people pay voluntarily.

I see how we need large-scale mining now, for fair initial BTC distribution. But in the future? There exists no other solution than trying to be the world's #1? A very bold claim, and a destructive one if it is false.

db:
this will give some arbitrary network size and power.

Want to make a bet of the kind "the biggest supercomputer in the world in 10 years will be Bitcoin and not run on cloud clusters that might suddenly have orders changed" as your statement? That is very risky. Many computation clouds are coming up, the net is growing huge.

asdf:
aren't inclusion costs independent of difficulty? Are you saying, Moore's Law will stop AND people won't build dedicated hardware AND pooled mining won't dump the problem into oblivion AND processing power will not be spread to bigger parts of the population?

You call the issue of a disturbingly low difficulty equilibrium "resolved" when the global cost of a transaction approximates a single verification? Sorry, are you serious, or have I misunderstood something about the verification cost scaling? Also, the discussion at hand would fit better in the other thread.

The block chain is already the solution to that, as long as it follows the rules and no branches are added somewhere in the past. And that's the thing. Just like with checkpoints, clients can frequently agree à la "okay, nobody coming up with a different block? then it's settled, this one is the real one for all eternity."

Implementing this agreement is all we need! It looks more like a Web of Trust problem to me, yet we hit it with brute force.

Say the current system goes down to a fairly low difficulty, but a Web of Trust sits on top of it, setup to come to an agreement on the question "when was this block published", to then strongly prefer branches of the block chain created earlier.

Not my idea, but I kind of like it. Go, attack this puny network with so little processing power. What'cha got?

My prediction was correctly restated by Holy-Fire, so I continue without a repetition.


We are talking about a high block size limit with large amounts of low-fee transactions allowed to be processed by miners. I would call it "eliminating the arbitrary magic value linking market size to transaction fees", but your proposal sounds good too.

Holy-Fire:
I think the argument was that if the transaction confirmations make up a large portion of power demand, a large miner is at a massive advantage. He gets to use his confirmations more often, since he finds more blocks. Competing small miners have to calculate them too, but they find fewer blocks and thus have to throw them away most of the time.

pulse: we can't proove a donation network is stronger than, say, a botnet. Relying on processing power will always have us in an arms race.

[mike]: Ah, I did not mean a total difficulty. Just a relative factor, or a time limit for attackers, as already achieved with the checkpoints, just shorter? I'm still brainstorming here for an optimal solution. I don't know whether it can be done without constructing a full Web of Trust, but basically, most nodes can tell when a blatant attack happens from the timing when the blocks are published. An attacker always has to wait for confirmations of the first transaction, then publish the second. Anything that behaves even remotely like a Web of Trust will be able to collectively determine which branch was there first, and try to enforce that this one be valid. Not using this information at all is a huge waste.

By the way, I don't care about the computation power voting system once coin generation is done with. In fact, I don't like it, it's a massive waste of energy on a known outcome: the block chain is supposed to be valid and follow the official timing.

Now, are you people really saying there's no better option to enforce a set of rules than building the world's largest supercomputer? I can't prove it false, but still. That's one hell of an expensive decision. There has to be a better way!

I'm kind of relieved to see more people agree we do have a problem.

Now, while I'm glad this thread is being used to clarify a part of the situation, this is touching a topic on which a theoretical discussion no longer suffices. IMO, we need a clear, widely accepted statement on the issue.

Sorry for making yet another thread, but I feel a serious need to do so; here I want to discuss possible solutions:

http://bitcointalk.org/index.php?topic=6576.0

We currently have no consensus on future system parameters controlling transaction fees, and thus also the amount of miners. In another thread, I concluded that in transaction fees are determined mainly by market size and the maximum block size. If you disagree, please discuss in the linked thread. In this thread, we assume the conclusion correct.

Here's the thread: http://bitcointalk.org/index.php?topic=6284.0

In this thread, I want to ask a simple question that apparently has no generally accepted answer. What is the desired future system configuration? How many miners do we want, how many do we need? How do we face the times ahead?

First, please let me share a personal feeling of mine, which drives my urge to write this thread. Please bear with this paragraph, I think this is really important. In my opinion, we should turn Bitcoin into a rock-solid set of rules that will not be broken or altered unless the technical circumstances change. Altering rules later on might run the system into a crisis, especially when things like miner income are concerned. No doubt lobbies would form, trying to push parameters one way or another. In my imagination, this has a huge impact on the psychological image of Bitcoin. That's not rock-solid, that's the mud we already have in other democracy-controlled currencies! Now, I know big things don't break easily, but I really don't want things to come down to this. Let us solve problems we find early and completely.



Now, to the situation. We have a set of jobs that must be done at all times.

• The block chain must be stored reliably, or at least all parts of it required for transaction and security against attacks.
• Transactions must be verified and processed
• The block chain must be kept consistent and sufficiently secure against attacks

Currently, miners solve all three points, and get paid with newly generated coins. As concluded from the earlier discussion, if no changes to the protocol are made, we have a problem at least with the third point, securing against attacks, once coin generation no longer pays miners. We have to find a compromise between a high transaction limit and a high vulnerability -- or a low transaction limit and high fees. A situation with high fees sounds very bad to me. A limit on transactions, expensive fees, all so that hardware can waste energy? It's better than a breakdown, but is it truly our best option? Plus the discussion on the limit, potentially segmenting the network in a cyber war. This makes me shudder.

Then again, we have another "tragedy of the commons" with storage. We cannot have arbitrarily high block sizes, for we can afford to generate, but not to store blocks of arbitrary size. I really hope the Bitcoin designers have made good models on memory requirement if the transaction count increases by a factor of 10,000 or the likes. And, last but not least, the trouble of an attacker with a lot of processing power remains.


But are the latter two really unsolvable? I doubt it. Let us try finding a way to survive without a large amount of miners. There should be methods for the network to agree on a block chain that do not involve absurd amounts of processing power. It could try punishing block chain branches that look like attacks for timing reasons. This could be done by raising difficulty on such chains. (Thanks to the one who suggested this on IRC, I forgot who it was though. ) This is much better than relying on having more processing power than any attacker! If this can be achieved, we'd only have the storage problem remaining. That somewhat also sounds doable, since we don't need to lift limits completely, and ancient parts of the block chain might not be all too important. We already have checkpoints, there might be ways for the network to agree on who has which coins without everyone storing that enormous history.

Think about it. We have to solve two problems, and we get a cheap and long-term sustainable state if we do. The Shangri-La of Bitcoin, so to say: we get gains on transaction amount, transaction cost and system security.


Can this be done? If so, I call to anybody into Bitcoin development: what are you waiting for? In either case, we should analyze the problem; the current configuration is likely to cause trouble.

Personally, I'd have liked it if BTC that aren't used for much too long begin fading away and get slowly collected by miners, after 10 years or so. That way, the amount of BTC is exactly determined and they don't just get less and less with nobody knowing how many are left. Plus we'd have some remaining mining in the future that has a solid and fairly predictable income.

But it may be too late for that fix now. I actually never understood why it shouldn't be done -- nobody accidentally keeps coins around unmoved that long.

@da2ce7, [mike]:

Can you please debunk the exact failure modes I described for your suggested system, and provide the suggested equilibrium of the miner network size? In my eyes, the system configuration proposed has a macroscopic and a microscopic configuration, and both fail and both provide no reassuring equilibrium estimation. This has been handled before in a logic argument, with no part of the argument shown wrong so far! Why are we going over this again, with just claims again? (In fact, I just found a minor error in my end state of the macroscopic "cartel" configuration -- but I don't find any configuration that splits the block chain in standard operation good, and no other stable state has been provided so far. I'm still editing the post for clarity now. I'm still worried nobody noticed the error, it feels like nobody is checking my posts, no wonder I don't get arguments against them.)

My suggestion is that we move on from the "arbitrary fee height agreed on by miners" model. It doesn't get the discussion anywhere, unless someone can back it more strongly. Especially, I want to note that the model does not even provide any equilibrium difficulty at all, so even if we'd take it as true, there is no reason to believe this equilibrium would be at a good value for the system. This is building on sand, investors will not be satisfied with such an answer. We're not doing a trial-and-error game here, we want a solid currency for the future!

@da2ce7: You claim there is a link between required security and fee height. I do not see a substantial link. Can you explain where this claim comes from?

So, if someone takes your phone, even a thief, he can read it. Wow I... did know that already. lol.

Leaving BTC unencrypted on a device you practically throw around across countries, tables and pockets -- one must be ready to loose them, no? Isn't the whole POINT of BTC to use crypto for security instead of obscurity?

If you people really are concerned, go to Cyanogen and improve security of the OS, e.g. easy full encryption + Password on both internal and exchangeable memory, replacing the insanely broad file system permissions.

Otherwise, you might persuade the police to be nice, but then a thief takes your phone --> epic fail.

The main question might just be: do we need lots of miners to support the system at that point?

Optimal case: a system can be established that can agree on a block chain without the use of enormous processing power. Right now, we need expensive calculations to ensure no single person gets all the new coins, but later? There might be a way to keep the system secure and fees low, and we should work hard to find it if it exists. It would make Bitcoin a lot more valuable if there was no compromise to be made between transaction fees and network security.

I'd compare with different examples: fishing in the ocean, polluting the environment, wasting tax money, supporting a bad natural monopoly, quickly claiming and using up natural resources. Clearly, in those examples individual behavior is damaging to the community, and they are closer to the Bitcoin example than the examples just provided, because they don't include a highly local market. Bitcoin mining is not highly local, unlike any shop or stadium.

A football stadium has fans who want to see exactly that game at exactly that place, it is known to its customers. The feedback goes to the stadium in a large fraction. A small miner, though, is practically unseen by his customers -- meaning he's not as afraid of the feedback. If you don't like the assumption of the miner being small, we're back at the case I discussed in the first reply to your model.

@last paragraph: In capitalism, limited funds stop someone from cornering a market of goods that can't be cheaply stored with lasting value. As seen with subsidies, e.g. US cotton against third world markets, the cornering happens the moment the limited funds loose weight. As you said yourself, in local markets with a very large player, price dumping is indeed a problem and has to be handled by authorities. (On goods with lasting value but no high storage cost, dumping a sales price is idiotic, because it turns you into supply to competitors. Example: dumping BTC in USD terms might get you another trader buying your BTC to later sell them in your place.)



We're still without a configuration that keeps a constant high mining rate while assuming a high tx limit and no further changes to the protocol. I like to emphasize that it has not been proven that this outcome is a problem. Also, maybe the block size limit shouldn't be set too high for the obvious reason of a gigantic block chain being costly to handle.

All in all, I propose trying to find a way to secure the block chain against fraud without wasting large amounts of processing power. A little to throw out cheap spam might be good, but the current mega-energy-burning sounds increasingly bad, and possibly unnecessary, to me.

@[mike]
I took the closest-to-stable configuration I understood from your post, and that included the splits. The second version is discussed afterward. As I understand from your reply, what you actually meant only works if the vast majority of miners abide to your rules. Otherwise, they will include all transactions with a small fee, and whenever someone pays larger fees, he pays to confirm all these transactions as much as his own, and the reduce in waiting time is only his own fee on a global scale, which is close to no benefit! Also, imagine half of miners follow your rules. (You wish, I don't see that happening.) Then calculate the average time to 6 confirmations for a low-fee payer and a high-fee payer. It's useless! The benefit is totally not worth the fee unless you're in a real hurry.

You make a claim that requires both macroscopic behavior (a cartel to enforce fees dominating block generation) and microscopic (no cartel exists that could split the block chain) at once. That is incoherent, I don't see Bitcoin balancing on some fine line between small and big miners, especially if small miners who don't follow the rules can make more profitable blocks. Your suggested configuration is not stable. End of story.

BTW, I don't see how one can "over-think" things. It's possible to make errors, true, but making some extra checks doesn't hurt, as I think this thread demonstrates neatly. It may be that the problem is not a problem, for the nice reason that Bitcoin code is open to minor adaptions if the majority agrees -- or, if it doesn't, the current block size limit solves the problem for us.

But that doesn't mean it's good to wipe a potential problem off the board, especially before it's analysis is finished. There is still no consensus on the final network configuration. We might end up with a sub-optimal solution, especially one that is too open for attacks or wastes processing power. There is currently no force that ties the wanted result (a level of security for the network) to the means that achieve it (transaction fees within a large network). If that's not worth discussing, what on the whole technology is worth discussing?


@bitlotto:
Please read the first post. If you did, please read it again.

You make an assumption (trade fees rising) that appears to not happen in the context at hand. First solve that problem, otherwise whatever follows "IF the fees got high" has no relevance. Again, remember I assume a Bitcoin system with a large maximum block size, so this does not determine fees as it would with the current limit and a larger market.

Glad to see someone agree, I was beginning to feel a little crazy here.

I don't think 25 BTC/block is a problem, we'll just see some miners disappear, but the reward will still sustain things.

But the issue should be solved in advance to demonstrate that Bitcoin is meant to work on the long run. We may be faced with bribing of developers to achieve higher or lower fees if we don't carve a sustainable solution in stone early enough. Arbitrary limits in a changing protocol are a magnet for corruption. And imagine the chaos and loss of trust in Bitcoin when a fraction of the network has the rules changed against their will. The protocol rules should be finished and fixed, hopefully never to be touched again afterward.

That said, I have run into an entirely new question: do we need a lot of hashing power at all times? Maybe we can solve the attack problem with very few miners and a smart protocol! I've opened a new thread to ask this question, since this thread is confusing enough already:

http://bitcointalk.org/index.php?topic=6363.0

Maybe we've been afraid for no reason -- maybe we're best off with very few miners! If security against attacks can be increased without increasing processing power, we're good, and we'll have super-low fees! Everybody would win.

If a miner would earn a lot (high fees), more miners would join, and thus the assumption of few miners wouldn't be valid anymore. Edit: ah, sorry, I'm talking about a situation in which the transaction limit is not an issue. It seems to be a common opinion that we don't really want transaction fees forced up by setting a harsh limit on the transaction rate.

It's not really the topic of the thread though. I just wonder how dangerous a state of a small hashrate would be. The dynamics of fee height and amount of miners are the topic of the thread I linked to.

We just had a little discussion about this on IRC... apparently, there might be ways to fend off attacks against Bitcoin better than by just overpowering the attacker, e.g. by giving advantages to miners working on a more "trustworthy looking" chain. I've not seen a formal version of this suggestion yet though.

As posted in another thread, I stumbled over a scenario in which total mining power might fall if there is no sufficiently small limit on the number of transactions per block:
http://bitcointalk.org/index.php?topic=6284.0

The discussion on whether it will happen aside, this thread is about what happens if it happens.

My guess would be that, in such a case, we'd end up with a miner supply that's not super-small, but nowhere near the supercomputer level we're currently running for. This scenario has the obvious benefit of low transaction fees, but is generally feared because of an attack that can split the block chain, reverting a past transaction. (Other dangerous effects?)

Any estimates on the troubles we face, considering a fairly large, world-wide Bitcoin network? Might there be methods to construct "insurance miners" that jump in on unwanted splits of the block chain? Maybe changes in the protocol, further rules to counter splits?

A Bitcoin network based on as few miners as possible would be a great success, we would have beautifully low transaction fees. Maybe what I fear as a danger might be a benefit, if there's a way to keep it stable against attacks. The "valid chain insurance" mining groups would behave great in that respect. Maybe this is the solution to the whole problem?