Quote from: Lauda on February 05, 2016, 11:33:54 PM

Quote from: simon66 on February 05, 2016, 08:24:40 PM

Mining pools and mega farms..

I think the code should have something to disincentivise the centralization of mining. I don't think rules that disallow it would be the answer. More like built in conditions that the free market will turn into decentralization rather than encourage centralization as it is.

This makes sense. Centralization is indeed a problem, albeit nobody has a real solution for this. Incentives to run nodes would be also nice in order to relive the costs and promote decentralization.

Yes, I agree that some incentive for nodes would be nice. I would run a node if so. Even just 1% of TX fees directed to nodes would be nice.

Quote from: bitbaby on February 06, 2016, 04:49:34 AM

Quote from: simon66 on February 05, 2016, 08:24:40 PM

Mining pools and mega farms..

I think the code should have something to disincentivise the centralization of mining. I don't think rules that disallow it would be the answer. More like built in conditions that the free market will turn into decentralization rather than encourage centralization as it is.

This. Maybe it is not a concern right now but it will be soon. Don't think Satoshi imagined that mining will become like this. But I don't think there is a solution to this now.

What if there was a way to make bitcoin's code aware of mining data such as in this pie chart..

And then vary difficulty based on who is connected and how much hash they are putting on to where connections of lesser hash would be hashing on a smaller difficulty then the mega hash connections. Like assign the greatest hash difficulty + 10% and the smallest hash difficulty -10%. To where if say actual difficulty was "find a hash with value less than 10" assign the greatest hash connection "must be less than 9" and the least hash connection "must be less than 11" and assign every hashing connection in the middle between least and greatest a difficulty somewhere in the middle..

hash=100=less than 9
hash=75=less than 9.5
hash=50=less than 10
hash=25 less than 10.5
hash=1= less than 11

Where hash=100 is the greatest hash connection and hash=1 is the least hashing connection.
This could be done linearly or exponentially or variably based on the difference between the least and greatest hashing connection and the solved block would be accepted based on difficulty X (connection hash % of max/min) and could even be weighted based on the % of miners that fall into a certin ange between least and greatest. Give an advantage of lower difficulty to connections with less hash power to bust up the mining monopolies.

Ofcourse I have no idea if something like this is possible because I really don't know what I'm talking about but I think it would be good to find a way to put the mining monopolies at a disadvantage VS the more decentralized miners.

I also think that this must not be done with rules or laws but rather in a way that provides incentives based on the code so the free market will sort it out.

Took me a while to find this post again..

Quote from: theymos on January 15, 2016, 08:10:18 AM

Someone who could very well be Satoshi said:

Quote from: Maybe Satoshi

I have been following the recent block size debates through the mailing list. I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus. However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork.

The developers of this pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth. When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement. Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it. By doing a fork in this way, these developers are violating the "original vision" they claim to honour.

They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn't anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.

If two developers can fork Bitcoin and succeed in redefining what "Bitcoin" is, in the face of widespread technical criticism and through the use of populist tactics, then I will have no choice but to declare Bitcoin a failed project. Bitcoin was meant to be both technically and socially robust. This present situation has been very disappointing to watch unfold.

I like that post a lot and think it is something that should really be thought about.

I don't know. I wish I was a genius and understood all the code but I don't. I probably barely understand the whole concept.