This.  Good, bad, or ugly you will never get the kind of consensus necessary to make just a drastic change to the Bitcoin network.  To even have a shot at it you would need to convince the developers of all the major wallets, a super majority of miners, a super majority of merchants, essentially all major exchanges, and convince at least a significant fraction of normal users.

It simply will never happen.  Every couple week/months/years someone will say "what if we x?" you never will be able to.  The current protocol has momentum and any miners of an alt-fork runs the very real risk they end up with lots of completely worthless coins while miners who stay on the current fork will see their difficulty fall and their revenue rise.

An alt-chain is possible.  I would also point out that an alt-chain doesn't need to start at a genesis block of 0.  You could for example take the current Bitcoin balances at block 210,000 and make your alt-coin start with that.  However changing something are core as the minting rate simply isn't going to happen so those who want it to  should start an alt-coin.

The only scenarios I see a permanent hard fork being plausible would be:
a) to replace ECDSA based addresses because they are cryptographically flawed.
b) to extend the number of digits because 1 satoshi is worth more than $0.10 USD in buying power (or equivalent).
c) to change the hashing algorithm because SHA-256 is cryptographically flawed.
d) to incorporate post-quantum cryptography because QC presents a credible risk.
e) some other catastrophic flaw in the protocol which simply must be changed to avoid the entire system failing

The same way you protect physical money, precious metals, diamonds, jewelry, etc.

First 90% to 95% should be in a cold wallet.  Depending on business needs 50%+ could be an in a "cold cold" wallet which isn't even located on site.  You don't need multi-sig in the protocol to split a private key.  Their are offfline techniques to split a secret so that is requires m of n sub-keys.   Designate one employee the trustee of each sub-key, and encrypt it with GPG public.   Then you have lots of options for securing the pieces to prevent rapid physical access.  Time lock safes (you know the real ones TL-6x30 rated, glass relocker, durress code, silent alarm,etc), safety deposit boxes in a nearby bank, a branch office located on another continent are all methods to make a "smash and grab" type robbery simply impossible.

The rest of cold funds should probably be off line but in a semi-available method.  Something like a cold wallet laptop in a time lock safe which requires 2 managers keys/codes.  

Protecting the hot wallet from a physical attack may be more difficult but it should be a dedicated physically hardened server.  Yes they make server chassis which are essentially burglary safes.  Making the hot wallet deterministic and in-memory only would allow the hot wallet to be wiped.  The seed should not immediately available during normal operations.   Then it really becomes how paranoid are you.  Rig the server to write over the hot wallet in memory when an attack is detected.  Site alarm system, panic button, duress code on the chassis, failure to receive heartbeat from the network could all be signals to wipe the server.  Hell if you wan to get crazy put a GPS on the server so if the attackers connected it to a battery, faked the heartbeat signal, and attempted to remove the entire server once it got more than x meters from the site it would clear and crash anyways.

In the event that attackers gain control of the site but can't directly steal the private keys the key server should have preset "rules" which limit coinflow.  It could operate in delayed signing mode for large tx, have tx qty and BTC qty limiter.  An example would be a set of rules that limit total tx per hour to 400 or less, total BTC per hour to 5,000 or less, and any single tx larger than 1,000 BTC will be delayed 60 minutes.

It all depends on how much you are willing to spend.  If you had the resources of even the smallest credit union or precious metal wholesaler you could turn an exchange into a fortress (class A building, armored doors, biometrics, armed security, close caption monitoring, panic shutdown system, datacenter vault, vehicle barriers, security lockouts, independent electrical power, etc).

You sure there is no GPA?  GPA is a core part of GPG4Win.  That makes me think maybe it is a busted install.

http://www.gpg4win.org/download.html

Some options:
a) Solo mining.
Enough said.  All the advantages and disadvantages which come with it.

