Bitcoin Forum

Each node's influence on the network is proportional to its CPU power.  The only way to show the network how much CPU power you have is to actually use it.

If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it.  IP addresses... much easier to get lots of them than CPUs.

Perhaps Satoshi saw something that he had not anticipated and realizing what was coming, he panicked and decided to leave.

I'm still a noob, but could you give a reason why Satoshi would have panicked over not anticipating mining pools?

Are you saying 51% attack stuff or something else?

The current system where every user is a network node is not the intended configuration for large scale.  That would be like every Usenet user runs their own NNTP server.  The design supports letting users just be users.  The more burden it is to run a node, the fewer nodes there will be.  Those few nodes will be big server farms.  The rest will be client nodes that only do transactions and don't generate.

[secondary conversation edited out from quote]

I keep wondering what is with less experienced users(I am trying to stay away from the newbie word) that keep mentioning 51%. What is so fascinating/scary about 51% attack that it needs to get thrown around everywhere?

I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version 31601)

m0mchil's external bitcoin miner idea has solved a lot of problems.  GPU programming is immature and hard to compile, and I didn't want to add additional dependencies to the build.  getwork allows these problems to be solved separately, with different programs for different hardware and OSes.  It's also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.

The interface has a few changes:

getwork [data]
If [data] is not specified, returns formatted hash data to work on:
  "midstate" : precomputed hash state after hashing the first half of the data
  "data" : block data
  "hash1" : formatted hash buffer for second hash
  "target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful.  [data] is the same 128 byte block data that was returned in the "data" field, but with the nonce changed.

Notes:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been separated into data and hash1.
- data is 128 bytes, which includes the first half that's already hashed by midstate.
- hash1 is always the same, but included for convenience.
- Logging of "ThreadRPCServer method=getwork" is disabled, it would be too much junk in the log.

ribuck's description is spot on.

Pool operators can modify their getwork to take one additional parameter, the address to send your share to.

The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user's near-hits/total near-hits from everyone

That would be easier and safer to start up.  It also has the advantage that multiple hits from the same user can be combined into one transaction.  A lot of your hits will usually be from the same people.

The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.

Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.

New users wouldn't really even need the Bitcoin software.  They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server.  When the miner says it found something, a while later a few coins show up in their account.

Miner writers better make sure they never false-positive near-hits.  Users will depend on that to check if the pool operator is cheating them.  If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.

Perhaps Satoshi saw something that he had not anticipated and realizing what was coming, he panicked and decided to leave.

More likely this scared satoshi away:

Bruce Wagner : When was the last time you chatted to satoshi <laugh>

Gavin Andresen: Um... I haven't had email from satoshi in a couple months actually. The last email I sent him I actually told him I was going to talk at the CIA. So it's possible , that.... that may have um had something to with his deciding

I am also pretty much convinced, that this CIA involvement has something to do with Satoshis disappearance.
He is either hidden very well or he is dead.

I am also pretty much convinced, that this CIA involvement has something to do with Satoshis disappearance.
He is either hidden very well or he is dead.

It would have been nice to get this attention in any other context.  WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.

I wouldn't know of anything else a mining pool could do, that would make "Satoshi panic", except a 51% attack.

Can you provide another example relating to the OP statements?

[I'll try to find the quote directly which dealt with mining centralization]

The design outlines a lightweight client that does not need the full block chain.  In the design PDF it's called Simplified Payment Verification.  The lightweight client can send and receive transactions, it just can't generate blocks.  It does not need to trust a node to verify payments, it can still verify them itself.

The lightweight client is not implemented yet, but the plan is to implement it when it's needed.  For now, everyone just runs a full network node.

I anticipate there will never be more than 100K nodes, probably less.  It will reach an equilibrium where it's not worth it for more nodes to join in.  The rest will be lightweight clients, which could be millions.

At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.

- snip -
Simplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network.  They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain).  If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes.  At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.
- snip -

