What do those two do? I'm guessing the tag is meant for miners? Is it useful for regular people who just run a node or wallet?

Since I just run QT like normal, I don't get the full transaction index? Does that take up additional space or isn't everything in the blockchain anyway? Or I am correct to guess that this is better used by large online wallets or something?

You already submitted this post! You might have accidently double clicked, or tried to refresh.

Of course hidden fork crunched at high speed in shadow is unlikely, and maybe checkpoints do not harm due to low probability of such fork.
But they harm in other way - they compromise Bitcoin decentralization, which is in my opinion is the biggest attractive feature of Bitcoin.
Today they add checkpoints (this effectively changes protocol specification), tomorrow they could freeze BTC on your address, by adding small tweaks to validation routine (just like checkpoints validation).

root@linuxcoin:/home/user# bitcoind --help
Bitcoin version v0.8.6.0-g03a7d67-beta

Usage:
  bitcoind [options]
  bitcoind [options] <command> [params]  Send command to -server or bitcoind
  bitcoind [options] help                List commands
  bitcoind [options] help <command>      Get help for a command

Options:
  -?                     This help message
  -conf=<file>           Specify configuration file (default: bitcoin.conf)
  -pid=<file>            Specify pid file (default: bitcoind.pid)
  -gen                   Generate coins (default: 0)
  -datadir=<dir>         Specify data directory
  -dbcache=<n>           Set database cache size in megabytes (default: 25)
  -timeout=<n>           Specify connection timeout in milliseconds (default: 5000)
  -proxy=<ip:port>       Connect through socks proxy
  -socks=<n>             Select the version of socks proxy to use (4-5, default: 5)
  -tor=<ip:port>         Use proxy to reach tor hidden services (default: same as -proxy)
  -dns                   Allow DNS lookups for -addnode, -seednode and -connect
  -port=<port>           Listen for connections on <port> (default: 8333 or testnet: 18333)
  -maxconnections=<n>    Maintain at most <n> connections to peers (default: 125)
  -addnode=<ip>          Add a node to connect to and attempt to keep the connection open
  -connect=<ip>          Connect only to the specified node(s)
  -seednode=<ip>         Connect to a node to retrieve peer addresses, and disconnect
  -externalip=<ip>       Specify your own public address
  -onlynet=<net>         Only connect to nodes in network <net> (IPv4, IPv6 or Tor)
  -discover              Discover own IP address (default: 1 when listening and no -externalip)
  -checkpoints           Only accept block chain matching built-in checkpoints (default: 1)
  -listen                Accept connections from outside (default: 1 if no -proxy or -connect)
  -bind=<addr>           Bind to given address and always listen on it. Use [host]:port notation for IPv6
  -dnsseed               Find peers using DNS lookup (default: 1 unless -connect)
  -banscore=<n>          Threshold for disconnecting misbehaving peers (default: 100)
  -bantime=<n>           Number of seconds to keep misbehaving peers from reconnecting (default: 86400)
  -maxreceivebuffer=<n>  Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000)
  -maxsendbuffer=<n>     Maximum per-connection send buffer, <n>*1000 bytes (default: 1000)
  -paytxfee=<amt>        Fee per KB to add to transactions you send
  -daemon                Run in the background as a daemon and accept commands
  -testnet               Use the test network
  -debug                 Output extra debugging information. Implies all other -debug* options
  -debugnet              Output extra network debugging information
  -logtimestamps         Prepend debug output with timestamp (default: 1)
  -shrinkdebugfile       Shrink debug.log file on client startup (default: 1 when no -debug)
  -printtoconsole        Send trace/debug info to console instead of debug.log file
  -rpcuser=<user>        Username for JSON-RPC connections
  -rpcpassword=<pw>      Password for JSON-RPC connections
  -rpcport=<port>        Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)
  -rpcallowip=<ip>       Allow JSON-RPC connections from specified IP address
  -rpcconnect=<ip>       Send commands to node running on <ip> (default: 127.0.0.1)
  -rpcthreads=<n>        Set the number of threads to service RPC calls (default: 4)
  -blocknotify=<cmd>     Execute command when the best block changes (%s in cmd is replaced by block hash)
  -walletnotify=<cmd>    Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)
  -alertnotify=<cmd>     Execute command when a relevant alert is received (%s in cmd is replaced by message)
  -upgradewallet         Upgrade wallet to latest format
  -keypool=<n>           Set key pool size to <n> (default: 100)
  -rescan                Rescan the block chain for missing wallet transactions
  -addtag=<tag>           Add a tag to your coinbase
  -salvagewallet         Attempt to recover private keys from a corrupt wallet.dat
  -checkblocks=<n>       How many blocks to check at startup (default: 288, 0 = all)
  -checklevel=<n>        How thorough the block verification is (0-4, default: 3)
  -txindex               Maintain a full transaction index (default: 0)
  -loadblock=<file>      Imports blocks from external blk000??.dat file
  -reindex               Rebuild block chain index from current blk000??.dat files
  -par=<n>               Set the number of script verification threads (up to 16, 0 = auto, <0 = leave that many cores free, default: 0)

That misses Stats 101

Since the shares are of higher value, then when one is submitted it will mean the hash rate will appear higher.

So back again to what I said ...


i.e. no 'weird' calculation.

If you (on average) submit a double diff share every share you submit, but do it half as often, then the average share difficulty you submit will still be the same.
I'll try a little simple maths: 2 + 0 = 2 ... average ... 1

Since the highest user is only around 11% of the pool, the variance it causes is also pretty small.

I think this idea should be discussed first in separate topic. Then, as I understand it should go to Bitcoin Improvement Proposals.

blah blah

Unless there's some weird calculation in the p2pool code to push the base difficulty down

blah blah

Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty.
This is known as "bad luck."

the guy from bloomberg?

what is CCP?