b) Higher difficulty shares.
Using a pool which supports higher difficulty shares will reduce outgoing bandwidth.  You may also wan to encouraging other pools to adopt higher difficulty shares.  For example on a pool using difficulty 32 shares you will find (and thus transmit) 1/32 as many shares. Compensation is the same as each share is "worth" 32x as much.  Pools could support dynamic difficulty as optimal share difficulty varies by hashing power.  20GH/s at difficult 1 will find (and need to report) 12,069,941 shares every month. At ~ 0.5KB per share that is ~6GB per month.  Note that is just outbound data and is under optimal conditions.  Using a difficult of 100 would reduce that by 99%.  Inbound bandwidth remains the same at 1 (or more) getworks per physical processor (CPU core, GPU, FPGA chip, etc) per block.  

c) Getwork splitting.
This may require more work that it is worth.  Higher difficulty shares improve outbound bandwidth but even with longpolling and ntime rolling you need at least 1 getwork per physical processor per block.  So a farm with 50 GPU farm requests 50 block headers on every longpoll and one every time a share is found.  In theory a single getwork could be split across multiple GPU/FPGA (by giving each one of them part of the nonce range).  There is still an upper limit of roughly 1 getwork per 4GH/s per block.  That limit exists because more than 4GH/s will need more than 1 getwork per second and the timestamp has a precision limit of one second.

d) Local work.
Local work is likely the long term solution given the rise of TH/s ASICs.  It would operate similar to how p2pool works but still using a central "traditional" pool server.  Essentially solo mining with shared rewards/variance.   There is no real requirement that the server generate the blockheader for all miners and distribute them.  The only thing the server needs to provide (and verify on submitted hashes) is the coinbase address to ensure the pool (and all miners) are equitably paid.  It would require new mining software but a miner could construct the entire blockheader locally as needed.  In theory this would reduce inbound bandwidth to a negligible amount.   Outbound bandwidth per share is increased as miner needs to submit the merkle tree to pool for verification.  Still by using higher difficulty shares the overall outbound bandwidth can be reduced.  Say using 100 difficulty shares even if the share requires 20x as much bandwidth we are still talking an 80% reduction in overall outbound bandwidth and incoming bandwidth is reduced to a negligible (rounding error) amount.


c & d require real work however there is no reason pools couldn't support difficulty >1 today.

Technically the blockchain doesn't store values it stores unspent outputs.  While all unspent outputs are currently in the same format it would be possible to have new "high precision" addresses which say store Bitcoins in a new format.  This new format would only be used on new addresses.  

The migration process would be similar to P2SH:
1) Hash out the details, test, debate, etc.
2) Request miners put a tag in the codebase of solved blocks indicating they support the protocol change.
3) When sufficient majority of miners support the change (I think Gavin looked for 80% in P2SH) release a new version of the client.
4) The new version(s) of the client have a changeover block coded into the client.   The client would have the ability to support the new address type but it would reject them as invalid if seen prior to the changeover block.
5) On the change over block the new address type would be supported.

At that point older nodes (both miners and non-miners) would be forked off.  The main main chain seen as the longest by upgraded nodes would be seen as invalid by them (they would see the new high precision addresses as invalid txs).  As long as they represent a minority there is no real harm.  They simply need to upgrade to the new version.  There is no issue of their client's being "confused" (showing wrong amounts, etc) they simply would reject block & tx involving the new incompatible address.

