Topic: Necessary protocol improvement; dissent on future mining configuration - page 3. (Read 6359 times)

That's pretty much how the proof-of-work system works now.  Feel free to fork the Bitcoin code to attempt what you are advocating.  And after a little while, I'll come help break your web of trust system.

Oh, yes.  I can.

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?

What is the better way?  How do you eliminate double spending?

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!

What you propose is:

a) Not BitCoin. "One CPU one vote" is pretty core to the whole idea. A system with substantially different voting rules would be an entirely different currency and network.

b) Not robust against future improvements in computational power. Nobody can decide up front what the "right" difficulty is because 100 years from now children will be assembling SHA256 capable ASICs out of lego bricks.

That's why a system which provides as much security as its users needs is required and that's what the model I've proposed does (more fees == more work). I know you don't believe in it, but if you want an alternative you'll need to actually design it and convince people it's correct. The voting rules are the most complex and subtle part of BitCoin so that will take some work.

Storage is not really a concern. You can already prune buried transactions from a stored copy of the block chain, though it isn't implemented today. This is covered in Satoshis paper.

Ok I'm a computer geek, but even regular people here seem to have their comp on 24/7 now.
Most have 2 or more cores and terrabyte drives.

What if the standard client nodes also generated hashes/blocks?
Let's say 50% of 1 core and 10Gbyte space was default "donation" to the network, adjustable by the user.
"donate and help keep your money safe!" 

By the time bitcoins converge the computing power and storage capacity should have increased maybe 10x or more? And all systems have GPU's or hybrid CPU architectures for even more hashing speed.

I think your conclusion is incorrect, but am still posting here to be able to follow this thread.

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: https://bitcointalksearch.org/topic/if-tx-limit-is-removed-disturbingly-low-future-difficulty-equilibrium-6284

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.