The current system where every user is a network node is not the intended configuration for large scale.  That would be like every Usenet user runs their own NNTP server.  The design supports letting users just be users.  The more burden it is to run a node, the fewer nodes there will be.  Those few nodes will be big server farms.  The rest will be client nodes that only do transactions and don't generate.
- snip -

As people have already said, it was probably Gavin's involvement with the CIA that was the final straw, he warned people many times about other things, openly so, but the CIA thing is clearly what made him most wary, he's clearly someone who knows just how heavily protective governments are of their monopoly over currency.

I would argue that he would prefer the mining pools above either having a more central network of miners or having an overall lower network hashrate. Pool mining is much more decentralized then what many people understand. If a pool were to in any way act dishonestly or harmful to the network then the owners of the miners would likely promptly pull their equipment and redirect it to another pool

Ummmmm what?

Ummmmm what?

- snip -
Unless the Cartel problem is solved, Bitcoin won't be what we expected to be, but maybe thats not a bad thing.

The concept of large scale mining pools was designed into the system from the very beginning.  Satoshi said so himself multiple times.  If it wasn't "what you expected to be", then you weren't paying attention.

I think coming up with a way to break blocks up so that 250 computers could mine 1/250th of a block while maintaining hash power in the network would help solve the pooling/central hashing issues.

I expected Bitcoin to be a decentralized movement, not something effectively owned by a select few individuals. Maybe I misunderstood, and its supposed to be in the grips of such moralistic stalwarts like Luke Jr.

Reading some of the earlier mailing list posts made by Satoshi back in 2008 and in his discussions with Hal Finney, it seems that his original vision of Bitcoin was quite different compared to the situation today. He did briefly mention ASICs as a possibility by referring to "specialized hardware" as well as the transition towards light wallets like Electrum and Multibit but he mostly referred to miners as being discrete individuals who mined using their personal computers. The only times where he talks about miners cooperating with each other to mine bitcoins is when botnets are discussed. Neither in his mailing list postings nor in his white paper does he ever mention the possibility of mining pools.


That quote is from a couple of months before he left the forum. Even then, he still held onto the belief that nodes are directly proportional to CPU power. Of course now we know that from the perspective of the network, someone that is mining on a pool is not considered a node and has no influence on the network. Instead, the influence lies in the operator of the mining pool.

Satoshi left this forum in late 2010. By then, the first pool (Slush's Pool) had opened and CPU mining was on it's way out. Perhaps Satoshi saw something that he had not anticipated and realizing what was coming, he panicked and decided to leave.

Satoshi knew pool mining was coming just like he knew gpu mining was coming. Back when I was mining with my laptop, the tiny bitcoin mining world was about to shrink to include only those willing to buy gpu's. Satoshi saw that as bad because it would mean that it would take longer for a large number of people to obtain bitcoin. There was a gentlemen's agreement to delay gpu mining.

I think coming up with a way to break blocks up so that 250 computers could mine 1/250th of a block while maintaining hash power in the network would help solve the pooling/central hashing issues.

I expected Bitcoin to be a decentralized movement, not something effectively owned by a select few individuals. Maybe I misunderstood, and its supposed to be in the grips of such moralistic stalwarts like Luke Jr.

- snip -
I anticipate there will never be more than 100K nodes, probably less.  It will reach an equilibrium where it's not worth it for more nodes to join in.  The rest will be lightweight clients, which could be millions.

At equilibrium size, many nodes will be server farms
- snip -

- snip -
If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes.  At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.
- snip -

The current system where every user is a network node is not the intended configuration for large scale.  That would be like every Usenet user runs their own NNTP server.  The design supports letting users just be users.  The more burden it is to run a node, the fewer nodes there will be.  Those few nodes will be big server farms.  The rest will be client nodes that only do transactions
- snip -

Satoshi went most of his BTC history not knowing if GPU mining would ever be. And not he never implemented his ideas of which there were many that counted on no GPU mining.


Following Dr. Goss is one of the fastest ways noobs in BTC historically can lose coins.