It worked well with P2SH and IIRC Gavin brought up some ideas that would make future transitions easier (like coding a version number into the blocks & clients so that client would warn users when they see a future incompatible version on the network.  

Since Bitcoin doesn't store values it stores unspent outputs (which are used as a single unit) it is possible to support newer high precision addresses while at the same time also supporting "legacy" addresses.  User could keep using their old addresses or have a new version of the client generate a new address for them and move their funds to the new address.

Matts bet (as stupid as it was) does highlight that trust has limits.  Prior to the bet I would have trusted Matt with a couple BTC, maybe even a couple hundred BTC, but 10,000 BTC requires a lot of trust more than just someone's word.  80,000 BTC even with a signed promissory note is just silly, ask your bank if they will give you a $1,000,000 unsecured signature loan.

The issue is betteors looked at only THEIR tx not Matt's tx.  Bettors should have asked themselves this questions:
"Would I be willing to transfer 10,000 BTC to an address Matt controls and trust him to transfer it back?"

If the answer is no they shouldn't have placed the bet.  It indicates they didn't trust Matt to pay 10,000 BTC based only on his word.  Matt's bettors while individually placing small bets, were collectively (maybe unknowingly) trusting Matt to pay almost a million dollars. Someone betting 50 BTC wasn't trusting Matt to pay 50 BTC.  Why would Matt pay 50 BTC and default on the other 79,950 BTC?  Obviously he wouldn't.  Either everyone was going to get paid or nobody would.    I don't trust anyone that much and certainly not anyone online.


"Trust-bonds" could be setp with limits  (i.e. I pledge 5 BTC that ripper234 won't bust a trade of up to 100 BTC).  The cap could be set based on how much the person trusted the other person. Trust bonds should also be revocable with a delay.  I trust ripper234 (to use him as an example) but if opened a "magic investing biz offering 7% per week" I should be able to revoke that trust.  His actions make me trust him less (enough so that I would no longer want to back it with funds).  The fact that he hasn't scammed anyone yet (in this scenario) doesn't matter.  It is possible that someone's actions can reduce trust long before they commit fraud.

For large transaction escrow is the only way to go.  Vlad made a 5,000 BTC bet but it was escrowed.  Neither party had to trust the other (although they did need to trust the escrow agent).  Where "trust-bonds" could be useful is smaller tx where the incentive to scam is less and the complexity and cost of an escrow is not worthwhile.  The only bad thing is I can't see how this can be done completely decentralized.  Semi-decentralized maybe ...

Yeah it does have some parallels.  In making a "BTC-vouch" you are trusting the person you are vouching not to cause a financial loss much like when you deposit your money/gold/btc in a bank you are trusting the banker not to cause a financial loss/theft.


Just had a weird idea.  If a system like that ever developed (where people backed "vouches" with financial penalties) you could see professional "trust-bondsman".  Say some new trader has no rep or little rep and he needs rep to get rep.  So he goes to a "trust-bondsman" who collects some ID, makes some verifying phone calls, and requires the new trader to put up some funds into escrow (say 20 BTC).  The trust bondsman may then offer x BTC of rep (will pay x BTC for a busted trade).  The 20 BTC are just escrowed so later when the new trader has enough self earned rep he can collect his escrow back (minus a fee).  Higher level of guarantee may require more extensive dox (mail verifciation, public records search, etc) and a larger escrow.  In time the bondman may offer a higher x BTC on the same escrowed amount.

Anyways feel free to ignore just bouncing some unfinished ideas out there.

Thinking a little further really OTC is the answer BUT there needs to be a couple improvements:

a) there needs to be an OTC lite portal.  Getting GPG can be tough enough, then using IRC, authenticating, etc.  That can be overwhelming so people don't use it.  Some OTC lite portal (maybe with limits on # tx, etc) would allow more people to use it and that makes the system more powerful.

b) the big one.  There is no consequence for bad ratings.  If I give Pirate a rating 10 (I didn't) then I am staking my rep on Pirate rep.  If it turns out I am wrong (either through collusion or ignorance) there should be a penalty to my rep.   That might not seem very fair but think about it for a second.  If I am a horribly bad judge of character then there should be some discount for my ratings right?

Imagine I give a 10 to 3 known scammers and nobody else.
ripper234 gives a 10 to 3 people who show themselves to be trustworthy (by future good trades).
Obviously a 10 from ripper234 means more than a 10 from me right?

Anyways just throwing some random stuff out there maybe something sticks. 

What is the incentive to do that?  Honest question.  I could see something like that working but there has to be an incentive for the person making the vouch.  Otherwise it is risk x to gain 0 which is always a bad decision.   Interesting concept to monetize trust.  It makes me thing some system is there I just can't see it through the coffee starved fog in my brain.

The best attempt I have seen yet.

Just scrutinize every order and be ready to make some subjective evaluations and rejections on the side of caution.

Just watch for all the obvious warning signs.
* Unverified PayPal
* Verified PayPal shipping to unverified address.
* Ebay account with little or no history or very recent account with history from a few (shill) sellers.
* Ebay account without activity for a long time (possible hacked/stolen account).

Will be interested if you can beat the scammers and hackers.  

A wallet with a single unspent output is certainly not optimal.

It doesn't take that much coinage to be considered high priority.

Take a user with 20 BTC.  Lets assume it is all in a single output and old enough to avoid low priority fee.
He spends 8 BTC gets 12 BTC back as change.  He now has to wait ~24 BTC hours or 2 hours before he can make a second tx without fee.

Compare that to a wallet same 20 BTC but in two 10 BTC unpsent outputs.  He can spend 8 BTC using one output and then seconds or minutes make a 2nd tx of up to 12 BTC without pay a fee.

Hero? Hardly.

I would nominated Stephen for "Super Hero" forum classification. 
He probably would hate the distinction but it is the truth.

Bitcoin-QT is a wallet.  It doesn't mine anything... ever.  The analogy would be like asking does my Bank Of America online banking do mining.  At one time (a long time ago) the client had a built-in miner but it was removed because it simply couldn't keep pace with the difficulty.   You could mine for years and not get anything with the old client.  To put it into perspective difficulty is now ~2.7 MILLION times higher than when the network launched.   For the same amount of computing power it will take you 2.7 millions times as long to produce the same amount of coins.

Today to participate in mining you need a piece of software called a "miner".  This would be seperate from Bitcoin-QT (or any other client/wallet).  You also will need a significant amount of GPU computing power and cheap electricity or specialized hardware (FPGA) to have the ability to mine more than a token amount (bitcents per day).

Why?  It was the exchange rate at the time.  He could have bought the pizza and then turned around a week later spent some cash and bought 10K BTC back.  10K BTC were simply only worth that much back then.   It would be like saying "I would like to say whoever sold 1 oz of Gold in 1950 for $30 (or whatever the exchange rate was) was a dumbass".  

I would also point out without exchange/commerce the coins essentially have no value.  Had he (and others) not traded trading Bitcoins for products & services the experiment may have failed a long time ago.  Price discover doesn't happen by magic.  It happens by people trading.  The more people trade the better idea we have that the price is an accurate one.  It has to start somewhere.

Find some sucker who doesn't care if he gets scammed and offer easily reversible, hacked, stolen PayPal for irreversible Bitcoin.  Offering an ridiculously high price seems to help.

Just press ignore and save yourself a lot of pain.

If he is high when he wrote that, then he is always high.

If you are in the US.  Get a PayPal debit card (free). 
Use it to cash out from PayPal at any ATM and use Bitcoins Direct cash deposit option (see sig).

They won't.  They will be using lite nodes in probably 5 to 15 years from now.

Any payment can be "voided" if allowed by statute (in the US it is 90 days prior to the BK petition).  However it is rare for personal payments to be voided.  

An example of a common BK. Someone is in debt (lots of creditors - multiple CC, a signature loan, a loan on a jet ski, loan on car, student loan, mortgage etc).   They get into financial trouble and the liabilities are more than the income.  This person decides to forget the jet ski, CC, and signature loan.  They use the little income they have each month to keep making payments on their mortgage and car note. Technically the trustee could void the prior 3 mortgage and car payments, return that cash back to the bankrupted estate and divide it among creditors.  In 99.9% of the cases the trustee won't.  It is human nature to try and save your home.  The debtor hasn't done anything which indicates that he is trying to defraud anyone. 

Another example.  Same debtor as above but he has $10,000 in gold coins.  He decides to sell the gold coins to his brother for a lawn mower worth ~$100, 90 or less days before the BK petition.  The trustee would likely void this payment.  The gold would return to the estate.  The brother would become a secured creditor and could either seek to get his lawn mower back or get fair market value on a prorated basis with other creditors.  It is quite obvious the intent of the sale was to defraud the creditors.

In the real world most cases fall in between those two.  Just because a trustee "can" void a payment doesn't mean they always will. There is no absolute rule, or "line in the sand".  Generally speaking trustees use common sense to determine an equitable arrangement. There are far too many unique situations for the law to specify in black and white how to handle every situation.

His scenario is someone DOES come to his house to take the large sum of bitcoins in his offline wallet.  You solved the scenario he isn't asking about.