Everything.  If majority of hashing power agree that block reward is 50,000 BTC per block then it is. 
If the majority of hashing power implements a demurage on your wealth then it happens.
If the majority of the hashing power forces a 0.1 BTC min fee for valid tx then it is unavoidable.

So yes the votes by hashing power are very important.  Now for a Democracy to work the voters must be INFORMED and EDUCATED.  Most of the problems with modern Democracies can be boiled down to ignorance of the issues.  Life is "good enough" for most Americans in America.  Most voters don't feel the need to be informed, or question authority. Even bad legislation isn't bad enough to stir them to action.  Our govt has rigged it so most Americans don't pay income tax thus have no direct stake is how the govt wastes money.

The nice thing about voting by hashing power is the miners do HAVE a direct stake.  Their hashing power has a cost, the future economic value of that hashing power is a direct tangible benefit.  Most (maybe not all but most) miners tend to be relatively informed.  They are more likely to make decisions that enhance Bitcoin because it enhances their future economic value.


Um ever heard of moving, or convincing the majority to change their mind, or violent overthrow of the govt?

I can exchange my Bitcoins for a currency I feel is better aligned with my interests.
I can move from my existing country to one where I feel the govt is better aligned with my interests.

I can work to change the protocol rules and convince a majority of miners to support those changes.
I can work to change the laws of my govt and convince a majority of voters to support those changes.

I can attack the Bitcoin network and setup a competing network.
I can attack my govt in an attempt to overthrow it and setup a new govt.

If you spend 1 BTC which is 100 days old then it is 100 bitcoin days destroyed.   Some incorrectly dismiss this because moving some very old coins can result in a lot of days destroyed HOWEVER they are now 0 day coins.  Each individual move isn't important what is interesting is the aggregate daily # of coins destroyed and if that amount is rising or falling.

Hundreds of people have similar experiences and Papypal doesn't really care what you threaten them with.

The outcome was completely predictable.  If you hadn't been scammed with this sale you would have on some future sale. It was never going to end well.

Your were naive and foolish.  Now (hopefully) you know better.

Is that really necessary?  Any node not upgraded has been forked from the p2pool as incompatible.

Sites like that (dailytech is another example) are heavily biased by the authors.  If a site has a concentration of authors who have a snap judgement about Bitcoin then articles will be slanted that way.

Ghandi (disputed quote)

The ignore phase was 2009 & 2010.  2011 was mostly the laugh phase.  If you look at the article in sequence the tones goes from one of laughably and mocking to harsh and biting.  People who thought Bitcoin was "stupid" in 2010 are getting frustrated because it is still around. 

That will be news to every datacenter in the world.

208V single phase
http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=AP9571A

208V 3 pahse
http://www.apc.com/products/resource/include/techspec_index.cfm?base_sku=AP7516

ATX PSU have no problems working @ 208V.

The rest of the info was good just not sure what you were trying to say with the quoted sentence.

Of course there is it just happens to be 1 hash = 1 vote instead of the more common 1 person = 1 vote (or 1 white land owning citizen = 1 vote)

While anything can happen you will never get 70% to 80% of miners to support it.  Notice I said 70% not 50.001%.  While technically you could fork the chain with any amount of support (even 1%) a 50% split would likely be the death of Bitcoin.  The original and modified forks would both exist, people would have coins in both forks and when sending coins they would need to specify which Bitcoin they were talking about.  Some exchanges/merchants might support "new Bitcoin" and some "old Bitcoin" and some would support both.  Users would have differing values in each chain and those supporting one side would see no value in the other resulting in massive selling. 

It would be beyond chaos, and the negative PR alone would be catastrophic.

It won't happen.  Even many miners who would support it in theory won't support it for the massive disruptions it would cause.  Discussion it is just pointless.

Nobody (I guess you are?) is even suggesting block reward will be kept constant.  The fixed # of coins is a cornerstone of Bitcoin.  Changing that now (even if desirable) will never happen.

Ok this doesn't make any sense.  As block reward declines the need for miners to exclude unprofitable tx becomes even MORE not less important.  

To combine your the two underlined portions, so hypothetically when the block subsidy is 0 BTC miners should be required to include all tx.  Even if they are mostly 0 fee?  If miners must include all tx (even those w/ no fee) why would any user include a fee?  The simple answer is they won't and thus both block subsidy and fees will be roughly ~0.

So when block subsidy is 0 and fees are 0 how will the network remain secure?

It can be done.  The other option is to cut the "fingers" of your PCIex8 extender with a dremel tool so only the PCIex1 "fingers" remain. Wrap the cut portion in electrical tape.

A mistake there only ruins a $10 extender.

Very good analogy.  

To the OP once you find that speed where cards are stable for hours but not days then you are close but still "speeding" a little too much.  Try dropping the clock 5-10 Mhz (remember every single GPU is different, there is no "standard" speed).  Cards will likely now be stable for 72 hours+.  At that point you need to decide if a reboot every 3 days is better/worse than dropping the cards another 5-10Mhz lower (where they may be stable for 30+ days).  

Another thing to look for (in cgminer) is HW errors.  Those are caused by the card returning garbage as "work completed".  It is a good sign the GPU is redlining and is right on the edge of stability.

It isn't black or white.  STABLE vs UNSTABLE.  It is a gradient (hypothetical numbers):
Crash instantly (0.0 ms)  - max speed
Crash in seconds - slightly lower
crash in minutes - slightly lower
crash in hours - slightly lower
crash in weeks - slightly lower
crash in months - slightly lower

You don't see a problem with that? Currently a 51% attack "only" alloww the attacker to
* stop the network
* double spend his own coins (reverse txs he created)

If network is reduced to a flat ledger a 51% attack would allow the attacker to change balances of accounts he doesn't own which massively increases the economic value of 51% attack.  Even the potential is damaging.

