51% can be prevented so long as all nodes agree.

[Peter R]

No I don't mean changing it, PoW is fine - It's the hash rates that worries me because, well, you never know.

I ain't worried about GHash either.
I am worried about how the general public will respond again to having a pool with 51% hashrate.
We have seen what the response was, and to be honest I expected worse..

That is why I said, if this "fear" is gone, then BTC will thrive and become mainstream.

I am saying this because every time I am asked about BTC, most of the people look at the possible failures rather than the already available benefits.
If this problem is out the window I can most certainly say that BTC will at some point become more or less a global kind of currency.
And believe me, I really want that to happen.

That is why I am stressing the fact that something has to be done now.
Obviously it's not an easy task.

Many of us are trying to do something.  But the answer isn't to add new protocol rules, complexity, or trust authorities.  The answer is to increase transparency, promote competition in an efficient and free market, and educate the community.  Like I said in an earlier thread, the best ideas I've seen include:

1.  Soft-fork the format of the blockheaders so that "hashers" can determine using only an SPV client if they are working on an attack chain.  The purpose of this is to increase transparency so that hashers can see more clearly how their hashpower is being deployed.  

2.  Promote P2Pool to attract additional hashpower and reduce reward variance.  Make the process of setting up a bitcoin node and connecting to P2Pool simple and write clear tutorials on the process.

3.  Work towards commoditization of SHA256 ASIC chips.  Right now, the significant obstacle to setting up million dollar + mining operations is securing a reasonable price for hardware.  If we could further decouple hardware producers from the SHA256 ASIC technology, it would create a more competitive market allowing many new large mining operations to come online.  These large operations will be incentivized to solo mine or use P2Pool to retain control of their hashpower.

4.  Educate the community: understand that a 51% attacker cannot create coins, spend coins that aren't his, change network rules, or much of anything really.  All they can do is double-spend their own coins (but it will be obvious in hindsight), and prevent transactions from confirming (this too will be obvious as well as likely stoppable using the Gavin-technique).  

[Grinder]

Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.

Pool A would appear as Pool C if the switched IP. They could just go back to being Pool A when they're back under the threshold, or pretend being pool D, E, F and however many they need to avoid being throttled.

[Jason]

I believe core bitcoin developer Peter Todd had a couple of ideas here:  http://redd.it/281ftd

I don't have much to add, except that a crazy thought just occurred to me where we add a PoS layer to the blockchain so that we have two layers of distributed consensus, one PoW and the other PoS.  Then the PoS layer can be used to regulate the PoW layer.  In other words, those of us who hold bitcoins can actively assign or remove trust from mining nodes (which could be pools or individual miners).  The trust could in theory limit the number of blocks they were able to submit on the PoW side.

I admit I haven't "thought this through" very far and it may not be viable at all.  However, the idea popped into my head after reading one of Danny Hamilton's last posts and I thought I should mention it as I haven't seen it discussed before.

[ljudotina]

do you really think someone can control 50% of "full nodes" ?

Yes, and for less cost than controlling 51% of the hashpower.  

If that's true ( i dont know cost behind it so i cant really argue againts it) than you win by this argument.

PSA: Add a Full Node for just $19/year!

This site suggests there are under 8000 full Bitcoin nodes.
So to get 50% would require adding 8000 nodes, at a cost of ~$160,000 per year. [In practice you could do it much much cheaper than buying them singly!]
I'm not going to work out the cost of adding enough hashpower to get 50% of the network, but it is an awful lot more than that.

I have learned today in this post more than in last few months reading this whole forum. Thanks for spending time battleing it with me / us. I like to discuss things and am not afraid to admit when someone has better arguments than i do and i'm always open to new facts that can / would chamge my oppinion.
After reading rest of posts in this thread i know where real problem is.
I will surely get alot more ideas like this one, now ill at least know how to "test" em out in my head before spending mine and others time by writing it on forums 

[S4VV4S]

do you really think someone can control 50% of "full nodes" ?

Yes, and for less cost than controlling 51% of the hashpower.  

If that's true ( i dont know cost behind it so i cant really argue againts it) than you win by this argument.

PSA: Add a Full Node for just $19/year!

This site suggests there are under 8000 full Bitcoin nodes.
So to get 50% would require adding 8000 nodes, at a cost of ~$160,000 per year. [In practice you could do it much much cheaper than buying them singly!]
I'm not going to work out the cost of adding enough hashpower to get 50% of the network, but it is an awful lot more than that.