Then again 75MB + 50MB per week (say 4 weeks of history retained) = 275 MB which last time I checked > 50MB claimed.  Also that was a back of the napkin estimate.  Someone actually did create a ledger and the size was 10% of full blockchain.  So that would be more like 200MB + 200MB for 4 weeks of history = 400 MB. 

The cost estimate for a pruned blockchain is ~500MB vs 2GB raw so you are saving very little.  Pruned block chain provides most of the space reduction with no loss of security.


Not correct but at least this time you correctly indicated it it your belief not fact.  

Pruned merkle tree allows verification of blocks, verification of your tx, verification of other users tx, and mining new blocks.  There is no functionality that is lost with the exception of tracing coin history beyond the oldest unspent output.

To verify tx (yours or anyone elses) you simply need to verify the prior outputs of the inputs in the tx to be verified.  By definition those would be included in a pruned blockchain.  Mining doesn't require anything beyond verifying txs other than access to prior blocks block header, the block height, and the ability to verifying work created by peers.

It might be a good idea to actually read the white paper.

I think fees is about the stupidest reason to avoid centralized exchanges.

EVERYTHING has cost.  Bitcoin itself has cost and fees pay that cost.

The things I dislike about centralized exchanges are:
* funds controlled by 3rd party (I would like to see an m of n type system where I have control of my BTC at all times)
* complete lack of accountability (MtGox deciding it is their job to be the Bitcoin Police)
* lack of transparency (does MtGox has $1 USD for $1 USD and 1 BTC for every 1 BTC in client accounts ? )

So far for more users those issues are dwarfed by the benefits of liquidity and narrow spreads.

That isn't how bitcoin works.  Bitcoin can't spend part of an OUTPUT.  So all tx must include entire OUTPUT(s) not entire wallets.  So if you have 100 BTC in your wallet, you want to send 10 BTC, and the smallest output (or sum of outputs) which will result in no fee is 12 BTC then you send 12 (100), 10 to the destination and 2 back to a change address.

Still what makes calculating tx value difficulty is that it is never possible to know for sure which is the "payment".  In the example above you could be sending 10 (w/2 change) or sending 2 (w/ 10 change).

BlockChain.info attempts to make educated guesses to determine which was the intended tx.

Raw Volume (sum of outputs)
http://blockchain.info/charts/output-volume

Guesstimate on like tx volume (based on size and "roundness" of outputs tries to determine likely change and removes it from daily sum)
http://blockchain.info/charts/estimated-transaction-volume

The estimated tx volume is pretty steady at 100K to 200K per day.

If the IP address changes then other nodes will see you as a new 0 minute node.  Nodes identify other nodes based on IP address.  Theoretically that could be changed but I don't think it is a pressing concern.

static IP isn't necessary as long as your IP address is relatively stable.  Looking at the incoming peers chart it looks like >8 hours is where # of incoming peers rapidly increases.  For most users DHCP leases tend to be 14 days or longer (I have the same dynamic IP address as I did last year) so there is no need for a static IP address.

Keeping p2pool running is important.  nodes rank other nodes based on how long they have seen them.  If you are always seen as a very short lived and unstable node it is unlikely any node will ever voluntarily connect to you (as there are other better options available).  Nodes are oppertunistic (as they should be).   They seek out the best possible nodes.

Currently looking at the code it looks like longevity is the only factor is how "good" a node is.  That probably could be expanded to include things like latency, share notification (what % of shares did that node report), bad shares (nodes should verify shares before forwarding), version reported, etc.

One thing to keep in mind if that even if you don't mine 24/7 you can keep p2pool & bitcoind running 24/7 (both use minimal resources & bandwidth).


If the IP address changes then other nodes will see you as a new 0 minute node.  Nodes identify other nodes based on IP address.  Theoretically that could be changed but I don't think it is a pressing concern.  One way I could see that changing is by nodes identifying themselves by a public key.  This would allow nodes to retain information on other nodes even when IP address changes.

A simpler patch would be to have the node list include dns entries.  Then using dyndns one could always be the same url despite IP address changing.  Personally I like the public key method better (prevents the need for frequent dns lookups) but using dns is much simpler.

Well technically they are on an incompatible and minority fork.  That fork can continue to exist forever but hopefully they notice the 70%+ (from their point of view) drop in hashing power and take the time to actually upgrade their p2pool once a month or so.

Yeah I am confused about what which slot you are looking to use?

PCIe x1 slot (which is not a "normal PCI slot")?

or

a normal PCI slot (which will require a different and significantly more expensive adapter than a PCIe x1)?

Haplo it is amazing that you can write so much and yet be consistently wrong.  I mean probability would indicate that a monkey randomly pressing keys would occasionally be right.

Haplo Myth:
the block chain could be 50MB.

Reality:
There are 1.8 million tx in the block chain thus 50MB/ 1.3 = ~27 bytes.  Entire tx stored in 27 bytes which can't be brute forced?  (cough cough) bullshit.

Haplo Myth:
pruned blockchain will prevent verification of tx by node without full blockchain

Reality:
Merkle tree was chosen because pruned blockchain will still allow tx verification

Haplo Myth:
There is no reason for the public address vs public key

Reality:
Addresses can be constructed from a public key but also can be constructed from other base types.  The use of an address allow similar processing regardless of the underlying structure.  It also provides cheksum, version, and protocol identification.  This greatly reduces the probability coins are sent to "nowhere".

Haplo Myth:
complex contracts take up more sense.

Reality:
p2sh allows massively complex scripts and contracts to take up no more space in blockchain that a "simple" tx.

Haplo how about you actually read the whitepaper, wikis, and code before incorrectly pointing out flaws.  
 
Haplo has no clue.