I have learned today in this post more than in last few months reading this whole forum. Thanks for spending time battleing it with me / us. I like to discuss things and am not afraid to admit when someone has better arguments than i do and i'm always open to new facts that can / would chamge my oppinion.
After reading rest of posts in this thread i know where real problem is.
I will surely get alot more ideas like this one, now ill at least know how to "test" em out in my head before spending mine and others time by writing it on forums 

+1

[rarkenin]

There's a bit of a dilemma in all arguments involving any sort of IP address. Bitcoin is designed so that it can function over any sort of (untrusted) communication medium. Blocks get from point A to B, verified at B, yada yada. This could be by HSMM (which identifies by callsign), satellite, even carrier pigeon in the most hypothetical of situations.

[TheCoinFinder]

The solution IMO, is to add in a third layer. You have the miner, the pool - and then you have the block template providers. BY connecting the block tempate providers to the miners you can verify that the pool isn't making their own blocks. Pools can then request blocks round-robin fashion from the block template providers, making sure that no one block template provider can get more than one block in succession. Pools then can have whatever hashrate they want - and if they stop using the blocktemplate providers - the mining software will disconnect from them.

Read here and please comment: https://bitcointalk.org/index.php?topic=656008

[phillipsjk]

The solution is simple: break up large pools. Anything short of that is no longer using "proof-of-work". If "Proof-of-Work" is not being used to secure the block-chain, there is no point in having it.

[ljudotina]

The solution is simple: break up large pools. Anything short of that is no longer using "proof-of-work". If "Proof-of-Work" is not being used to secure the block-chain, there is no point in having it.

Break up?
First question would be "how"?

And let's imagine you do somehow break em. What would stop GHASH from opening "GHASH2". One pool could have 30% and second one could have 30%. If GHASH want's to attack all they need to do is change code on both pools and they are as good as one single 60% pool.
So basicly, breaking em apart doesnt do much.
Somehow forcing p2p only pool could be solution maybe?
Wont write again in this topic untill i read little bit more about subject...today was real eye opener...i tought problem was at place A when in reality it's on place B.

But i still think that it's not problem of pools, it's problem of protocol that needs to change to effectivly stop this kind of behviour, just like it stops creating coins once all coins are mined etc.

[phillipsjk]

The solution is simple: break up large pools. Anything short of that is no longer using "proof-of-work". If "Proof-of-Work" is not being used to secure the block-chain, there is no point in having it.

Break up?
First question would be "how"?

Perhaps my choice of words was poor. If the pool(s) you have your miner pointed at exceeds 25% of the hash-power, consider finding a replacement.

I you are a pool operator with more than 25% of the hash-power, consider raising fees.

[QuestionAuthority]

Ok screw this. I have too much "trust" in human intelect. I should have known that barely anyone will read my post with at least half brain turned on, so here it is again, stupid proof and changed so no "trust" is involved:

Well this idea can be extended. Add in some kind of "proirity" level to nodes that nodes gain working over period of time. Priority would be assigned by whole network which is basic idea of BTC....things being decided by whole newtork.
New nodes would have low priority level which would have more restrictions (they could submit less blocks).
Higher priority level nodes would have less restrictions (they could submit more blocks than low priority nodes).

Priority is gained by submiting blocks over period of time. That would disable switching form ip to ip. How?

Her's an example.

(numbers are just figurative)
Pool A = large pool that submits 50 blocks per hour
Poll B = new, small pool that just started working and is submiting 5 block per hour

Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.

What basicly happened, Pool A shot itself in the foot and is loosing ALOT of BTC because they tried to cheat the system, while new honest pool is growing steady.


Is it now much clearer?

Interesting idea but I don't think it would work for two reasons. It doesn't seem to scale very well. When volume grows block times will need to increase and your priority system would be a bottleneck. Also, network time is based on the median time of a node's peers which is sent in the version message when peers connect. The network time is used to validate new blocks. Nodes already reject any block timestamp that is greater than 2 hours from the current network time. Currently there is no incentive to develop a method to spoof network time. You would be creating a reason to do it. If it could even be implemented in the current code, I can see a system like this really screwing something up badly.

[QuestionAuthority]

Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses. If the individual miner submits a block the reward goes to the pool and the pool pays the miner based on what ever reward system criteria is set. Pools or solo miners work against each other to find the block and get the coinbase transaction and the leftover from the other transactions (the fee). What if every participating miner in the world got a proportional share of every block mined? No more pools would be allowed at all. The now defunct miner in Bitcoin QT could be reinstated and that would be the only allowed mining software. If you're not running a full node you can't mine. I know this is insane.

[DannyHamilton]

I know this is insane.

And impossible to enforce.

How will you know who is mining?  How will you know if anyone is using a different mining software?

[rarkenin]

Why not change to just one giant pool, sort of.

What about making an altcoin as a prototype, in order to test the viability?

[QuestionAuthority]

I know this is insane.

And impossible to enforce.

How will you know who is mining?  How will you know if anyone is using a different mining software?

You won't know who is mining. You'll only know that there is no control over the network. What could you do to ensure that proprietary software isn't being used? I don't know. Maybe have the node run a verify on the client at each payout like a random code filter check or possibly a call to verify random code strings against a template.

[DannyHamilton]

- snip -
What if every participating miner in the world got a proportional share of every block mined?
- snip -

You won't know who is mining.
- snip -

I'm confused.

If nobody knows who is mining, then how does the system know what proportion to send to everyone, and who to send it to?

[Erdogan]

Ok screw this. I have too much "trust" in human intelect. I should have known that barely anyone will read my post with at least half brain turned on, so here it is again, stupid proof and changed so no "trust" is involved:

Well this idea can be extended. Add in some kind of "proirity" level to nodes that nodes gain working over period of time. Priority would be assigned by whole network which is basic idea of BTC....things being decided by whole newtork.
New nodes would have low priority level which would have more restrictions (they could submit less blocks).
Higher priority level nodes would have less restrictions (they could submit more blocks than low priority nodes).

Priority is gained by submiting blocks over period of time. That would disable switching form ip to ip. How?

Her's an example.

(numbers are just figurative)
Pool A = large pool that submits 50 blocks per hour
Poll B = new, small pool that just started working and is submiting 5 block per hour

Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.

What basicly happened, Pool A shot itself in the foot and is loosing ALOT of BTC because they tried to cheat the system, while new honest pool is growing steady.


Is it now much clearer?

Bitcoin has only one connection to the real world: the timestamp used to regulate the block rate. Everything else is concepts. We do not want to invent new references to the real world. We want it to float between peoples minds.

It is not necessary to worry about concentration in mining. Firstly, it is only the pools that are now concentrated, the actual miners are still well distributed. Even if also the miners should merge into a near monopoly, it is not a problem. Study monopolies in the free market as analyzed by austrian economics. Monopolies are a problem only in the presence of force in violation of human rights. Heck, you can ask Henry Ford.

Imagine managing a miner with 80%, competing with 3 miners with 5% each, the last 5% spread around. To keep that market share, you have to be on top of everything. Getting the best new hardware, keeping a stable power supply, keeping the personell, be alert around the clock and around the year. Even at 80%, you can be only slightly more profitable than the next miner. A slight misstep, and you loose some blocks, eroding your profit, transforming it to a loss. A chance for another miner to have a go.

[QuestionAuthority]

- snip -
What if every participating miner in the world got a proportional share of every block mined?
- snip -

You won't know who is mining.
- snip -

I'm confused.

If nobody knows who is mining, then how does the system know what proportion to send to everyone, and who to send it to?

How did Bitcoin QT know who to send the reward to back in the old days? You enter your address. The only difference would be tracking hashrate. If QT sent the hashrate of each client to the network you would know how much each installation of QT was generating. Every node in the network would have a copy of the template and the file size of the software. At each payout it could run a check on the software to verify a random string then check its own file size and verify with the network. I said this was insane. It would be a complete overhaul of the system and require everyone to update their client at once. It's much easier to leave everything alone then to make changes, which is probably why nothing is changing. Well, except for all the competing altcoins that are being developed daily. Eventually someone will come up with a really great idea for a superior coin that fixes all of the current problems. I haven't seen it yet but it could be out there already waiting to take over.

[phillipsjk]

Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses.

Congratulations, you re-invented P2Pool. Eligius does the same thing: paying the miners directly instead of paying everything to the Pool's wallet (Both examples still use the traditional approach for alt-coins).

There is a bit of a definition issue though: miners generate blocks, while hashers generate proof-of-work. We are in this crisis mainly because those two functions have been separated.

While I understand setting up merged mining may be costly and a lot of work; hashers need to understand that they have to monitor the entities they are lending their hash-power to.

[QuestionAuthority]

Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses.

Congratulations, you re-invented P2Pool. Eligius does the same thing: paying the miners directly instead of paying everything to the Pool's wallet (Both examples still use the traditional approach for alt-coins).

There is a bit of a definition issue though: miners generate blocks, while hashers generate proof-of-work. We are in this crisis mainly because those two functions have been separated.

While I understand setting up merged mining may be costly and a lot of work; hashers need to understand that they have to monitor the entities they are lending their hash-power to.

LOL  Except mine would be forced on you.